Accessibility Showdown: HTML5 vs ARIA – Which One Should Be the Priority?

HTML5 vs ARIA

The title might suggest a conflict, but HTML5 and ARIA actually complement each other.

In this article, we will explore the use of HTML5 and ARIA in accessibility design. We'll discuss their roles, and explain how, where, and when to use each one to create an accessible product effectively.

If you need custom support for your project, we are here to help.

Get Support

What is HTML5?

To keep it simple, HTML5, also known as semantic HTML, is the fifth and latest major version of the HyperText Markup Language (HTML). It was designed to improve the language with support for the latest multimedia while keeping it easily readable by humans and digital devices.

HTML5 introduced a special syntax known as semantics, specifically aimed at improving the quality and accessibility of web pages.

What is ARIA?

ARIA, which stands for Accessible Rich Internet Applications, is a set of specifications developed by the World Wide Web Consortium (W3C). ARIA is designed to improve the accessibility of web content, especially for people who rely on assistive technologies.

ARIA introduces additional attributes that can be added to HTML elements to provide extra information about the roles, states, and properties of user interface elements, thereby enhancing the accessibility and usability of web pages.

Is ARIA in competition with HTML5?

ARIA is not a competing technology to HTML5, but rather a set of attributes that works alongside HTML5 to improve the accessibility of web content, especially for people who rely on assistive technologies like screen readers.

Before the release of HTML5, classical HTML relied heavily on ARIA attributes to make them accessible. However, HTML5 reduced this reliance by introducing semantics that naturally define the roles of different sections of code blocks.

Some of the HTML5 semantics are:

  1. <article>: Represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable.
  2. <section>: Defines a section in a document, such as chapters, headers, footers, or any other sections of the document.
  3. <nav>: Defines a set of navigation links, such as menus and tables of contents.
  4. <aside>: Represents a section of the document with content indirectly related to the main content. This is often used for sidebars.
  5. <header>: Specifies introductory content, typically a group of introductory or navigational aids.
  6. <footer>: Defines a footer for a section or page, typically containing information about the author, copyright information, links to related documents, etc.
  7. <main>: Represents the dominant content of the <body> of a document, excluding content that is repeated across web pages such as sidebars, navigation links, copyright information, site logos, and search forms.
  8. <figure>: Specifies self-contained content, like illustrations, diagrams, photos, code listings, etc. It is often used with the <figcaption> element.
  9. <figcaption>: Defines a caption or legend for a <figure> element.
  10. <mark>: Represents text highlighted for reference purposes, due to its relevance in another context.
  11. <time>: Represents a specific period in time.
  12. <progress>: Represents the progress of a task, typically displayed as a progress bar.
  13. <output>: Represents the result of a calculation or user action.
  14. <details>: Used as a disclosure widget from which the user can obtain additional information or controls. Often used with the <summary> element.
  15. <summary>: Specifies a summary, caption, or legend for a <details> element.
  16. <dialog>: Represents a conversation or a part of an application where the user can enter information, such as a dialog box or window.
  17. <address>: Provides contact information for the author or owner of a document or an article.

These semantic elements help define the different parts of a web page, making it easier for assistive technologies to understand and navigate the content.

There are instances where these HTML5 semantics alone can sufficiently make a webpage accessible without the need for ARIA enhancements. However, there are also more complex situations where HTML5 semantics alone may not be sufficient to aid accessibility. This is where ARIA shines. With sprinkles of ARIA attributes, such complex scenarios can be made accessible.

In the next section, we'll quickly demonstrate 3 examples of using pure semantics and their corresponding ARIA equivalents. We will also demonstrate with 2 examples how both can be deployed to make a complex or dynamic content more accessible.

Please note that pure semantic usage for simple code should be the first choice; the ARIA equivalent is only recommended if your codebase relies on older versions of HTML.

Pure Semantic Example 1

In pure semantic HTML5, you can create a navigation menu using the <nav>, <ul>, and <li> elements without any need for ARIA. Here's an example code snippet:

The following code snippet shows a navigation menu using a nav semantic:


<nav>
    <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">About Us</a></li>
        <li><a href="#">Services</a></li>
        <li><a href="#">Contact</a></li>
    </ul>
</nav>

ARIA Equivalent Example 1

For compatibility with older HTML versions, which mostly use "<div>" tags, you can use ARIA roles to define the navigation menu. Here's how you can modify the code with ARIA attributes:

The following code snippet shows a navigation menu using a div element:


<div role="navigation">
    <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">About Us</a></li>
        <li><a href="#">Services</a></li>
        <li><a href="#">Contact</a></li>
    </ul>
</div>

Pure Semantic Example 2

For creating interactive buttons using pure HTML5 semantics, we would use the <button> element without any ARIA attribute. Here's an example:

The following code snippet shows a button element constructed with semantic html:


<button type="button">Click me!</button>

ARIA Equivalent Example 2

For compatibility with older HTML versions, which mostly use "<div>" tags, you can use ARIA roles to define buttons. Here's how you can make the code accessible with ARIA attributes:

The following code snippet shows a div element acting as a button:


<div role="button">Click me!</div>

Pure Semantic Example 3

In pure HTML5 semantics, we can use specific elements to denote landmark regions in our document without the need for ARIA. Here's an example:

The following code snippet shows a basic webpage structure constructed with semantics only:


<header>
    <h1>Website Header</h1>
</header>

<main>
    <h2>Main Content</h2>
    <p>This is the main content of the website.</p>
