#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.
80% of your React is HTML, so learn it. It’s much more than just divs and spans.
In the quotes above, you could replace “React” with “Vue” (or “Angular”, or “Svelte”, etc.) and the sentiments would still hold true.
#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:
- Is Vue (or any other Virtual DOM Framework) your hammer?
- Is Vue (or any other Virtual DOM Framework) really the best fit for this project?
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 text||86.3%|
|Missing alternative text for images||66.0%|
|Missing form input labels||53.8%|
|Missing document language||28.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
#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:
- Do I know the variety of ways people use websites? Have I heard of some of their assisting technologies and strategies for doing that?
- Do I know which standards for web accessibility do exist?
Only then it is reasonable to ponder about the following, much more concrete questions:
- Does my HTML document’s page title convey the topic or purpose of the app or document?
- Do present headlines help to structure its content, and is their hierarchy arranged in a logical way?
- Are there so-called “bypass blocks”, meaning: Navigation helpers such as skip links (sending focus to other parts of a page), or structuring elements such as landmark regions (like
- Is information not only conveyed through color only? For example: does a red outline alone shows that a form input validation has gone wrong?
- In your texts, do you avoid referring to content or controls by their visual position on the site, their shape or color? Does your copy say “Click on the triangular/green button to proceed” or the like?
- Do you use good text contrasts in your document, especially regarding (but not limited to) links and other interactive elements?
- Is the currently focused element marked clearly? Meaning: do you either have a visible outline, or a dedicated focus styling in your CSS?
- Is the page zoomable, or can users adapt the text display without breaking your layout and making parts of the content unreachable?
- Does any form of media (e.g. images) and do any interactive controls (e.g. icon buttons) have alternative texts or accessible names?
- Do form fields have labels? Are they described well and close to the related input? Are error messages understandable, clear and programmatically tied to “their” input field?
- Is the whole app operable with keyboard only? Are there parts of your app that are only reachable on hover?
- Regarding touch input: are the targets big enough; are there alternatives to touch gestures?
- Could animation or parallax effect present in your app cause seizures for people with photosensitivity?
- Do you prevent auto-playing media, and do you offer a pause function for auto-scrolling, auto-playing, auto-updating, moving or blinking content?
- Do you use semantic HTML when outlining your document and describing its content?
- Do you supply information on the web app’s language in the document (human language, like English, French, German or Spanish, in this case)?
- In case of audio and video content, do you offer captioning, transcripts or audio description?
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:
#Recommended free materials
- Hidde de Vries’ talk “It's the markup that matters” on YouTube
#Recommended paid materials
- Derek Featherstone’s video courses on Lynda.com
- Jon Kuperman’s video course on frontendmasters.com
- “Accessibility for Everyone” by Laura Kalbag
- “A Web for Everyone: Designing Accessible User Experiences” by Regine M. Gilbert
- “Practial Web Inclusion and Accessibility” by Ashley Firth
- “Inclusive Design Patterns” by Heydon Pickering (eBook)
- “The Bootcampers Guide to Web Accessibility” by Lindsey Kopacz (eBook)
#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.
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 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.
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!
#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:
- Familiarize yourselves with the Web Content Accessibility Guidelines (WCAG) and look into some of the “Recommended free materials” links above.
- Try a screen-reader (Windows Narrator, Mac OS Voice Over, Orca on Linux) but don’t assume the difficulties of you using it is representative of “the authentic screen-reader experience”. Or where your first minutes behind the wheel of a car representative of your character as a driver in general?
- Familiarize yourself with companies and organizations of disabled people to whom you can reach out for. Don’t expect these people to work and test for free, though. Some of them are extremely familiar with their assistive technologies, can help you make your site or app work better, and need to be paid as the specialists they are.