Skip to main content

The A11y Path

This blog aims to cover: W3C Guidelines, Assistive Technologies (AT), European Accessibility (EN 301 549), and more.

Aria 1.2 Overview Part 1

Published

#was #aria #journal

Now that I'm done with ATAG, the next focus in the WAS Body of Knowledge (BoK) is ARIA (Accessible Rich Internet Applications). Progress has been a bit slow lately — things have gotten busier on my end, WAI-ARIA and to be honest, the WAI-ARIA documents can be pretty overwhelming. I also struggled with how to approach the study, So, I asked ChatGPT for help in creating a structured checklist to guide my ARIA study, and here's what it came up with:

WAI-ARIA Study Checklist for WAS

1. ARIA Basics

  • Understand the purpose of WAI-ARIA and when to use it.
  • Know the difference between roles, states, and properties.
  • Learn the 5 rules of ARIA (“First Rule of ARIA: Don't use ARIA”).

2. ARIA Roles

  • Landmark Roles
    • banner
    • navigation
    • main
    • complementary
    • contentinfo
    • search
    • Understand how landmarks help screen reader navigation.
  • Widget Roles
    • button, checkbox, radio, tab, tabpanel
    • dialog, tooltip, menu, menuitem, slider, switch, etc.
    • Learn expected keyboard interactions for each role.
  • Document Structure Roles
    • heading, list, listitem, region, article, separator
  • Live Region Roles
    • alert, status, log, timer, marquee
    • Understand when and how these roles notify users of changes.

3. ARIA States and Properties

  • aria-label vs aria-labelledby vs aria-describedby
  • aria-expanded, aria-pressed, aria-checked
  • aria-hidden and its impact on visibility in the accessibility tree
  • aria-live, aria-atomic, aria-relevant
  • aria-controls, aria-owns, aria-activedescendant
  • Which roles require which properties (refer to ARIA spec tables)

4. ARIA Authoring Practices

  • Review ARIA design patterns from the WAI-ARIA Authoring Practices Guide
  • Understand complete keyboard interaction models for:
    • Tabs
    • Modal Dialogs
    • Accordions
    • Menus
    • Sliders
    • Disclosure Widgets

5. ARIA & Native HTML

  • Know which native HTML elements already have implicit roles
  • Know when ARIA is redundant or harmful
  • Examples of incorrect ARIA use (e.g., role="button" on a non-focusable div)

6. Testing & Debugging

  • Use browser dev tools (like Chrome or Firefox Accessibility pane) to inspect ARIA roles/states
  • Practice checking the accessibility tree
  • Know how screen readers behave with various ARIA roles/states
  • Identify common ARIA failures during accessibility audits

7. Bonus Review

  • Understand the ARIA 1.1 spec vs 1.2 draft differences (optional)
  • Check IAAP BoK references to ARIA patterns and roles
  • Use ARIA examples in your own code for practice

This checklist feels like a solid starting point, and I'll be using it to organize my learning. I'll also be referencing the official WAI-ARIA documentation as I go. As always, I'll keep updating this blog with my progress.

While I use AI to support my studies, I don't rely on it as a primary resource. I use it to help me better understand the official resources I'm already using; mainly W3C documentation (for now). For example, when I come across something I find difficult to grasp, I ask AI (ChatGPT) to explain it or help break down parts of the WAS Body of Knowledge outline. I wouldn't recommend using AI as your main source of study, because it can sometimes provide inaccurate information.

Understanding Aria

I learned that ARIA was created to solve a very specific problem that came with the web becoming more robust and dynamic. While we currently have some semantic HTML, like nav to describe navigation, we don't have semantic tags for other roles like tab. So, when developers create a tab interface, it's usually made with just divs and buttons. Visually, it might look like a tab, but a screen reader user wouldn't know that. Cue WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications).

ARIA solves these issues by providing accessible roles, states, and properties which, when used properly, are meant to give assistive technology users full context and information.

Roles vs States vs Properties

Roles, states, and properties are key parts of ARIA:

  • Roles define what an element is or what it does. For example, role="tab" tells assistive technologies that the element functions as a tab in a tabbed interface.
  • States describe the current condition or status of an element. For example, aria-disabled="true" indicates that the element is currently disabled and cannot be interacted with.
  • Properties provide additional information about the element to help users understand or interact with it. For example, aria-label="Close" gives a screen reader user a clear label describing the element's purpose.

In summary, roles tell what something is, states tell what it is doing, and properties provide extra information.

5 Rules of ARIA

  1. Don't use ARIA if you can use native HTML if a native HTML element or attribute provides the necessary semantics and behavior, use it instead of ARIA. This is the most important rule.
  2. Don't change the native semantic unless you really need to. In other words: Do not override the semantics of native HTML elements unnecessarily with ARIA roles.. Changing native roles can confuse assistive technology users.
  3. All interactive ARIA controls must be keyboard accessible if you use ARIA to make something act like a widget (e.g., button, tab, menu), you must add all expected keyboard support manually. Interactive ARIA roles like role="button" do not come with keyboard interaction. You need to add it with JavaScript.
  4. Don't use role="presentation" or aria-hidden="true" on focusable elements If you do this then some users will not be able to use the focusable element; Focusable elements must be visible to assistive technology. Also setting display:none or visibility: hidden on an interactive element makes it unfocusable, it is also removed from the accessibility tree, so you do not need to add aria-hidden="true" or tabindex="-1"
  5. All interactive elements must have an accessible name All interactive components must expose their name (label), role (what it is), state (for example, checked, expanded), and properties (for example, value) programmatically to assistive technologies.

Conclusions

So far, I've learned that ARIA is a powerful tool for making web applications more accessible, but it should be used judiciously. The best practice is to use native HTML elements and attributes whenever possible, and only use ARIA when necessary to enhance accessibility. I also learned that ARIA is not a replacement for semantic HTML; it's meant to complement it.

I've also learned that ARIA is not a one-size-fits-all solution. Different roles, states, and properties are needed for different components, and it's important to understand how they work together to create a seamless experience for users using assistive technologies. I also learned that ARIA is not just about adding attributes to elements; it's about understanding the context in which those elements are used and how they interact with each other.

ARIA is a topic I've been looking forward to exploring for a while now, and I'm glad I've finally reached that point. However, there doesn't seem to be one single, dedicated resource—there are multiple. I started with MDN's WAI-ARIA basics (which I've added to the resources section). It explains the problem ARIA was created to solve and introduces some foundational concepts.

Next, I read W3C's Using ARIA document, which focuses on how to properly use ARIA in HTML. I also went through 100 Days of A11y, and it felt reassuring to see that Amy (the creator of 100 Days of A11y) also had a slow start with the ARIA documentation due to its structure (So I'm not alone). Her post also nicely ties in how the Robust principle of WCAG connects to ARIA.

And I'll end this post just like she did:

Do not use ARIA if you don't have to... use semantic HTML first

Resources