Semantic HTML & ARIA: Accessibility Enhancement Without the Overkill

When it comes to building inclusive web experiences, semantic HTML is your strongest ally. Using the right elements for their intended purpose does more than just communicate structure, it automatically provides browsers and assistive technologies with essential information such as an element’s role, state, and accessible name. This HTML-first approach unlocks built-in accessibility features (e.g. keyboard navigation, screen reader support) and lays a solid foundation for further enhancements.

However, HTML alone does not cover every scenario, especially when working with some custom components. That is where ARIA (Accessible Rich Internet Applications) comes in. ARIA roles, states, and properties plug the semantic gaps by embedding additional metadata into the accessibility tree, ensuring that every interactive element behaves as it should for all users. We will dive into both semantic HTML and ARIA to show how they work together to create truly accessible web experiences.

Semantic HTML Elements

A semantic element is an element that has a meaning or role. Semantic element describes its function and role to the browser and search engine. Using semantic HTML means writing markup that reflects the meaning of your content, in other words using the right elements for the right job. For example, using <h1> for a main heading, using the <nav> for navigation links, <button> for a clickable button and so on. This matters a lot for accessibility as semantic tags come with built-in meaning and behaviour that the browser, search engine and assistive technologies like screen readers understand. Without semantic elements, web contents might appear difficult for screen readers to identify key parts like headings, buttons, or inputs amongst others.

When developing web interfaces, utilizing native HTML elements offers significant accessibility advantages. These elements inherently provide:

1. Semantic Information: Native elements automatically convey their role, state, and accessible name to assistive technologies through the accessibility tree. This enables screen readers and other assistive tools to interpret and interact with the element effectively. For example, role Identifies the type of element (e.g checkbox, button).

<label>
  <input type="checkbox" checked>
  Subscribe to newsletter
</label>

• Role: The <input type=”checkbox”> element inherently has the role of checkbox, indicating its function to assistive technologies.

• State: The checked attribute denotes the checkbox’s state as selected. Assistive technologies, like screen readers, announce this state to users.

• Accessible Name: The text “Subscribe to newsletter” associated with the <label> provides an accessible name for the checkbox. This ensures that screen readers can convey the purpose of the checkbox to users.

1. Keyboard Interactivity: These elements are designed to be operable via keyboard by default. For instance, users can navigate to a checkbox using the tab key and toggle its state with the spacebar. This built-in functionality ensures consistent and predictable behavior across different browsers and operating systems.

<label>
  <input type="checkbox" checked>
  Subscribe to newsletter
</label>

• Keyboard Navigation: Users can press the tab key to focus on the checkbox. Once focused, pressing the Spacebar toggles its state between checked and unchecked.

• Built-in Functionality: Native HTML elements like <input type=”checkbox”> come with default keyboard behaviors, eliminating the need for additional JavaScript to handle basic interactions.

• Consistent Behavior: This standardized interaction ensures that users relying on keyboards, including those using assistive technologies, have a predictable and consistent experience across various platforms.

The Power of ARIA

When semantic HTML does not fully capture your design’s functionality, for instance, when implementing a custom carousel, tab interface, or a progress bar, then ARIA might be the next best option. ARIA lets you annotate elements with roles, states, and properties to expose their purpose and behavior to assistive technologies.

<div role="tablist" aria-label="Programming Languages">
  <button role="tab" aria-selected="true" aria-controls="panel1" id="tab1">JavaScript</button>
  <button role="tab" aria-selected="false" aria-controls="panel2" id="tab2">Python</button>
  <button role="tab" aria-selected="false" aria-controls="panel3" id="tab3">Rust</button>
</div>

<div id="panel1" role="tabpanel" aria-labelledby="tab1">
  <p>JavaScript is widely used for web development.</p>
</div>
<div id="panel2" role="tabpanel" aria-labelledby="tab2" hidden>
  <p>Python is popular in data science and automation.</p>
</div>
<div id="panel3" role="tabpanel" aria-labelledby="tab3" hidden>
  <p>Rust is known for performance and memory safety.</p>
</div>

• role=”tablist”: declares the container holds a group of tabs.

• role="tab": defines each clickable tab.

• aria-selected: indicates which tab is currently active.

• aria-controls: links a tab to its content panel.

• role="tabpanel": defines each panel.

• aria-labelledby: ensures screen readers associate the panel with the corresponding tab.

Note that we will have to handle keyboard interactions (arrow keys, tab, enter/space) and panel visibility in JavaScript to complete the widget’s accessibility.

Rules of ARIA

We have explained ARIA and have given examples of its use case, however, it comes with some fundamental rules as outlined by the W3C which is the organization that regulates the web and they are as follows;

1. Don’t Use ARIA: Surprising as it might sound, the first rule is a caveat, only use ARIA when it is really necessary. This means as long as there is a native HTML element that can do the job, then do not use ARIA. A popular example will be trying to design a div to act as a button, this is very frowned at and would require a lot to turn a div into achieving the built-in functionalities of a button.

2. Do Not Change Native Semantics: This rule further emphasizes that native HTML is still the first and most advisable. However, it is not advisable to change the original meaning of native semantics in order to achieve a behavior.

3. ARIA Controls Must be Keyboard Usable: If we create a widget that a user can click, tap or scroll, such a widget must respond to standard keystrokes or a combination of keystrokes. If we can’t perform the action using the keyboard then its not inline with the ARIA rule.

4. Keep Interactive Elements Visible: Never hide focusable elements. For example do not use aria-hidden=”true” on elements like buttons or links.

5. All Interactive Elements Must Have an Accessible Name: You must provide a name/label to every interactive element.

Conclusion

Semantic HTML and ARIA are not adversaries but partners. HTML builds the accessible foundation while ARIA fills in only where needed. By favoring native elements, following W3C patterns, and avoiding redundant roles, you will create interfaces that are robust, maintainable, and truly accessible without the overkill.