Read Accessible Vue

Chapter 1: Cover accessibility basics first

Web app accessibility is web accessibility

Let’s start this book about accessibility in Vue with quotes about React:

Building an accessible React app is, at its core, not about React at all. The key is mastering the fundamentals of web accessibility: semantic document structure, appropriate labeling, and managing focus.

Netlify's article 'Accessibility is not a "React Problem"'

80% of your React is HTML, so learn it. It’s much more than just divs and spans.

Artem Sapegin on Twitter

In the quotes above, you could replace “React” with “Vue” (or “Angular”, or “Svelte”, etc.) and the sentiments would still hold true.

This means: Although there are special idiosyncrasies of web apps that create challenges for accessibility (more on these specifically in chapter 5), one thing remains true: Everyone committed to JavaScript Framework accessibility has to make sure that they understand the basics of web accessibility first. Accessibility for a specific framework can only be a second step in a process where the first one is to learn the basics. You could go even as so far as to refer to the famous Pareto principle: 80% of web app accessibility is taking care of basics, while only 20% is a special web app accessibility matter.

Unlike material on JavaScript framework accessibility, you will find plenty of good educational content on web accessibility online – if you look for it. I wrote this first chapter to help you look and learn, hopefully providing you with many starting points to tackle “the 80%”. A word of caution, though: If you are a developer new to web accessibility, then merely reading some of the resources linked below would not be enough to get a grasp on the accessibility fundamentals. It is a much more effective way to learn by building little experiments and projects, apply what you have learned, and try to use it assistive technology (a screen-reader, for example). On the other hand, when you are a seasoned and accessibility-savvy developer and are looking to employ your knowledge in Vue.js, you can safely skip this chapter.

Law of the instrument

I am not only starting the first chapter about a book on Vue with statements about React, but I will also go even further in saying: Check if you need Vue in the first place for the project at hand. Just because you know a particular tool very well and have profound experience does not mean that it is the right tool for the job. This principle is attributed to the US psychologist Abraham Maslow and dubbed Maslows’s hammer: “If all you have is a hammer, everything looks like a nail”. Reflect and ask yourself:

Tools made to create applications with should be only used for exactly that. Building a simple landing page or blog clientside-rendered is overkill. Why engage in solving (accessibility) problems like asynchronous updates in screen readers and accessible routing without any need? Especially when you could have chosen a tool that outputs static pages (nuxt, eleventy, Hugo, even WordPress) and you could reap the fruits of standard page loading browser behaviour – and of more of robustness (see Jeremy Keith’s talk “Layers of the web”)?

The sad status quo

Did the last paragraph either makes you rage-deleting the ebook file and asking for a refund, or are you really plan to build an app? In the second case: let’s move on (in the first case, we’re probably both writing each other an email right now).

The sad truth is that even in projects that are not web apps (wherever you draw the line between web page and app), things are not great when it comes to following the most basic accessibility advice. As a consequence, the web is full of websites that exclude people.

The “WebAim Million” is an often-quoted piece of research where the service provider WebAim investigated the accessibility of 1,000,000 pages via automated testing. While the source of the data, automated testing of accessibility, has its limits (more on that in chapter 7), the study still shows tendencies what goes wrong in the web due to the sheer number of sites examined. The conclusion of WebAim is devastating:

...the results paint a rather dismal picture of the current state of web accessibility for individuals with disabilities.

When examining the results, WebAim was able to identify and group the following main sources of error in the pages they checked:

WCAG Failure Type% of home pages
Low contrast text86.3%
Missing alternative text for images66.0%
Empty links59.9%
Missing form input labels53.8%
Empty buttons28.7%
Missing document language28.0%

(Data from February 2020)

All in all, a whopping 98.1% of homepages had detectable WCAG failures. There are two very sad things about this: Firstly, most of the errors (or error groups) listed above a relatively easy to fix. This must lead to the conclusion: Web developers either don’t know about these issues, don’t care, or aren’t allowed to fix.

Secondly, the picture painted by the research project is most likely incomplete, and the actual situation is even worse. As mentioned before, the WebAim Million mass test was conducted in an automated way. Automated testing is only one way of auditing a web project for accessibility and can only detect circa about 30% of the barriers present. The other way is the more thorough manual test. Some decisions can only be made by a human being with their judgement and knowledge of the context. For this reason, automated testing is in the best-case scenario kept within a manual audit process. Both human and machine can play out their respective strengths in this scenario.

