Skip to content

Conversation

@fstrr
Copy link
Contributor

@fstrr fstrr commented Oct 13, 2025

Ref #4378

This is one of the "future link" references that have been around for a while (this one probably since 2.1 was released). This technique demonstrates using and ARIA progressbar riole and a live region.

Edit to add ARIA 25 deploy preview

1. add temp link to `progressbar` working example
2. delete `role=marquee` reference as that role has no browser support
3. delete aria live with chat client as the `log` example is a chat client example
Ref: #4378

This is a technique that’s been listed as a “future link” probably since WCAG 2.1 was released.
@netlify
Copy link

netlify bot commented Oct 13, 2025

Deploy Preview for wcag2 ready!

Name Link
🔨 Latest commit 47bf25e
🔍 Latest deploy log https://app.netlify.com/projects/wcag2/deploys/69654c0010969f00087bd4ee
😎 Deploy Preview https://deploy-preview-4686--wcag2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@fstrr
Copy link
Contributor Author

fstrr commented Oct 13, 2025

Preview

@bruce-usab
Copy link
Contributor

Discussed on Backlog call 10/31. @patrickhlauke agreed to review.

@mbgower mbgower self-assigned this Nov 7, 2025
@mbgower
Copy link
Contributor

mbgower commented Nov 17, 2025

@fstrr Is it worthwhile mentioning that the values are exposed programmatically? And that additionally, the text message is properly created as a status message? My thinking here is that without any message, the three value attributes are sufficient to support the progress bar role. The "done" text message is a separate way of conveying status; it's nice, but it's not necessary to be sufficient. If you concur, is it worth stating that?

@fstrr
Copy link
Contributor Author

fstrr commented Nov 19, 2025

Yep, that works. I think it's more that the progress is programmatically determined with the aria-value* attributes, but as the progress role isn't live, the only way for a screen reader user get an upate is, I think, to move on and off the element as it updates. The status message underneath the progress component improves the user experience but, yes, isn't strictly necessary.

@patrickhlauke
Copy link
Member

patrickhlauke commented Dec 12, 2025

the example gives the impression that you need to do both the progressbar (fully ARIA-fied) and the live message. what if the author chose to use a generic <div> with some fancy CSS to give the visual impression of a progress bar, but then still used the live region? that would also still satisfy 4.1.3 - the key bit here is the live region?

(though of course, it's nice in NVDA that progressbars that update automagically get the frequency-based notification of change as well, as in the attached video)

aria25-progress-live.mp4

@mbgower
Copy link
Contributor

mbgower commented Dec 19, 2025

@patrickhlauke your latest comment came after this had already been moved to 'ready for approval'. Is there something you want changed before it goes to the WG?

In regard to impressions, sufficient techniques often exceed the minimally sufficient and get into the realm of best practices. This doesn't seem to me to be excessive in that context.

@patrickhlauke
Copy link
Member

well yes, my point was: this demo is overloaded ... if it serves to illustrate 4.1.3, why also use progress bar? that just muddies the clarity of the advice here ... that you need to use a live region to announce the change (whether you use progress, or a div, or whatever)

@patrickhlauke
Copy link
Member

sorry, batting this one back for discussion, as I still believe the point this tries to make is obfuscated unnecessarily by the use of progressbar itself

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants