There is still a lot of scope for improving our use of ARIA techniques. During the early phases of D8 development (2012-2013, say) the level of support for ARIA was quite inconsistent across various browsers and assistive technology. Many accessibility issues were decided on the basis of what we could get away with in the present state of technology. Since then, ARIA 1.0 has been more completely implemented. Broadly speaking we've moved from "not ready yet" to dealing with known bugs/quirks, and we are seeing more consensus in the wider accessibility community about how to use ARIA effectively.
The new six-monthly release cycle provides scope for modernizing our ARIA usage in stages, adopting new patterns once we feel they are well enough established. Quick wins can come in D8 minor releases, and major changes can be postponed to D9 if necessary.
The W3C ARIA Authoring Practices guide (APG for short) is being developed as a set of best-practice patterns for accessible UI widgets. It provides a good starting point to compare our existing UI widgets against. We don't have to adopt it wholesale though.
Similarly, WAI-ARIA 1.1 is now a W3C recommendation, and introduces some new roles, states and [properties which we can employ.
Some places we could use better ARIA patterns include:
aria-current property, which can make pagers, breadcrumbs, menus, and multi-step forms, more robust.
aria-errormessage relationship property. We could programatically associate error messages with form inputs, similar to how we use aria-describedby for help text.role="progressbar" for Batch API could provide clearer announcements than the current approach which is just a basic live region. See comment #22-24.aria-modal="true" to clarify the behaviour of dialogs. Additionally, HTML 5.2 introduced a <dialog open> element with an accompanying HtmlDialogElement interface. We might employ these eventually. The authoring practices have some advice about how dialog implementation.aria-haspopup="dialog", per ARIA 1.1, does not have good support yet as of Feb 2019. When it does, it should be useful for places where we have dialogs: Views UI, Workspaces, MediaLibraryWidget, Layout builder, etc..aria-haspopup="true", per ARIA 1.0, has good support and can be used for menus like dropbuttons.Use child issues to explore particular UI widgets in detail.
This is primarily about accessibility improvements, for screen reader users, keyboard-only users, etc..
No major changes propsed to the current designs (visually speaking).
Some markup changes might be necessary; aim to minimize these.
Possibly some additions to the Javascript API. Some of these ARIA patterns might work as a JS library, or involve expanding the capabilities of existing libraries. On the scale of our existing Drupal.announce() and Drupal.tabbingManager() APIs.
Hopefully none.
Active
11.0 🔥
markup
It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Moving to core from the ideas queue (which is deprecated).
We're now at 1.2 and there is a draft of 1.3
https://www.w3.org/WAI/standards-guidelines/aria/
Should we update this or start a new issue?