The search for root causes

Now, why is the situation the way it is? I do not claim to be able to answer the question. But I think theories are legitimate. Here are my two guesses as to what the crucial root causes are:

Theory 1: It's an education problem

Whichever way you look at it, accessibility is very rarely part of web development tutorials. The majority of authors or content creators concentrate on the main learning content (naturally). When you are not aware of the underlying problem of unsemantic HTML, but want to convey how some library X fetches data from end-point Y you do not really mind about the trigger of it all being a <span> button with a click event listener on it. Because everything seems to be working! So the people who teach are not always aware that their knowledge of the craft is incomplete (“unknown unknowns”, as Donald Rumsfeld put it). A chain reaction of inaccessible code follows (but hey, your state library now purrs like a cat!).

The lack of accessibility as a topic in coding boot camps can be considered as the other side of the coin. Due to recruiting needs, the hottest frameworks are put in the window displays (and course agendas) of boot camp providers. As a result, the necessary accessibility basics are skipped or ignored. Your state library still has soft fur.

Theory 2: Too much focus on tooling, not on the output

Developers have always loved abstracting, and to be frank, I consider this one of our superpowers. And abstraction is not bad in itself! Sometimes it is the only way to deal with both large code bases and to work with your omnipotent framework for web applications. Before there’s a misunderstanding: excellent developer experience (DX) and following concepts like DRY (Don’t repeat yourself) are not bad per se! We just have to remember the end-user. What they experience using the result of our work is not the awesome DX, the dogmatically correct code. It’s the resulting HTML, CSS and JavaScript. Ultimately, the user (rightly) only assesses projects from the concrete result in front of them, and whether they can use it or not. I strongly feel web developers need to keep spending less mental energy to keep the framework environment happy and need to be more invested in the output that your miracle framework generates.

Where to start to make a change

So it comes down to learning about “the lived experiences of disabled people as a context for understanding the need for design and code created with access in mind” (to quote Eric Bailey on Smashing Magazine). The Million $yourCurrency question is now: Where to start? If you ask me, it makes great sense to start with a big round of questions. Here are the first general but important ones to ask yourself:

Only then it is reasonable to ponder about the following, much more concrete questions:

As you can see from the list of questions above and the looming blocks of introductory tutorials below – web accessibility is a large and diverse topic. It is also one that is covered in many articles, courses and books. Since it does not make sense to try to explain what others have explained before (and in a better way, I’m sure) – and since that book is about Vue.js accessibility specifically, here are references and links to great starting points:

Ask users, do User Testing

If you worked through the material above or knew your fair share of accessibility before opening this book, you know: On the one hand, humans and disabilities are diverse. On the other hand, people building websites, organizations building user agents (browsers) and governments making laws facilitating the participation of all people have to agree on standards.

Standards are the results of a discussion, an agreement between parties and, for the most parts, a compromise. Since humans and their abilities are diverse, accessibility is a spectrum, and so are accessibility standards. The central document and standard for digital accessibility are the Web Content Accessibiliy Guidelines (WCAG). Consider: There are but a bare minimum to aim for, not the end of the process of building your project inclusively. Don’t fall into the misconception that with WCAG compliance, everything is perfectly accessible.

The matter becomes even more complex that there are many materials about accessibility out there that cannot be considered “actual standards”, even if they are coming from the W3C. When dealing with the accessibility of JavaScript-driven interfaces and web apps, one often stumbles upon the WAI-ARIA Authoring Practices. Beware: these are not standards! I will go into the details in the next chapter, but it is important not to put the Authoring Practices in the same "standards bucket" as WCAG’s success criteria.

If you are truly caring for an inclusive web product, you pair conformance to (real or misunderstood) web accessibility standards with running web accessibility user testing. Ideally at regular intervals, ask your users about their experiences, expectations and preferences. The creators of the web app “Invision” have written a great introductory blog post on this:

With accessibility user testing, the main goal is to verify whether your assumptions concerning accessibility features were right. The objective is to discover potential problems and opportunity areas based on the already working product or the prototype.

It is worth studying the article in-depth to learn about the importance of goal setting, methodology and recruitment in such a process,

