Native HTML elements run from simple ones, like button and heading, to more complex elements like table and select. What differentiates the simple from the complex is that a complex element contains both parent and child elements. A button is just that, a button, but a table has child rows that have child cells, both heading and data cells. A table is much more complex than a single element like a button.
I want to introduce you to what may be the single most useful site for ensuring the accessibility of your web pages, particularly if you want custom styling that can’t easily be accomplished with vanilla HTML. “Vanilla HTML” implies flavored HTML, and this “flavored HTML” is a combination of HTML and ARIA (remember, this stands for Accessible Rich Internet Applications.) That extremely useful site is the WAI-ARIA Authoring Practices.
There are common widgets that have no native HTML equivalent, like an accordion, tooltip, dialog, etc. The Authoring Practices provides accessible patterns for widgets, specifically the roles, parent/child/sibling relationships, states and attributes required to allow non-visual users to recognize, understand, and use your widgets.
Some HTML elements can be trickier to style, for instance the select. With HTML and ARIA, you can use the Select Combobox Pattern, which is built with divs that you can easily style. There’s a tradeoff though, if you use native HTML elements, all the functionality, roles, and states are built in. If you use HTML and ARIA, you will probably have to write JavaScript to handle the functionality and states.
This is one of the most important considerations when it comes to easily creating accessible content: when you are designing your page, every widget you plan to use you should look for in the Authoring Practices. If you find it, make sure you adhere to the pattern, and the roles, parent/child/sibling relationships, attributes, states, and keyboard behaviors match the pattern.
If you want to create a new widget that doesn’t exist in the Authoring Practices, or if you don’t want your widget to announce and/or behave as described in the AP, you must commit to spending the time to build, test, repeat as many times as it takes to get it right. You also have to provide users with instructions so they know how to use the unfamiliar widget.
Comments