Landmarks and ARIA
In order for a screen reader user to be able to navigate on a web page, understand different functions or know when something on a page has changed, most websites need to be coded with some type of aria.
Many developers do not know that the browser takes the HTML DOM and changes it to a so-called accessibility tree, which is where the screen reader gets most of the information from.
When we audit websites, it is clear that many areas and functions lack aria, or even worse, have coded it incorrectly. This means that the accessibility tree does not at all reflect the information as it is intended. To avoid this type of problem, some basic knowledge of aria and landmarks is needed. As a developer, you of course need to test your code with a screen reader every now and then, but above all you need to test with people who use screen readers daily.
What is this all about?
To help a screen reader user, you can for example use some of the basic structural HTML 5 elements available, such as "header", "main", "footer" and "nav", this is a good start.
If you mark the search function with the attribute role = search and if you use aria-expanded = "true / false" on buttons that expand areas, that is another step in the right direction.
Landmarks
Never use a landmark or a role that you do not know the consequences of. All too often we see components that are correctly coded in themselves, but which together with other components create problems.
The examples of landmarks mentioned above are called structural HTML 5 elements and they fulfill their purpose. The attribute "role = value" is also a type of landmark and there are just over 80 different values to use, of which 75% are almost never relevant.
The example below shows html code which I consider to be the basis of a website:
<body>
<header>
<div role="search">
Search Function
</div>
</header>
<nav>Navigation</nav>
<main>Content</main>
<footer>Repeated content</footer>
</body>
ARIA
An example of when it is important to use aria is if there are several different navigations on a page. A screen reader finds these areas if they are coded with the element "nav" or with the attribute "role = navigation", but it can be difficult to distinguish the areas from each other.
The aria-label attribute can be easily used to mark the respective navigation. The screen reader then finds out that there is one navigation called "main" and another called "local".
<nav aria-label="main">
<ul>
<li><a href="url1">Landing page 1</a></li>
<li><a href="url2">Landing page 2</a></li>
</ul>
</nav>
<nav aria-label="local">
<ul>
<li><a href="url1">Page 1</a></li>
<li><a href="url2">Page 2</a></li>
</ul>
</nav>
Another example of when it is important to use aria is when an area on the page is expandable. A typical such area is usually the mobile navigation. If a screen reader user clicks on this type of button, nothing happens. Purely visually, the area is displayed but the screen reader says nothing. What should happen is that the screen reader says something like "expanded" or "collapsed" which it would actually do if the button was marked with "aria-expanded" and that the value then switches between "true" and "false". In the example below, the mobile navigation is collapsed and thus not visible.
<button id="m-trigger" aria-expanded="false">Menu</button>
<nav aria-label="mobile" hidden>
<ul>
<li><a href="url1">Landing page 1</a></li>
<li><a href="url2">Landing page 2</a></li>
</ul>
</nav>
In this example, the mobile navigation is expanded and fully visible.
<button id="m-trigger" aria-expanded="true">Menu</button>
<nav aria-label="mobile">
<ul>
<li><a href="url1">Landing page 1</a></li>
<li><a href="url2">Landing page 2</a></li>
</ul>
</nav>
WCAG 2.1:
1.3.1
2.4.3
2.5.3
4.1.2
4.1.3