-
Notifications
You must be signed in to change notification settings - Fork 341
Technique using progressbar role #4686
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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.
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Discussed on Backlog call 10/31. @patrickhlauke agreed to review. |
|
@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? |
|
Yep, that works. I think it's more that the progress is programmatically determined with the |
|
the example gives the impression that you need to do both the (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 |
|
@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. |
|
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) |
|
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 |
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
progressbarriole and a live region.Edit to add ARIA 25 deploy preview