Our industry must learn and understand: Websites and apps are not always consumed in a setting which is (I assume) envisioned by the developer: Rendered visually and used with either mouse and keyboard or touch. The reality is: there are more type of web usages around that the average developer can imagine: zoomed in, with changed fonts, being output non-visually through a screen reader voice, utilized with a mouth-controlled mouse, seen with color vision impairments, used with an impairment that prevents fine motor movements, read by people who have the language your app is in as a foreign language, populated with people who use websites and apps with their voice only, visited by people with learning impairments - or simply operated by people who are in a hurry, outside in the sun, have trouble concentrating because they are distracted by whoever, can't move their mouse because they broke an arm - and so on, and so on. This list is as infinite as human variety. At the same time, I consider this the first pillow of the problem: Non-awareness of diversity.
The third part of the educational problem is a delicate one, and I'm really not trying to enter the blame game. Modern web development professionalized more and more. Which is a good thing, because the web is becoming more and more infrastructure of our world. This professionalization led to an influx of diverse developer groups (which is, in the big picture, a great thing). What you can do on the web, what functionality is available online is mind-blowing and was only possible on some dedicated machines, on proprietary and expensive systems, years ago. Part of that boost of functionality and complexity had something to do with, let's call them, programming veterans. The gate-keeping aspect of the "brave new web dev" world put aside: The respect for well-designed, elegant and dry backend parts of apps has definitely increased one hundredfold, where the respect for the actual output (HTML, CSS) has stalled (or did even shrink). And this is a problem. The thinking of "framework first", as Eric W. Bailey puts it, needs to give way to thinking "user-first". And the profound realization that user are far more diverse that most web developers, old and new, think.
I wrote this book to help with educational problems 2 and 3. Regarding problem number one, there are a plethora of great books and resources around (which I'll try to link in the first chapter).
#What are the contents of this book?
This book is about web app and Vue accessibility in general. However, "normal" accessibility is about 80% of web app accessibility, and I aim to give you pointers on where to get a basic understanding, where you can start your journey towards inclusivity (chapter 1).
Then, in Chapter 2, I will try to present you building blocks for an accessible web that are especially useful in client-side driven situations.
What really differentiates web apps from web pages (and where Virtual-DOM frameworks can really shine) is state and asynchronicity. One can't deny the problems of inaccessibility this potentially leads to, especially with screen readers. Chapter 5 is about that.
Chapter 6 is about testing, and about how you can use the power of automated checks to improve and (in part) ensure accessible output. At the same time, it tries to convey the limits of automated or semi-automated testing and tries to nudge you towards creating infrastructure for the most important kind of testing at all.
Finally, chapter 7 is about the fact that accessibility is not only a topic that can't be covered aptly in a short book like this (even more if it limits itself to Vue). So, this last chapter is about the reader's further learning journey. I tried to gather some interesting articles, books, videos and teachers to do just that in this last part.
#What are the limits of this book?
Cypress in the testing chapter deserves a whole book each. I, thus only can supply starting points, prime you towards the existence of those tools, try to convey the message why they are useful when building accessible apps.
#Who is this book for?
This book is for individuals who are familiar with Vue and care about not excluding users from the pages and apps they built with it. Potential readers ideally have a basic understanding of web accessibility. Otherwise, they should follow the pointers in chapter 1. Knowing more about accessibility is a skill that pays off. Not only for further reading of the book! The topic of web app accessibility and especially accessibility with Vue is a tad under-documented. But nonetheless very important.
#How do code examples in this book work?
There are plenty of ways to use vue (with
vue-cli, by just adding a
<script> tag, full client-side or using Vue just as the JS-icing of the serverside cake).
In the coming chapters, I will write example code in the "classic" way:
- By using single file components
- When I refer to a complete project, I assume it was created with Vue CLI.
- I will consequently use the Options API (if you don't know what this is: the way you write the script parts of Vue 2 components).
- Code examples are provided both in Vue 3 and Vue 2 syntax - in the form of a CodeSandbox instance for every code sample.
#Who wrote this book?
But for some other projects, using a client-side-driven framework is the best choice. Since I'm fascinated by web accessibility, Vue and especially the intersection of both, I decided to share what I know about it in this book and in my blog. I hope you can take something away from the reading.