The First Rule of ARIA is "Don't Use ARIA" [2/6]

Hey, there! Welcome back to this accessibility email series.

When building websites and web applications, there is both an opportunity and a responsibility to use semantic HTML and ARIA that exposes accessibility information to assistive technologies. Semantic HTML refers to elements that provide structure and hierarchy, such as HTML5 landmark elements, headings, lists, forms, and interactive controls like buttons, links, and inputs. These elements come supplied with "implicit roles" baked-in from the browser and exposed in accessibility APIs, such as <main>, <nav>, <h1>, <button>, <ul>, and <fieldset>.

Start building an accessible baseline with the most semantic HTML structure you can, and then enhance with scripting and ARIA to add interactivity. There are legitimate use cases for turning off JavaScript, and users will be able to access information rendered in semantic HTML even if it isn't as dynamic. For example, you could mark up parts of a product listing in landmark and list elements and reformat into an accessible tab switcher component when JavaScript is available.

Browsers provide a lot of functionality with HTML and APIs for free, such as focusability and browser history for anchors with href attributes. It's worth researching and exhausting all available options before attempting to create something custom. My favorite resources for this kind of thing are MDN and HTML5Doctor.

Should you absolutely need to create custom browser components, there is always Accessible Rich Internet Applications, or ARIA for short. The ARIA specification defines a standard set of attributes you can explicitly "bolt on" to your HTML markup and plumb accessibility information through web pages. ARIA is an advanced tool that can sometimes cause more harm than good, so be sure to read up on a particular attribute's requirements before using it. And remember the the "first rule of ARIA", from the W3C:

To give you an example of how accessibility information is used in assistive technology, consider this requirement for an accessible button: its accessible name. For each interactive control or repeated landmark element (like <section> or <nav>), a unique text name is needed to tell a user of assistive technology what that item is for. For example, a settings button would need an accessible name that identifies it, such as an aria-label attribute or text content of "Rainier McCheddarton profile settings". This unique text would ensure that particular button stands apart from other settings buttons, such as "Bagley Fluffpants profile settings".

An accessible button would also need an interactive role to behave properly in assistive technology. Native HTML <button> elements inherit this role for free, while custom <div> buttons (if you must!) can take on the interactive role with <div role="button">. Note: there are also quirks with JavaScript click events depending on the element. You'll learn more about these mechanics later in the Testing Accessibility email series.

When an interactive role and accessible name are present on a button, screen readers will announce something like "button Rainier McCheddarton profile settings". This is made coordinated by a browser structure parallel to the DOM (Document Object Model) called the accessibility tree. This structure enables platform accessibility APIs to announce the page's accessibility information in assistive technologies. Our settings button button would also be listed in configurable document summaries that utilize the accessibility tree, such as NVDA's Elements List and the Voiceover Rotor.

Semantics and ARIA provide accessibility information "under the hood", where developers may miss the impact of certain markup unless they test for it. It's unfortunately easy to use ARIA wrong and it can really screw up the accessibility of a page if used incorrectly.

To ensure your semantic markup and ARIA helps rather than harms user interfaces, use browser extensions like Accessibility Insights and its automated checks, headings, tab stops, and headings tools. You can also validate accessibility information in Chrome and Firefox DevTools by inspecting an element and viewing the details on accessible name calculation and other attributes.

It's also worth learning how to test in screen readers such as NVDA, JAWS, and Voiceover. Download cheat sheets from WebAIM and Deque University to familiarize yourself with common shortcuts. But remember: as a new and irregular screen reader tester there will be a learning curve. So use caution when filing bugs against websites and remediating fixes. Consult with proficient screen reader users to gain more insight into how user interfaces would work best. For a primer, check out Leonie Watson discussing How a Screen Reader User Accesses the Web.

In the next email in this series, you'll learn about keyboard and screen reader mechanics using JavaScript and ARIA with HTML. Click here to answer a quick quiz question about what we just discussed, and I'll send the next one right away!

Until next time,
Marcy Sutton