Oh Accessibility Tree

In the spirit of the holiday season a bit of silliness (and education too) I provide you with Oh Accessibility Tree.

Oh Accessibility Tree – The Song

What is the Accessibility Tree

The accessibility tree is a crucial concept in digital assets that helps make websites more usable for people with disabilities. If you think of a map, which shows landmarks, street names, addresses and other items of interest which help you getting around the accessibility tree is similar in its purpose, making it easier for people with assistive tech navigating around websites and applications.

What does the accessibility tree contain

The accessibility tree contains information about the elements and structure for the website or app.

Typically the accessibility tree includes:

1. Roles. Describes the type of element (e.g., button, link, heading).
2. Properties: Provides information about the element’s characteristics and state (e.g., whether a button is disabled, the level of a heading).
3. Names and Descriptions: Text that identify the element’s purpose or content (e.g., alt text for images, labels for buttons).
4. States: Current status of the element (e.g. whether a checkbox is checked or unchecked, whether a drop-down is expanded or collapsed).
5. Relationships: How elements are related to each other (e.g., which items are part of a menu, parent-child relationships in nested elements).

5 Steps to a Beautiful Accessibility Tree

1. Use heading structures correctly

Headings are often the first way of navigation of a website by a user operating a screen reader as identified in the WebAIM Screen reader survey #9.

Creating correct hierarchy of headings is important as are the use of clear headings. There are guidelines around headings.

• Each web page should have one (and only one) <h1> represent the main topic or title of the page.
• Use headings should usually follow hierarchical order with only some minor exceptions. E.g. <h1> with <h2>, then <h3>. Headings should not skip levels. levels (e.g., don’t go from <h1> to <h3>).

Additional heading properties are:

• Headings should be descriptive and explain the content that follows.
• Text style should not be determine the heading or level. Headings just for styling (e.g., making text big and bold). Should not be used to determine structural headings.
• Balance of text should be considered. Headings should break content into meaningful chunks.

2. Leverage landmarks in Semantic HTML

Landmarks are specific areas of a web page that are identified and labelled to help users navigate more easily, users can jump to content across different landmarks.

Common Landmarks:

• Header: <header> – Contains introductory content or navigational links.
• Main: <main> – Represents the main content of the document.
• Navigation: <nav> – Contains navigation links.
• Footer: <footer> – Contains footer content, such as copyright information.
• Aside: <aside> – Contains content that is tangentially related to the main content.
• Section: <section> – Defines a section of the page, typically with its own heading.
• Article: <article> – Represents a self-contained composition, such as a blog post or news article.

3. Ensure all your form controls are labelled

Controls which are labelled correctly make content easy for a user with assistive tech to perceive the control and understand the purpose of the control. Labels for controls are necessary for both users with or without assistive tech. While some controls may not have text labels, but may use icons (see my blog article: X Marks the spot but never the close button, you needs to have a label!

To understand why it is better to have text labels visible on screen as well as icons) sometimes you would wish the visible label to be different to the accessible label. E.g. if you have multiple “Edit” buttons on a page, you may wish to be more specific and have unique labels for users operating screen readers, such as “Edit contact details”

Without a label how is a user who can not see the visible content understand what your button does? If you have a power switch board without any labels and you want to turn on your lights ow do you know which button to change? It’s the same for users who are blind or have low vision, you need to activate the button and hope it does what you want.

4. Don’t disable your buttons

Disabling buttons on a web page until a pre-condition is met can create a confusing and frustrating experience. Users may struggle to understand what they need to do to be able to activate the button and if the button is not in the accessibility tree, or disabled in the accessibility tree an assistive tech user may be lost in your website and leave.

Remember the important note: A disabled button does not provide feedback. A user that does not understand will leave and you will have one less customer and person engaging with your content.

Alternatives to disabling buttons:

• Provide Clear Instructions: Guide users on what needs to be done to activate the button.
• Use Real-Time Validation: Instead of disabling buttons, provide real-time feedback as users complete the required steps.
• Highlight Missing Information: Clearly indicate what needs to be filled out or selected to activate the button.

5. Ensure you are correctly hiding information

Hiding content, whether it removes items from the accessibility tree or not is fraught with danger. Implemented incorrectly can lead to two big issues

1. You hide information which is needed for people with assistive tech users to operate your site
2. You forget to hide information from assistive tech users which should be hidden (e.g. parts of a form which are only meant to be shown in certain situations. Such as when a user selects “Other” and is prompted to provide more information when it should not be present for other answer options. )

Let’s get technical for a minute…

Misuse of aria-hidden

The aria-hidden attribute is used to hide elements from assistive technologies (including screen readers) but keep them visible on the screen. This can often go wrong, such as if it is used to hide content that is crucial for understanding or interacting with the page. Doing so can make it unusable for users relying on assistive technologies.

Another issues is where non-hidden interactive elements are not visually hidden but are marked with aria-hidden (e.g. if you have used optional hide/show functionality but missed changing when presented to the screen) then will hide them from screen readers and other assistive tech, strongly impacting users.

Example of Misuse and poor code

<div aria-hidden="true">
  <button>Submit</button>
</div>

In this example, the button is hidden from screen readers, making it inaccessible to users who rely on them.

Misuse of role=presentation

role=”presentation” is used to remove the semantic meaning of an element removing that information from the accessibility tree and assistive tech. This is meant to be used when you have content visually presented on the screen in a certain format which does not need to be communicated to assistive technologies.

Common missuses occur when people apply these to interactive components, effectively hiding them from assistive technologies, or items such as lists, where the list items will then be treated as standard text with no hierarchy or relationship.

aria-presentation is also recursive, so if you add it to a top layer element, all children elements will also be treated as if they are specified with role=”presentation”

Example of Misuse and poor code

<table role="presentation">
	<thead>
		<tr>
			<th>Header 1</th>
			<th>Header 2</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>Data 1</td>
			<td>Data 2</td>
		</tr>
	</tbody>
</table>

In this example, the list semantics are removed, making it harder for screen reader users to understand the structure.

Key Takeaways

• When creating a clean accessibility tree, it is important to know where you should use aria attributes and where you should not.
• be aware of the negative impacts of aria-components and use them sparingly
• Headings should be clear and in correct hierarchical structure
• Semantic HTML landmarks should be used but do not implement lots of other landmarks as it will just clutter the navigation
• Do not disable buttons, it will only confuse people
• Ensure all your interactive components have appropriate labels which describe their function.