Note that mention of “assumptions” in the quote above? On uxdesign.cc (with is at the time of writing, sadly hosted on the rather inaccessible platform Medium.com), Daniel Pidcock shares an eye-opening story about an assumption he as a Head of Accessibility held:

An online food ordering service should be awesome for deaf people, right? I thought so. Find out why I was wrong and how I learned the importance of user testing with disabled people.

Only after he had the opportunity to check his assumptions – after having had contact with affected people on social media – Pidcock learned about points of failure that makes the ordering of food on the service’s website impossible for deaf customers: “Accessibility user testing: a cautionary tale”.

A special look on screen-readers

While accessibility is of course more than “making a website compatible with screen-readers”, this very special of technology is worth a mention in a basic chapter about web app accessibility.

Who uses screen-readers?

You may associate screen-readers exclusively with blind or visually impaired users, helping them to perceive text that is displayed on computer (or smartphone) screens with either a speech synthesizer or transforming the text information into tactile information.

But screen-reader use in reality is not limited to these groups alone. They can serve as a relief to consume large amounts of text for people with reading difficulties, or in general:

Some people can consume information more comfort – ably and conveniently by hearing text rather than reading it. For example, many people prefer audiobooks over reading, and sighted users with learning difficulties may prefer screen-readers for reading lengthy amounts of text aloud.

(Laura Kalbag, Accessibility for Everyone)

How does a screen-reader work?

It is hard for a sighted user to imagine navigating the web without actually seeing a page or using a mouse. Blind screen-reader users have no problem navigating a web page that is coded correctly and follows basic accessibility guidelines.

("A brief history of screen-readers")

A screen-reader’s core functionality in the context of its usage with web browsers is to convert HTML documents in either auditory form or as Braille keyboard output.

The reading order in a screen-reader is based on the order of the HTML or XHTML elements in the Document Object Model, as is the default tab order.

(W3C's Techniques for WCAG)

By definition, blind screen-reader users find to gain an overview of a document in a way that a visual user can take a glance on a document. Imagine the point of reading (the so-called “virtual cursor” of a screen-reader) as the index finger of your hand. When people with perfect vision are reading books in print form, this finger can help them read a book page. But it can only be at one place at once on a page. So can a virtual cursor of a screen-reader.

Before web-apps and, with this, a “dynamic DOM” appeared, screen-readers offered its users the opportunity to navigate a static DOM. If the website’s creator used semantic elements such as headlines and landmarks, a screen-reader user could navigate and consume a page even more or less comfortable, because they have - guided by these structuring elements - a way to jump to certain parts of the page quickly. For a time, they would not have to expect that the DOM is changing in any form. This notion shifted quite drastically with the event of pure client-side, Virtual DOM-heavy frameworks.

What is the problem with screen-readers and web apps?

Web apps differ from “static documents” in one crucial way. In a web app, a part of the DOM could change without a page reload. But the screen-reader user’s virtual cursor could already be past that point of DOM change, instead somewhere else in the document. How will the user notice the change? Do they actively have to search for possible DOM changes after every, let’s say, button activation?

While consequences of interactions, such as button clicks, are (mostly) instantly perceivable for visual users, a screen-reader lacks tools for such immediate feedback. Imagine another scenario: in a single page application (SPA), a screen-reader user is currently in the main navigation. They activate the link to the “About” page – and because it is a SPA, only parts of the dynamic document, the content area, will get updated. But if the screen-reader stays silent after the interaction with the “About” page, a user is in doubt where their click worked, and they have to actively go to the content area to check. Compare that to the experience of clicking a link and knowing the interaction has worked, because a new page loads and its page title is announced!

Fortunately, there are tools available to remedy these “silence of the apps” problems, namely ARIA live regions. Also, the question about what can happen after a SPA route change event is more and more becoming research matter for accessibility professionals. We’ll look into these in detail in Chapter 5. However, live regions are not the only instrument available in a web developer’s tool-belt when it comes to web accessibility and JavaScript. Before we dive into Vue.js itself in Chapter 3, let’s strengthen your web app accessibility knowledge with presenting you vetted patterns, established strategies and “just add water” building blocks that improve your app’s accessibility in the next chapter.

Action Steps for this chapter

The best way to learn new skills is not to only read the material, but to apply your new knowledge. Thus, you will find some action ideas at the end of every chapter. Here we go:

Go to the next chapter ›

Last update 2021