Tagging And Structure In ARIA

Overview

In this lesson, you will continue exploring the basics of the Accessible Rich Internet Applications (ARIA) standard, with a focus on how structure affects accessibility. Assistive technologies rely on well-structured content to support effective navigation and comprehension. Using appropriate tags and elements, such as headings, lists, landmarks, and tables, helps ensure your content is organized in a clear and meaningful way.

Goals

You have the following goals for this lesson:

• Understand how document structure supports accessibility
• Learn how semantic HTML can convey meaning and relationships between elements
• Identify common structural issues that affects screen reader or keyboard access
• Compare the use of semantic HTML versus ARIA for conveying structure

Warm up

In previous lessons, you learned that structure plays a key role in how screen readers convey information. Now, consider this: if ARIA changes the meaning or role of elements on a page, how might that affect features like the Rotor on iOS tablets, Quick Nav on Mac desktops, or Browse Mode in NVDA? Think about how these navigation tools rely on meaningful structure, and what might happen if that structure is altered or unclear.

Vocabulary

You will be learning about the following vocabulary words:

Web Content Accessibility Standards

This lesson covers the following standards:

• WCAG 2.2 - 1.1.1 Non-text Content
• WCAG 2.2 - 1.3.1 Info and Relationships
• WCAG 2.2 - 2.1.1 Keyboard
• WCAG 2.2 - 4.1.2 Name, Role, Value

Explore

In the last lesson you were introduced to what an ARIA role is and a few types of roles you may encounter. Remember that ARIA roles describe what an element is and adds semantic meaning to it. There are two more categories of ARIA roles that can help manage accessibility. Document Structure roles convey structure and organization and Landmark roles identify high-level regions of a web page for navigation and orientation.

Document Structure Roles

Document Structure roles give a description for a section of content. These roles are meant to show relationships and organization of content. Assistive technologies make use of these roles to give more information about the structural context of the elements. These roles might not add functionality, but they cover common usage patterns. For example, if an accessibility device comes across a toolbar, they might be familiar with toolbars and thus change the user interface, in any number of ways for any number of different kinds of people with any number of disabilities.

Here are some of the Document Structure roles that have no native HTML equivalents:

Modern HTML has a variety of tags that cover a lot of structure roles ARIA has to offer. The roles still exist and can be used but for the following roles there is an HTML equivalent that should be used instead:

Headings

Headings provide a clear outline of content, allowing users to scan and understand the structure of a page. Screen readers often rely on heading levels (e.g., <h1> through <h6>) to generate an overview of the page and enable quick navigation. Proper heading hierarchy is essential, skipping levels or using headings purely for visual styling can disrupt accessibility.

Lists

Lists group related items together, helping users interpret information more efficiently. Whether ordered (<ol>) or unordered (<ul>), lists communicate structure to assistive technologies and maintain consistency in content presentation. Avoid using visual spacing or symbols in place of semantic list elements to ensure content remains navigable and meaningful.

Tables

Tables are a visualization tool and used widely across the web. Because of this, screen readers give tables extra affordances that allow users to navigate them easier and read out relevant information about an individual cell. They are mentioned here because they require a small amount of care with tagging.

The tags related to tables are examples of Document Structure roles that add meaning to cells by describing the relationships between cells and where they fit in the structure. Here is an example of a bad HTML table:

<table>
  <tr>
    <td>Product</td>
    <td>Price</td>
    <td>In Stock</td>
  </tr>
  <tr>
    <td>Laptop</td>
    <td>$999</td>
    <td>Yes</td>
  </tr>
  <tr>
    <td>Monitor</td>
    <td>$199</td>
    <td>No</td>
  </tr>
</table>

If rendered in the browser, although it might look fine visually with this structure, these tags could negatively impact the experience of a user that is using a page's hidden structure. It is common for the first row of a table to be the header cells that describe the cells below them. For a screen reader to provide this additional information to a user, the table needs to be marked up correctly. Here is an example of a correctly formatted HTML table:

<table>
  <thead>
    <tr>
      <th scope='col'>Product</th>
      <th scope='col'>Price</th>
      <th scope='col'>In Stock</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Laptop</td>
      <td>$999</td>
      <td>Yes</td>
    </tr>
    <tr>
      <td>Monitor</td>
      <td>$199</td>
      <td>No</td>
    </tr>
  </tbody>
</table>

Now this table has a proper header section with <th> elements that also describe how they are headers for a column and not a row. And now the body and header section are properly sectioned. The cells and rows now have a specified relationship. For example the properly formatted table could be read row by row by a screen reader like ‘Product: Laptop, Price: $99, In Stock: Yes.’ As a reminder, many types of accessibility tools use structure, but the choice becomes aurally obvious in a screen reader.

For tables, the native HTML elements cover enough that you should not need to use the associated ARIA roles to make a native HTML table fully accessible. Here are some of the elements you can use:

Landmark Roles

Landmark roles are less fine grained than Document Structure roles. These roles identify a high-level region of a web page. Landmarks allow screen reader users to jump quickly to major parts of a page. A lot of these regions typically only show up once per page and these semantic regions then get exposed in the accessibility tree. The accessibility tree, typically stored in the computer's operating system, is a location where all accessibility devices gather information from. How it works is complex and varies in its implementation. For web developers, it is kind of similar to working in the DOM, but usually much more low level and with roles that are mapped at the operating system level and generally less the web level.

When using landmark roles, it is important to apply them correctly to maintain clarity and consistency for assistive technology users. Remember that roles like main and banner should appear only once per page to prevent confusion, while others like navigation can appear multiple times as long as they are clearly distinguished. To help users differentiate between similar landmarks, especially when there are multiples of the same type, you can use attributes like aria-label or aria-labelledby to give each region a unique, descriptive name. For example, labeling different navigation areas as ‘Main Menu’ and ‘Footer Links.’ This ensures screen reader users can easily understand the purpose of each section and move between them efficiently.

