WAI-ARIA

WAI-ARIA stands for Web Accessibility Initiative - Accessible Rich Internet Applications. It is a technical specification published by the World Wide Web Consortium (W3C) that specifies how to increase the accessibility of web pages, particularly when dynamic content and user interface components developed with Ajax, HTML, JavaScript, and related technologies are used.

Web accessibility (often referred to as “a11y”) is vital for creating an inclusive digital world for all users, regardless of their abilities. This post provides a few notes on accessibility considerations and best practices.

Accessibility Tree

The Accessibility Tree is a hierarchical representation of an application’s user interface, specifically designed for assistive technologies like screen readers. While derived from the Document Object Model (DOM), the Accessibility Tree focuses on the semantic information and skips over irrelevant content and styling details. This ensures that assistive technologies present only the essential and meaningful parts of a web page to users.

Simplified Structure: Unlike the DOM, which includes every element (including non-semantic elements like div and span), the Accessibility Tree only contains elements that are important for conveying the page’s structure and meaning.
Influence of ARIA: ARIA attributes can manipulate the Accessibility Tree, overriding default roles, states, and properties. This allows developers to create custom widgets that are still accessible.
Dynamic Updates: As the content and UI change (like in single-page applications), the Accessibility Tree can be dynamically updated to reflect those changes, ensuring that users of assistive technologies receive the most current information.

ARIA Attributes

ARIA attributes provide a way to enhance the accessibility of web content, especially in cases where traditional HTML attributes fall short. These attributes communicate additional information about an element’s role, state, and behavior to assistive technologies, ensuring a comprehensive user experience for individuals with disabilities.

Purpose of ARIA Attributes:

Convey Additional Information: ARIA attributes give more context to elements, describing properties or states that aren’t otherwise obvious.
Indicate State Changes: Many ARIA attributes represent dynamic states (like aria-pressed for a toggle button) and are updated in real-time as user interactions occur.
Label and Describe Elements: When visual labels or descriptions are insufficient or missing, ARIA attributes like aria-label and aria-describedby step in to provide the necessary context for screen readers.
Build Accessible Relationships: Some ARIA attributes establish relationships between elements, even when they aren’t adjacent in the DOM, such as aria-controls or aria-labelledby.

Common ARIA Attributes:

aria-hidden: Indicates whether an element is visible or not to assistive technologies.
aria-live: Communicates how assistive technologies should respond to changes in content within a live region.
aria-expanded: Signifies if a collapsible element, like a dropdown, is currently expanded or collapsed.
aria-required: Specifies if a form input is mandatory before form submission.

Key Takeaways:

Enhance, Don’t Redefine: ARIA attributes should be used to enhance native semantics, not to replace or redefine them.
Dynamic Updates: Ensure that any changes in an element’s state or properties are reflected in real-time in their corresponding ARIA attributes.
Test with Actual Tools: To verify the efficacy of ARIA attributes, test the content using screen readers and other assistive tools.

ARIA Roles

ARIA roles are attributes added to elements in your HTML to specify their role (or purpose) in the interface, especially when that role might not be evident or is different from their default semantic meaning.

Main Types of ARIA Roles:

Landmark Roles: These roles help users navigate different sections of the page. Examples include:

banner for site-oriented content like a logo or site title.
navigation for navigation components.
main for the primary content of the page.
contentinfo for metadata or information about the site.

Widget Roles: Describe common interface elements like sliders, tabs, and tooltips. Examples include:

button
checkbox
dialog
progressbar

Document Structure Roles: Indicate structural elements within content or containers. Examples include:

article
heading
list
grid

Live Region Roles: Inform assistive technologies about parts of the page expected to update as a result of user actions or automatic changes. These include:

alert
log
status
timer

Why Use ARIA Roles?

Semantic Enhancement: Some custom components don’t have built-in semantics that can be understood by assistive technologies. ARIA roles fill in these semantic gaps.
Improved Screen Reader Experience: ARIA roles guide screen reader output, ensuring users hear more meaningful and context-rich feedback.
Custom Component Clarification: For non-standard UI elements that might be ambiguous or unclear, roles provide clarity on their purpose or behavior.

Best Practices:

Don’t Override: Avoid changing the role of an element with a clear native semantic meaning unless necessary. For example setting role="main" on the main element is bad practice.
Use Supportive Attributes: Many roles work best when combined with other ARIA attributes to define their state or properties.
Stay Up To Date: The ARIA specification evolves. Always refer to the latest version to ensure you’re implementing roles correctly.

Live Regions

Live regions are areas of a web page where content can change without the page reloading. Such regions can be problematic for users who rely on assistive technologies like screen readers, because the content changes may not be communicated to them. When an area of the page receives updates (i.e. a chat window) it’s necessary to signal these updates to screen readers.

`aria-live`

Its primary purpose is to indicate that an area of a web page is a “live region”, where content can change dynamically without the page being reloaded. For users who rely on assistive technologies, such as screen readers, changes in content might go unnoticed. The aria-live attribute helps alert these users to changes as they occur.

