“For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.”
The WAI-ARIA specification says that it exists to provide:
“an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications.”
And so the twain shall meet when development of custom components occurs.
Things I accomplished
I got a slower start on these docs, as I just wasn’t as familiar with them. WCAG had a straightforward POUR outline. ARIA docs didn’t have as easy an access point for me, so I had to spend some time trying to create an approachable framework for myself to navigate the less familiar territory. I did manage to:
- read the WAI-ARIA’s introduction and using WAI-ARIA. and
- add a sheet to my WAS Certification Prep spreadsheet to include ARIA.
What I learned today
So many things!
- ARIA 1.1 complements the HTML5 and SVG2 specs.
- WAI-ARIA Authoring Practices 1.1 is an accompaniment to ARIA 1.1 is a how-to guide and best practices for ARIA, including links to accessible widget examples.
- As a matter of fact, there’s a whole WAI-ARIA 1.1 suite geared towards the audiences it affects:
- WAI-ARIA Authoring Practices 1.1 addresses authoring recommendations for HTML, and is also of interest to developers of authoring tools and conformance checkers.
- Core Accessibility API Mappings 1.1 addresses developers of user agents and assistive technologies.
- Accessible Name and Description: Computation and API Mappings 1.1 also addresses developers of user agents and assistive technologies.
- Semantics: the science of meaning.
- Roles describe element types that do not change.
- States and properties declare attributes that change during interaction.
- Managing focus in web applications sounds like something I need to spend some quality time on.
“WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement.” -and- “It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object.”
It’s tempting to use ARIA, since it’s a bit more mysterious and, therefore, appealing to master, but it can’t be stated enough: don’t use ARIA if you don’t have to. I’ve heard this before, seen it stated in different documentation, and completely agree. Use semantic HTML first.