In one regard, Vue is very accessible: When it comes to the developer experience and learning new shiny JavaScript frameworks, its often quoted "developer experience" is one of a kind. At least, in my opinion, getting to write your first lines of Vue code is far easier than writing your first lines of code in a React or Angular project. If you are using direct imports of the script, you don't even need a bundler or "create Xy app" script in the first place! Not even a node.js setup necessary!
In another regard, Vue is considered not very accessible: When it comes to the output it produces. This is not a problem that is exclusive to Vue, mind you. All three of the current big players in JavaScript framework land - Vue, React, Angular - have this problem. The issue is not that it is impossible to create inclusive experiences with these systems: all three of them are very well capable of producing code that can be accessed by a maximum of users (and I hope this book succeeds in helping you to churn out accessible Vue apps). There are some specialities that JavaScript frameworks and especially the concept of client-side rendering bring to the table, but there are strategies to tackle them (and in this book you are going to learn how). No, in my mind, inaccessible apps built with a large framework are first and foremost an awareness and education problem. In order to create inclusive apps, the actual output of your JSX, Typescript, Hooks, Composables, State of whatever has to be moved much more into the limelight than it is now. Because this output part is what counts for a large and always growing user group.
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 second part of the educational problem is not exclusive to apps built in or with JavaScript – it is also valid for an old-school website (whatever that may be exactly). It is the mismatch that there is so much good content around on the internet to make the web accessible, but people either aren't aware of it or are overwhelmed by it and don't manage to find a point of entry into this topic.
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.
Chapter 3 is about how you can use Vue's core concepts and architectural strengths to achieve accessible output. JavaScript-based frameworks have, despite their bad reputation, plenty of advantages when it comes to accessible code. Alas, just a minority of developers know and use them.
The next chapter (number 4) deals with making some of the most typical components you have in your app or JavaScript-enhanced page accessible.
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?
I have the urge to put an emphasis on this: I can't and won't repeat web accessibility basics here, although they make up the vast majority of accessibility of your app. Other, better and larger books have been written especially about this topic, and the ones that I know and love are recommended in chapter 1. This is a book about accessibility (a11y) in Vue, not about a11y in general. But: since the very aim of any JavaScript-driven framework is to output HTML, many contexts are the same in other frameworks (or user interface libraries, if you want).
Due to the vast amount of accessibility topics covered, this book only can introduce most of the tools I recommend on a surface level. Being too detailed in a book dealing with a moving target like JavaScript is an error in itself, I think. For example, the proper usage of eslint, jest and 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?
I'm Marcus Herrmann, certified Web Accessibility Specialist (IAAP) and freelance web developer from Berlin, Germany. As a developer, I reach out - happily - for VueJS, when I need should build a more complex user interface with JavaScript. At the same time, I like things that I built to be robust. This means I don't build every project in Vue.
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.
Last update 2021