Day 44: ARIA Roles Have Requirements

Published on 13 Jan 2019

• journal
• was
• aria
• techniques
• widgets

Finishing off my study week about interactive controls/widgets from the WAS Body of Knowledge, I came back to ARIA documentation to look through ARIA roles, their parent and child relationships, and required attributes. This was actually a very engrossing study time as I dove into how some roles are related and how they can help make an interactive component more accessible!

• Read ARIA Roles and Attributes: How to Actually Use Them.
• Browsed through the WAI-ARIA spec to pinpoint requirement within relationships.
• Created another sheet in my study spreadsheet to break out roles that have required parents, children, attributes, and/or accessible names. (it's not quite finished yet)

Requirements for roles used in interactive controls, found in the WAI-ARIA docs, include:

• required owned elements (e.g.role="combobox" has to have textbox and listbox, tree, grid, or dialog as children)
• required context roles (e.g.role="cell" has to have row as a parent role)
• required states and properties (e.g.role="checkbox" has to have the aria-checked attribute)
• accessible name required (true or false)

One thing I've discovered on my learning journey is that I'm having a much easier time reading "hard" documentation the further along I get. It was overwhelming at first, yet as I better understand what I'm looking for, the easier it is for me to browse and find the answer to what I'm looking for. For instance, knowing that some roles have different requirement, I did a Ctrl + F to quickly find the word "required" throughout the documentation, so I could quickly find which roles had required parents, children, and/or attributes.

One requirement that was completely new (and of interest) to me: the heading role requires an aria-level attribute. Makes sense, I just wouldn't have guessed to use it.