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

chrome

Safari

safari

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

ff

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.

CommentFileSizeAuthor
#21 safari.gif277.12 KBfinnsky
#21 ff.gif112.86 KBfinnsky
#21 chrome.gif336.59 KBfinnsky

Issue fork drupal-1484174

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Niklas Fiekas’s picture

Issue summary: View changes

W3C, WHATWG spelling

kika’s picture

Niklas Fiekas’s picture

Status: Active » Closed (duplicate)

Oh, it is. Thank you.

Just created the issue because that one wasn't in the overview. Added it there.

Bojhan’s picture

Status: Closed (duplicate) » Active
jibran’s picture

Version: 8.x-dev » 9.x-dev
jibran’s picture

Issue summary: View changes

Add alternative

catch’s picture

Version: 9.x-dev » 8.x-dev
Issue summary: View changes
Issue tags: +minor version target

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

finnsky made their first commit to this issue’s fork.

finnsky’s picture

Version: 9.5.x-dev » 11.x-dev

finnsky’s picture

Title: Add new HTML5 FAPI element: progress » Add HTML5 element: <progress>
Issue summary: View changes
Status: Active » Needs review
Issue tags: -minor version target +Needs Review Queue Initiative
Related issues: +#2973140: Convey AJAX progress messages to assistive technology.
FileSize
336.59 KB
112.86 KB
277.12 KB
finnsky’s picture

Issue summary: View changes
finnsky’s picture

finnsky’s picture

Issue tags: -JavaScript +JavaScript, +a11y
mgifford’s picture

Issue tags: -a11y +Accessibility

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/

finnsky’s picture

RE #25

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

smustgrave’s picture

Status: Needs review » Needs work

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

andypost made their first commit to this issue’s fork.

andypost’s picture

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

finnsky’s picture

little lag in current Firefox but is it really a blocker

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

Keshav Patel made their first commit to this issue’s fork.

Keshav Patel’s picture

Status: Needs work » Needs review
finnsky’s picture

Issue summary: View changes
Status: Needs review » Needs work

- 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.

mgifford’s picture

Issue tags: +aria

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.