Main

A common landmark is main (<main>), and it identifies the primary content of a page, excluding headers, footers, and sidebars. This allows users to bypass repetitive content and focus directly on the core material. There should be only one main region per page to maintain clarity and avoid confusion.

Navigation

Another common landmark role is navigation (typically implemented as <nav>), it identifies a section of the page containing links to other areas or pages. This helps users quickly locate site menus or other navigational aids using screen reader region shortcuts or rotor features. Each page can have multiple navigation landmarks, but they should be clearly labeled to differentiate them.

Widget Roles

As a reminder from the previous lesson, widget roles describe interactive components like buttons, sliders, and dialogs. These roles provide essential information about how users can interact with elements. They are especially important when native HTML elements are not used or when behavior extends beyond standard controls.

Application

It might be the case that you have created a web experience that is more like a desktop application than a normal web page. There could be a number of interactions and commands where navigating by headers or jumping to landmarks does not work with this application and would be harder for screen reader users to use. That is where the ARIA widget role application comes into play. This role is essential, dangerous, confusing, messy, confusing, inconsistent, and so many other things. To say the least, while it does have use and it is good to know about it, try to avoid using it unless you absolutely know what you are doing. Also, be aware that no matter how you use it, others will likely tell you that you are doing it wrong.

The application role signals to a screen reader that a region of the page should be treated differently and to not provide traditional screen reader affordances. This gives developers finer control over keyboard interactions and focus management in that region. Or at least all of that is true in theory. In practice, it never really works out and again considerable caution and ample testing is necessary if you believe you need this role.

There also exists the aria-roledescription attribute which can be added to custom widgets to change how a screen reader expresses the name of that role. Take this code example:

<div role='application' aria-roledescription='Block' aria-label='My Component'>
    My Component
</div>

Without the role description a screen reader would vocalize this as ‘application, My Component’. The word application does not really give the user much information. The role description gives you a way to override the name to something you as a developer would find more helpful. For this example it could be read as ‘Block, My Component’ and in the context of your own application could be more useful for the screen reader experience.

Because encountering an element with role='application' can be disruptive to the screen reader experience, it is a role to be used cautiously. Screen readers lose what is known as the virtual cursor and non-interactive elements like images or paragraphs cannot be reached. Certain shortcut keys screen readers add to navigate web pages stop working so those keys are opened up to be used by your application. Because of this, unfortunately results you get using this role may vary.

An incorrectly applied or misused role='application' could be detrimental for the usability of a site for a screen reader user. So the implementation and result can vary between system and assistive technology. For example, on mobile devices, the major screen readers Talkback and VoiceOver tend to ignore the role and operate as if it was not there. As such, it is important to test on various platforms when attempting to use this role. Even though the role might not always work as expected, sometimes it is useful to try to get a screen reader to relinquish control and let the developers try to make a more accessible experience than might have not otherwise been possible. Put simply, the platforms can sometimes be a real hindrance to accessibility, even with good intentions, and thus the application role is an optional tool to use in these cases.

Engage

Visual layouts can mislead you into thinking that assistive technologies can agree on its structure. For this activity you will be given a broken table that with the right styling might look fine but is missing all of the semantic structure. Your goal is to fix it.

Directions

Below are some tables that might resemble a grid of data. It has no structure and only uses one type of element. Your job is to turn this into a screen reader friendly table using either the native HTML tags and ARIA properties as you see fit. For each table, do the following:

• Imagine what it would say in your head as navigating
• Actually traverse the table with various technologies and check
• Fix the table and recheck

To do this, you can either copy paste the HTML into an HTML file and open it in a browser or copy the code and use an online HTML editor like W3Schools TryIt Editor.

First, take the following table code:

<div class='table'>
  <div class='caption'>Users</div>
  <div class='row'>
    <div class='cell'>Name</div>
    <div class='cell'>Email</div>
    <div class='cell'>Status</div>
  </div>
  <div class='row'>
    <div class='cell'>Jane Doe</div>
    <div class='cell'>[email protected]</div>
    <div class='cell'>Active</div>
  </div>
  <div class='row'>
    <div class='cell'>John Smith</div>
    <div class='cell'>[email protected]</div>
    <div class='cell'>Inactive</div>
  </div>
</div>

As part of your fixes, ensure that the header cells are tagged appropriately and that each cell is properly associated with its header. Once you have finished fixing the first table, try to correct the next table. Remember that cells are sometimes associated with more than one header:

<div class='table'>
  <div class='caption'>Sales info</div>
  <div class='row header'>
    <div class='cell'></div>
    <div class='cell'>Monday</div>
    <div class='cell'>Tuesday</div>
    <div class='cell'>Wednesday</div>
  </div>
  <div class='row'>
    <div class='cell'>North</div>
    <div class='cell'>$1,200</div>
    <div class='cell'>$1,450</div>
    <div class='cell'>$1,300</div>
  </div>
  <div class='row'>
    <div class='cell'>South</div>
    <div class='cell'>$980</div>
    <div class='cell'>$1,100</div>
    <div class='cell'>$1,050</div>
  </div>
  <div class='row'>
    <div class='cell'>East</div>
    <div class='cell'>$1,500</div>
    <div class='cell'>$1,600</div>
    <div class='cell'>$1,550</div>
  </div>
</div>

Next Tutorial

In the next tutorial, we will discuss Desktop Accessibility Inspectors, which describes how to manually examine element accessibility properties and structure using a desktop inspector.