100 Days of A11y

Day 11: Diving into ARIA

Published on

I've finished studying WCAG! Now onto ARIA, the next item in the checklist from the WAS Body of Knowledge. WCAG's Robust principle segues into this. As SC 4.1.2 states:

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

Permalink for "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:

What I learned today

Permalink for "What I learned today"

So many things!

Always Remember

Permalink for "Always Remember"
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.