Add HTML5 element: <progress>

Created on 15 March 2012, almost 13 years ago
Updated 11 March 2024, 10 months ago

WHATWG: http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element

Currently it supported by all browsers and can be even styled. https://caniuse.com/progress

Current install Drupal pages for example:

Chrome

Safari

Small transition problem in FF(but seems not critical):

Main plus here is a11y

From:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/pr...

It is recommended to use a native
or elements rather than the progressbar role. User agents provide a stylize widget for the
element based on the current value as it relates to the 0, the minimum value, and the max value. When using non-semantic elements, all features of the native semantic element need to be recreated with ARIA attributes, JavaScript and CSS.

Better to use native elements always imo.

What left to do?

- Correct styles for Umami (it is possible to remove them completely from Umami. Because they look strange even before the patch)
- Figure out what to do with stable9 styles
- Figure out what to do with the starter kit.

โœจ Feature request
Status

Needs work

Version

11.0 ๐Ÿ”ฅ

Component
Formย  โ†’

Last updated 2 days ago

Created by

๐Ÿ‡ฉ๐Ÿ‡ชGermany Niklas Fiekas

Live updates comments and jobs are added and updated live.
  • JavaScript

    Affects the content, performance, or handling of Javascript.

  • html5

    Implements and supports the use of HTML5.

  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • Merge request !5115Draft: Resolve #1484174 โ†’ (Open) created by finnsky
  • Status changed to Needs review about 1 year ago
  • Pipeline finished with Failed
    about 1 year ago
    Total: 200s
    #37875
  • Pipeline finished with Success
    about 1 year ago
    Total: 664s
    #37878
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada mgifford Ottawa, Ontario

    Wanted to flag this the accessibility concerns about properly labelling it:

    In most cases you should provide an accessible label when using <progress>. While you can use the standard ARIA labelling attributes aria-labelledby or aria-label as you would for any element with role="progressbar", when using <progress> you can alternatively use the <label> element.

    I would say that using <label> is better.

    <label>
      Uploading Document: <progress value="70" max="100">70 %</progress>
    </label>

    More good examples here - https://scottaohara.github.io/a11y_styled_form_controls/src/progress-bar/

  • ๐Ÿ‡ท๐Ÿ‡ธSerbia finnsky

    RE #25

    Thank you for review. Yes definitely we need label. Here i only prepared example that no visual regressions will be.

  • Status changed to Needs work about 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    But think original question, least how I understood, is that this is definitely a good replacement to have.

  • First commit to issue fork.
  • ๐Ÿ‡ซ๐Ÿ‡ทFrance andypost

    There's still little lag in current Firefox but is it really a blocker?

  • Pipeline finished with Success
    10 months ago
    Total: 568s
    #115580
  • ๐Ÿ‡ท๐Ÿ‡ธSerbia finnsky

    little lag in current Firefox but is it really a blocker

    I don't think so. Probably it may be fixed or even ignored.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia keshav patel

    Keshav Patel โ†’ made their first commit to this issueโ€™s fork.

  • Pipeline finished with Success
    10 months ago
    Total: 492s
    #115821
  • Status changed to Needs review 10 months ago
  • Status changed to Needs work 10 months ago
  • ๐Ÿ‡ท๐Ÿ‡ธSerbia finnsky

    - I adjusted the styles for Olivero and Claro.
    - Added a label for accessibility

    What's left to do:

    - Correct styles for Umami (it is possible to remove them completely from Umami. Because they look strange even before the patch)
    - Figure out what to do with stable9 styles
    - Figure out what to do with the starter kit.

    Moving back to work

    Would be cool if anyone could test it.

  • Pipeline finished with Failed
    10 months ago
    Total: 648s
    #115930
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada mgifford Ottawa, Ontario

    Worth comparing with https://dequeuniversity.com/library/aria/progress-bar-bounded

    Many uses of progress bars are essentially static, but Drupal we often use them as dynamic elements which should be updated with aria-live.

    Deque uses:

    <div id="progressbar-bounded" class="deque-progressbar deque-progressbar-bounded">
      <progress role="progressbar"
      aria-valuemin="0"
      aria-valuemax="100"
      aria-label="A bounded progress bar from 0 to 100">
      </progress>
      <p>
        <button class="deque-button" id="start-progressbar">
          Start
        </button>
      </p>
    </div>

    They leverage the ARIA progressbar role. I"m not certain that this is needed, but wanted to note it here.

    MDN just states:

    If the progressbar role is applied to an HTML
    element, the accessible name can come from the associated . Otherwise use aria-labelledby if a visible label is present or aria-label if a visible label is not present.

    What is in the latest patch I think is:

      <div id="${id}" class="progress" aria-live="polite">
            <label>
              <div class="progress__label">&nbsp;</div>
              <progress class="progress__element" value="0" max="100"></progress>
            </label>
            <div class="progress__percentage"></div>
            <div class="progress__description">&nbsp;</div>
      </div>

    I'm not sure how much the JavaScript would affect things here either. I haven't compared the two.

Production build 0.71.5 2024