aria-practices
aria-practices copied to clipboard
w3c
When to use what ARIA - add throughout APG. [important]
APG needs to make it clear up front and throughout:
- What ARIA everyone should be doing even for simple, non-interactive web pages to provide basic accessibility (like Level A)
- What ARIA would be good for everyone to do even for simple, non-interactive web pages to provide better accessibility (like Level A)
- What ARIA I don't need to bother with if I'm not developing custom controls
- What ARIA I should user for which types of native controls
- That it's often better to use native HTML with accessibility support, rather than build your own custom controls
- etc.
I think the redesign text and promotion muddy above, to the frustration of some (publicly vented).
I think this is fundamentally important for helping readers (including folks like myself and @SteveALee) know what to spend their time learning. And to combat overwhelming-ness. Also, it's important for APG's reputation.
Related (that I'll address elsewhere) is better communicating the status of implementation support, etc. for each aspect. I understand that getting and proving good data on that is an upcoming project. In the meantime, each page should have some sort of disclaimer or explanation of the current situation, even if it's not well known yet.
@shawna-slh wrote:
APG needs to make it clear up front and throughout:
- What ARIA everyone should be doing even for simple, non-interactive web pages to provide basic accessibility (like Level A)
- What ARIA would be good for everyone to do even for simple, non-interactive web pages to provide better accessibility (like Level A)
These are great things to do, but they are currently outside our scope. Basically, this means thoroughly covering correct use of semantic HTML.
As part of our long-term plan, though, we would like to bring full coverage of semantic HTML into the APG so that people do not have to go to one place to learn just about ARIA and another to learn about the ARIA that is implicit in HTML. In particular, review the scope section of our original redesign proposal.
We are still in the very beginning of that proposal. We have accomplished about half of phase one and a couple items from phase two. It will likely take most of 2023 to complete phase two. We might want to consider pulling some of phase four forward if the demand is strong, as this issue suggests.
Net, it will take several years for APG to evolve into being a more wholistic resource.
BTW, specifying what is required for WCAG is not planned to be in scope. It is better for WCAG to reference APG where appropriate rather than for APG to describe what is needed for single-A compliance.
- What ARIA I don't need to bother with if I'm not developing custom controls
I don't understand this point.
- What ARIA I should user for which types of native controls
Please give an example of what you mean. Does this simply mean how to minimize use of explicit ARIA? If so, this is part of the long-term plan I referenced above to increase scope and consolidate resources describing use of semantic HTML.
- That it's often better to use native HTML with accessibility support, rather than build your own custom controls
This is stated at the top of every example page and at the top of the patterns and practices pages. It is part of the read this first content.
I think the redesign text and promotion muddy above, to the frustration of some (publicly vented).
That's disappointing to hear. I wonder specifically how the new design muddies such messaging, especially since we have put quite a bit of effort into making the read this first content more prominent than it ever was in the TR doc.
I think this is fundamentally important for helping readers (including folks like myself and @SteveALee) know what to spend their time learning. And to combat overwhelming-ness. Also, it's important for APG's reputation.
Currently APG is not designed to help people prioritize their personal learning process, e.g., how to go from zero to one. It is intended to be a reference. We want it to be easy for people to find what they want to learn, but they do need to approach it with an intent. It would be quite an undertaking to build a progressive resource. I imagine that would be a companion to APG that references its content.
Related (that I'll address elsewhere) is better communicating the status of implementation support, etc. for each aspect. I understand that getting and proving good data on that is an upcoming project. In the meantime, each page should have some sort of disclaimer or explanation of the current situation, even if it's not well known yet.
This is part of the read first content at the top of every example page. Currently, that content is not very visible; the redesign did unfortunately reduce its visibility. That will be fixed in a few days by w3c/wai-aria-practices#116.
BTW, the aria-at project is on track to integrate screen reader support tables for eight patterns by end of year. Please note, these are the simplest ones; they are the proof of concept.
