How to solve accessibility problems
By Adrián Benavente, Frontend developer & A11y specialist at Coderio.
Talking about accessibility is talking about equity and possibilities. Because thinking that everyone can have access to the same spaces implies, first of all, starting from the basis that we are different and, secondly, looking for a way to make the access easier and viable for everyone.
In web development, accessibility is the inclusive practice that guarantees access to sites by using and designing tools and technologies so that people with disabilities can use them. In other words, the possibility that most of the users can perceive, understand, navigate, interact, and contribute to the network.
Let’s start from the beginning
Single Page Applications (SPAs) are tools or sites that allow users to interact with websites more efficiently. Instead of requesting servers to load entire pages every time the users interact with them, SPAs load the content once and then update the necessary content using JavaScript without reloading the whole page. SPAs allow more fluid navigation and less resource consumption, similar to a native application.
In turn, it has allowed developers to make our architecture much more granular. We have stopped thinking about pages to see everything in terms of components. It has also made debugging easier since all we need is a browser and the developer tools of the framework or library we are using.
However, despite all its benefits, of which I have only named a few, it could be said that in a certain way they have made the web less accessible by default.
But, of course, putting all the blame on the SPAs would not be the most reasonable. A paradigm shift is nothing more than a new way of thinking and doing things.
That is why I want to share a series of implementations that are a must from the beginning of the development process. Also, with the regular basic verifications, we will guarantee that our SPAs comply with the second principle of WCAG 2.0: to be operable.
Focus management
Since the tab does not reload when navigating between views, the screen reader will not notice any content changes unless explicitly told to do so. A common technique to fix that problem will be to place the focus on the first header.
function onNavigate() {
document.getElementById('titulo-seccion').focus();
}
But header tags are not focusable elements, so you have to give them this feature by giving the tabindex attribute. We assign it a value of -1 to prevent it from interfering with the TAB key navigation flow.
<section>
<h2 id="titulo-seccion" tabindex="-1">
Título de la sección</h2>
<p>Aquí el contenido...</p>
</section>
It also applies to cases where a button or link scrolls within the view to another part of it. The focus should always be on the beginning of the content, to where we will direct the user.
Document title
Since there is only one HTML document, it will always have the same title. The user might not know what screen they are on if they go to another browser tab and then return. Therefore, we need to modify the text of the <title> tag through JS when switching views to reflect its content.
document.title = "Mi maravilloso sitio | Quiénes somos"HTML semantics
Sometimes SPA development frameworks, if not well used, can force bad practices such as excessive use of <div> tags, which can degrade or even completely ruin the user experience of assistive technologies. That is why always maintaining correct HTML semantics is essential.
<header>
<h1>Mi página</h1>
<nav>
<ul>
<li>
<a href="/home">Inicio</a>
</li>
<li>
<a href="/nosotros">Nosotros</a>
</li>
<li>
<a href="/portfolio">Portfolio</a>
</li>
<li>
<a href="/contacto">Contacto</a>
</li>
</ul>
</nav>
</header>
<main>
<section>
<h2>Nosotros</h2>
<p>Bla, bla...</p>
</section>
…
</main>
<footer>
<p>@adrian.benavente.dev</p>
</footer>
Conclusion
As the ways of developing software advance, assistive technologies accompany this evolution. Surely soon, we will find better support for SPAs from the various user agents used by people with disabilities, or perhaps the SPA development tools will incorporate accessibility improvements. In the meantime, we cannot sit back and wait for this to happen and —when it does— drop backwards compatibility.
Finally, let’s not forget that, according to WCAG 2.0, in a conformance statement a document is or is not accessible, but it can never be partially accessible. In that case, it is considered that it is not and is excluded. Now, a SPA consists of a single document.
Update
The WCAG 3.0 draft incorporates the concepts of views and states, shedding terms such as page or document, thus bridging the gap with the current vocabulary and adjusting to include SPAs. However, this version will not see the light of day before 2023.
By Adrián Benavente, Frontend developer & A11y specialist at Coderio.