</main>

<nav>
    <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">About Us</a></li>
        <li><a href="#">Services</a></li>
        <li><a href="#">Contact</a></li>
    </ul>
</nav>

<aside>
    <h2>Sidebar</h2>
    <p>This is the sidebar content.</p>
</aside>

<footer>
    <p>Footer information goes here.</p>
</footer>

ARIA Equivalent Example 3

For older HTML versions or specific accessibility needs, we can use ARIA roles to define landmark regions. Here's how we modify the code:

The following code snippet shows a webpage structure using ARIA roles:


<div role="banner">
    <h1>Website Header</h1>
</div>

<div role="main">
    <h2>Main Content</h2>
    <p>This is the main content of the website.</p>
</div>

<div role="navigation">
    <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">About Us</a></li>
        <li><a href="#">Services</a></li>
        <li><a href="#">Contact</a></li>
    </ul>
</div>

<div role="complementary">
    <h2>Sidebar</h2>
    <p>This is the sidebar content.</p>
</div>

<footer role="contentinfo">
    <p>Footer information goes here.</p>
</footer>

Using ARIA to Compliment HTML5

HTML5 and ARIA complement each other well, especially in situations where HTML5 alone falls short. Their combined strength is most evident in complex and dynamic scenarios. We'll showcase this synergy with two examples.

ARIA + HTML5 Example 1

An accordion is a UI component that allows users to expand and collapse sections of content.

In this example, we have an accordion with three sections. Each section consists of a tab (role="tab") and a corresponding panel (role="tabpanel"). The ARIA roles and attributes are set appropriately to ensure accessibility. The <section> element wraps the entire accordion component and provides a semantic context within the document.

The following code snippet shows an accordion using ARIA roles:


<section aria-labelledby="accordion-heading">
    <h2 id="accordion-heading">Accordion Heading</h2>
    <div role="tablist">
        <div role="tab" aria-selected="true" id="section1-tab" aria-controls="section1-panel" tabindex="0">
            Section 1
        </div>
        <div role="tabpanel" aria-labelledby="section1-tab" id="section1-panel" aria-hidden="false">
            Content of Section 1
        </div>

        <div role="tab" aria-selected="false" id="section2-tab" aria-controls="section2-panel" tabindex="-1">
            Section 2
        </div>
        <div role="tabpanel" aria-labelledby="section2-tab" id="section2-panel" aria-hidden="true">
            Content of Section 2
        </div>

        <div role="tab" aria-selected="false" id="section3-tab" aria-controls="section3-panel" tabindex="-1">
            Section 3
        </div>
        <div role="tabpanel" aria-labelledby="section3-tab" id="section3-panel" aria-hidden="true">
            Content of Section 3
        </div>
    </div>
</section>

ARIA + HTML5 Example 2

A modal dialog is a popup window that requires user interaction before returning to the main application. Here's how you can create an accessible modal dialog:

The following code snippet shows a modal dialog using ARIA roles:


<div role="dialog" aria-modal="true" aria-labelledby="modal-title" tabindex="-1">
    <div role="document">
        <h2 id="modal-title">Modal Title</h2>
        <button aria-label="Close" onclick="closeModal()">X</button>
        <p>Modal content goes here.</p>
        <button onclick="confirmAction()">Confirm</button>
    </div>
</div>

Let’s wrap it up!

In a nutshell, HTML5 is the foundation of modern web development and is sufficient for designing basic web pages. However, when dealing with more complex or dynamic content, ARIA can be an invaluable additional enhancement for managing accessibility and improving the user experience.

FAQs

ARIA, which stands for Accessible Rich Internet Applications, is a set of specifications developed by the World Wide Web Consortium (W3C). ARIA is designed to improve the accessibility of web content, especially for people who rely on assistive technologies.

ARIA introduces additional attributes that can be added to HTML elements to provide extra information about the roles, states, and properties of user interface elements, thereby enhancing the accessibility and usability of web pages.

Use semantic tags instead of div tags with ARIA roles. Only use ARIA attributes when they are absolutely necessary.

Start Building Accessible Solutions Today

We are an agency that knows our onions. Let us transform your rigid websites into highly accessible fortresses.

HIRE US

Written by:

Samuel Enyi

Samuel Enyi

Sammi is a seasoned accessibility expert with over a decade of experience. He holds several professional certifications in web development, a Trusted Tester certification from the U.S. Department of Homeland Security, and a Bachelor's degree in Electrical-Electronics Engineering. Sammi excels at managing client accessibility needs across multiple platforms and enjoys simplifying complex problems.

Ramib Abeeb

Ramib Abeeb

Ramib is a Computer Science graduate who brings a wealth of experience to the table. He is passionate about supporting individuals with disabilities, dedicating his expertise to making their work environments more accessible and user-friendly.

Olivera Peter

Olivera Peter

Olivera is a meticulous proofreader and editor with a bachelor's degree in linguistics. She ensures our blog remains error-free with her keen eye for detail. Outside of work, she enjoys traveling and playing tennis.

Related Pages:

  1. Building Accessible Data Tables: Best Practices
  2. Simplified Guide to WCAG SC 1.1.1: Non-text Content for Document Accessibility
  3. Simplified Guide to WCAG SC 1.1.1: Non-text Content for Web Accessibility
  4. Principal Accessibility Software Engineer at Splunk
  5. Accessibility Audits: A Vital Step in SEO Optimization

Filed under: Articles - @ 19:53

Tags: , ,