Less ARIA, More Accessibility: Documenta11y’s Guide to Cleaner Web Content

ARIA (Accessible Rich Internet Applications) attributes are a powerful tool for bridging the gap in native HTML, but they can sometimes do more harm than good when used excessively or not applied accurately. At Documenta11y, our mission is to pioneer digital accessibility so that your content is both accessible and clean. In this post, we look at the delicate balance between using ARIA when necessary and keeping your markup simple and rich with the intended meaning.

The Purpose of ARIA

The accessibility of dynamic web applications like those that use complex interactions – menus, custom widgets, and live content updates – is the focus of ARIA’s creation. HTML alone cannot handle these cases, but roles, states, and properties in ARIA can. For instance, ARIA roles can identify an element as a button, even if it’s not a native <button> element, and ARIA states and properties can dynamically communicate changes (e.g., whether a form field is invalid). WebAIM reminds us, though, that ARIA is meant to supplement, not replace, what we can do with native HTML. Using ARIA when we have native semantics available can be harmful. It can lead to all kinds of unintended side effects, making things less accessible for users with disabilities, not more accessible.

The Five Rules of Effective ARIA Use

The ARIA specification sets forth best-practice guidelines for its application. Let’s go over the key points:

Use Native HTML First

ARIA is unnecessary if the required semantics are already provided by a native HTML element. For example, don’t add role=”button” to a <div>; use a real <button> element instead. When you use native HTML elements according to their intended purpose, flavoring them with ARIA roles and properties becomes redundant. A browser and assistive technologies built in the way HTML was meant to be understood take care of the “extra intervention” with which some authors insist on burdening ARIA.

Do Not Change Native Semantics Unnecessarily

HTML elements possess built-in behaviors and meanings. Using ARIA to change these (for example, by adding a role attribute to modify an element’s function) can confuse screen readers and their users if not done with careful consideration.

Ensure Keyboard Accessibility

Interactive controls that are enhanced with ARIA must be keyboard accessible. Not only must they receive focus (often via tabindex=”0″), but they must also support the correct keyboard interactions as defined in the ARIA design patterns.

Maintain Proper Semantics and Visibility

Interactive elements must have clear semantics. For instance, if an element is focusable, it must not be hidden with CSS or marked with aria-hidden=”true”, which would remove it from the accessibility tree even though it remains in the tab order.

Provide an Accessible Name for All Interactive Elements

Every control should have a descriptive label. Whether you use native HTML <label> elements or ARIA attributes like aria-label or aria-labelledby, it’s crucial that the element’s purpose is communicated effectively to screen reader users.

These rules are detailed on the WebAIM site, which serves as an excellent reference point for best practices in ARIA usage.

The Problem with ARIA Overuse

If ARIA is overused or if used incorrectly can cause what documenta11y refers to as, “bloated accessibility.” Here are a few issues:

Redundant Markup:

Using ARIA on top of elements that already have semantic meaning can create conflicts. A specific example where this type of extra complexity should not exist is, if you take a unordered list, wrap it in an extra div and give it a navigation role, you really could have just used a <nav>.

Loss of Native Functionality:

If ARIA is being used to override what works natively in HTML, some essential functionality (such as auto-focus management or native keyboard handling) may be lost. This can hinder the experience of people who depend on assistive technology.

Increased Maintenance Burden:

Having additional ARIA attributes means maintaining more code. With the evolution of websites, it becomes crucial that these attributes continue to reflect current structure and behavior.

How to Improve Accessibility with Web Remediation

Excessive use of ARIA is one of the main accessibility issues. This is a user-friendly guide to help you optimize your markup and make your website accessible.

1) Begin with a thorough audit

Use technologies available online to do an automatic audit before making any code modifications. These tools swiftly identify problems that could trip screen readers, like redundant ARIA roles or missing labels. To catch anything the tools might overlook, combine this with a brief manual examination of your code.

2) Use Native HTML First

Native HTML elements have built-in accessibility integrated into them. For example, use <button> for actions instead of a <div> with role=”button”. This way, you leverage browsers’ default behaviors and avoid the extra overhead that ARIA might introduce.

3) Follow the ARIA Rules

Follow these basic principles

• Native is Best: If HTML already provides the needed semantics, don’t add ARIA.
• Don’t Overwrite: Avoid changing an element’s default meaning unless you have a strong reason.
• Keep It Keyboard Friendly: Make sure interactive elements can be navigated and activated using just the keyboard.
• Make It Visible: Don’t hide interactive elements with aria-hidden=”true” if users need to interact with them.
• Label It Clearly: Every interactive element should have a clear, descriptive name using either native labels or ARIA attributes like aria-label.

4) Clean Up and Test

Remove any ARIA attributes that aren’t needed. For example, if you’ve wrapped a list inside a <div role=”navigation”> when a <nav> element would do, swap it out for the native element. Then, test your changes with a screen reader and try navigating the site with just your keyboard.

5) Make It Part of Your Workflow

Incorporate accessibility checks into your regular development process.

Conclusion

These are the simple steps that make your website accessible and manageable. As a reminder, good accessibility is about making things clear and simple, so use native HTML where possible and ARIA only when it’s necessary. For an effortless on-the-go digital accessibility and document remediation solution, use documenta11y by visiting www.documenta11y.com.