Values of aria-live:

off (default): Changes in this region will not be announced by the screen reader unless the user navigates to that region. This is the default value if the attribute is not present.
polite: Changes will be announced by the screen reader at the next available opportunity, such as after the user has stopped typing or after the screen reader finishes speaking its current task. This is typically used for updates that are important but not urgent.
assertive: Changes will be announced by the screen reader immediately, potentially interrupting any current announcements. This should be used sparingly and only for urgent notifications, such as error messages or alerts.

Usage: Imagine a search feature on a website where, as a user types, search results update in real-time below the search box. Using aria-live="polite", a screen reader would announce the updated number of search results once the user stops typing.

For an urgent alert or error message that needs to grab the user’s immediate attention, aria-live="assertive" could be used to ensure the message is announced without delay.

Important Considerations:

Overuse: It’s crucial not to overuse aria-live, especially with the “assertive” value. If changes are announced too frequently or with unnecessary urgency, it can be disruptive and confusing for users.
Complementary Attributes: Other attributes often used in conjunction with aria-live include aria-atomic, which defines whether the entire region or just the changed parts should be announced, and aria-relevant, which indicates what types of changes should be vocalized.

`aria-relevant`

The aria-relevant attribute assists in determining what types of changes should be vocalized.

Values of aria-relevant:

additions: New nodes that are added to the live region should be announced.
removals: Nodes that are removed from the live region should be announced.
text: Changes to the textual content of existing nodes should be announced.
all: Indicates all the above types of changes should be announced. Multiple values can be used by separating them with a space, for example: "text additions". If aria-relevant is not provided, its default value is "additions text", which means that both text changes and node additions will be announced, but not node removals.

The HTML `alt` attribute

The HTML alt attributes primary purpose is to provide a text description for images, ensuring content remains meaningful and accessible, especially for users who rely on screen readers or those with visual impairments.

When is the alt attribute important?

Screen Readers: For visually impaired users, screen readers vocalize the content of a page. When they encounter an image, they’ll read out the alt text, providing context and understanding about the image’s content or function.
No Image Display: If an image fails to load or if images are turned off in a browser, the alt text will display in place of the image, informing users about what should have been there.
SEO Benefits: Search engines use the alt text to understand image content, aiding in better indexing and search relevance.

Best Practices:

Descriptive Text: The alt text should be succinct yet descriptive enough to convey the image’s meaning or function.
Functional Images: For images used as buttons or links, the alt text should describe the action or destination.
Decorative Images: If an image is purely decorative and adds no content value, an empty alt attribute (alt="") should be used. This tells screen readers to skip over the image.

Managing Focus

One critical component of web accessibility is managing focus, particularly for keyboard-only users and those using assistive technologies. Two of the most effective tools for enhancing focus management are the tabindex attribute and skip links.

`tabindex` Attribute

The tabindex attribute specifies the tab order of elements, ensuring a logical and smooth navigation sequence.

Values:

0: The element can be focused and is included in the keyboard navigation sequence, in the order it appears in the DOM.
-1: The element can be programmatically focused (using JavaScript, for example), but isn’t accessible via keyboard navigation.
Positive values (e.g., 1, 2, …): Defines a specific order for keyboard navigation. However, this is considered an anti-pattern as it can disrupt the natural navigation flow and confuse users.

Skip Links

Skip links, also known as “bypass links”, allow users to bypass repetitive content, like navigational menus, and jump directly to the main content or other significant sections of a page. This prevents the need to tab through the same set of links every time a new page loads.

Implementation:

Skip links are typically the first focusable elements on a page. They may initially be hidden and become visible when focused.

<!-- A typical skip link -->
<a href="#main-content" class="skip-link">Skip to main content</a>

<!-- Later in your HTML -->
<div id="main-content">
<!-- Main content goes here -->
</div>

CSS for Skip Links:

.skip-link {
position: absolute;
top: -40px;
left: 0;
background: #FFF;
padding: 10px;
z-index: 100;
}

.skip-link:focus {
top: 0;
}

In the example above, the skip link is positioned off-screen by default. When a user tabs into the page, the skip link gains focus and moves into view, providing a means to skip repetitive navigation and dive right into the main content. You’ll find a skip link on this page if you tab from the top, but don’t tab too fast because there is a built in delay.

Styles

Using CSS attribute selectors to style aria attributes instead of css classes button[aria-pressed="true"]. Use display:none or visibility: hidden to prevent focus on offscreen content.

Touch Size

The ideal minimum touch size for an area is around 48x48dp
The spacing between touch targets should be a minimum of 32dp

Color Contrast

Do not use color alone to convey meaning, i.e. (Error, Success). Color blindness is relatively common affecting 1 in 12 men and 1 in 200 women.

Large text may use a 3:1 contrast
The minimum contrast for paragraph text is 4.5:1
Use the Chrome high contrast extension to verify that everything works well for low vision users.