Like the modern JavaScript environment, web app accessibility is a fast-moving target. This has directly to do with the incredible pace of web development nowadays. Where more possibilities emerge due to technical progress, more usage strategies appear as well, and at the same time, these new features for some people could be barriers for others.
Admittedly, both accessibility and web development have parts that are staying the same – robustness and future-proofing are web accessibility principles. This book aims to put emphasis on those basic parts of Vue.js accessibility.
However, this alone is not enough. You need to be aware of the streams of development in web dev, web apps, Vue and their intersection with accessibility (therefore people, and their usage strategies) as well. Over time, I found the following people to be very helpful and educational:
#Follow these people
#Web Dev and Web Apps in general
Find below many individuals from whom I learned so much about accessibility, processes, problem patterns and solution strategies, inclusive code and - last but not least - communication.
- Scott O’Hara is a Senior Accessibility Engineer at The Paciello Group and part of the W3C Web App and ARIA working groups. His research in usage strategies, assistive technology, and tools at our disposal as web developers go very deep, and he has a very approachable writing style. You find him online and on Twitter as @scottohara.
- Marcy Sutton is a freelance web accessibility expert who worked in the past for Deque (the ones who built the axe tools) and improved accessibility and related documentation at Gatsby.js (see chapter 5). She is very hands-on, conducts research and conveys important topics regarding web app accessibility in great presentations, blog posts and workshops. You can find Marcy Sutton on Twitter at @marcysutton or visiting her website.
- Heydon Pickering is a freelance web specialist as well. With the combined talent of genuine British humor and masterful explanation skills, Heydon shares his accessibility knowledge wherever he can. To our fortune, some of his clients, like the BBC or Bulb, open-sourced his analyses, advise and accessibility work for them. You can find more on Heydon’s website and on his Twitter account, @heydonworks. He also wrote not one but three essential books on web app accessibility: Apps for all, Inclusive Design Patterns and Inclusive Components. I consider all three standard references if you work in web app accessibility.
- Sarah Higley is an accessibility professional working at Microsoft and really likes to dig in deep into topics like inclusive tooltips, ARIA grids and custom selects. The digging is thorough and based on real user testing - and the accessibility community loves how Sarah is presenting her research in the form of awesome talks and great blog articles. You can find her website here and her tweets @codingchaos.
- Lindsey Kopacz is a web developer specialized in accessibility. She cares for inclusive experiences on the web, about overcoming ableism and educating her fellow web developers about the importance of accessibility. Apart from writing on her blog she has courses on Egghead and recently published her ebook “The Bootcampers Guide to Web Accessibility”. On Twitter she is called @littlekope.
- Adrian Roselli: Assembling this list, it struck me that all most of the people I’m recommending to follow here share two qualities: On the one hand, they have a vast knowledge of accessibility and routinely share it. But on the other hand, simultaneously, nearly everyone on this list has a very dry and sarcastic sense of humor. Adrian definitely combines both qualities, and his blog posts are frequent, funny and always dive deep into the topics. He succeeds to look at things in a very balanced way, emphasizes that, in accessibility, there is not one irrefutable truth, but you always have to look at things individually and, above all, ask your users. You can find him online, and on Twitter he is @aardrian.
- Karl Groves gives out solid advice and has a special talent to explain complex things in a very approachable way. Since parts of web accessibility can be really complicated, this is a valuable talent to have. So look out for presentations or workshops in your area (or online) for a treat. Karl also blogs regularly, and the topics of his articles are often very valuable from a business, organizational and accessibility service provider perspective. You can find Karl personal blog here and his Twitter account is @karlgroves
- Alice Boxhall and Rob Dodson are both Google employees and move the needle for accessibility in the Chrome project. Further, both and are competent educators in the web accessibility community. For example, Alice and Rob produced an extensive course for people starting in web accessibility you can find at Udacity. Alice authored the specs on the
:focus-visiblepseudo selector and theinertattribute in HTML (see chapter 2). Rob has an amazing video series on web app accessibility on YouTube called AllyCasts. You can find Alice Boxhall on Twitter @sundress. Rob Dodson’s handle is @robdodson.
#Look into React
One could say, React has a certain advantage when it comes to accessibility. Starting points of how to build inclusive web apps and pointers towards the most basic building blocks have been part of the official documentation for a long time (Vue just caught up lately in this regard with an “Accessibility” section in their official documentation). Also, there are some accessible libraries and initiatives already around, one of them Reach UI. Among other things, the team behind Reach (Ryan Florence and Michael Jackson) built Reach Router, a router library for React that takes basic care of focus management upon route transition (read more in Chapter 5 about the importance of this). The fantastic news regarding Reach Router was that this project would be archived - because Reach Router and React Router will merge. Although React does not do “first class plugins” like Vue.js, this is excellent news.
Because React has been around for a longer time than Vue – and because, let’s face it - React is still more popular, many companies have committed to building their UI libraries React-based. A part of them open-sourced their work, and an even more amazing part wrote their UI library with accessibility, standards, and best practices in mind. Among them are the Cauldron collection of components by Deque and the Design System of the Australian Government. Also, BaseWeb by Uber is open source and considered inclusive.
It is always great when large Virtual DOM Frameworks like Angular, React, and Vue inspire each other. It brings forward modern web development as a whole. This is even more valid regarding accessibility - when the Vue community learns from React, that itself learned from Angular, nobody loses. It much more opens the possibility that the ones who count at the end, namely users, win.
#Follow the development of standards
Not only frameworks, libraries and user agents are evolving. The same is true for standards, specs and APIs as well. Here are a few worth watching:
#AOM
The motivation for the Accessible Object Model, or AOM is the following, as stated in its explainer:
Web apps that push the boundaries of what’s possible on the web struggle to make them accessible because the APIs aren’t yet sufficient - in particular, they are much less expressive than the native APIs that the browser communicates with.
In concrete terms, that means that the AOM is intended to help developers with:
- Setting accessibility properties directly (for example:
el.role = "button";instead of relying onel.setAttribute('role', 'button')) or the like. - Setting relationship properties without the use of IDREFs. Again the reasoning behind it is avoiding querying the DOM and setting properties with
setAttribute. - Listening for events from Assistive Technology.
- Adding non-DOM nodes (“virtual nodes”) to the Accessibility tree.
- Inspecting the computed accessibility tree programmatically. Despite now having tools in browsers such as Google Chrome or Mozilla Firefox for this, there is still no way to inspect a node’s accessibility properties in a programmatic way alone.
All of this combined could be a really convenient API for developers who know this form of convenience from other languages. That’s why it is an exciting concept worth following. For this, I recommend watching the aom repository of the Web Incubator Community Group. Further, please follow Hidde de Vries on Twitter (@hdv) and subscribe to his blog. He’s a freelance accessibility specialist and, while not limited to the Accessibility Object Model, he wrote a great primer on the topic.
#ARIA 1.2
ARIA 1.2 is, at the time of writing, in the working draft stage, which means still open for feedback and capable of changing the specification based on the feedback received. As it looks now, ARIA 1.2 will introduce new roles (e.g. blockquote, caption, code and paragraph) while also refining new properties as aria-disabled or aria-expanded regarding their valid usage on elements. To stay updated, the safest bet is to watch the corresponding GitHub repo. But like all the other topics mentioned in this section: Subscribing to the folks listed above should ensure that you don’t miss significant developments.
#Join the accessibility community
One great place to meet the worldwide accessibility community, to stay informed on developments, share resources and pieces of advice about anything accessibility-related is the Web A11y Slack. The channel was founded a few years ago by Marcy Sutton and it is the most crowded and vivid accessibility community that I know of. It is full of specialized sub-channels, plenty of knowledge bits regarding technologies, approaches, testing, laws and certifications - to name a few. Because of spam reasons, the slack channel is invite-only. If you’re interested in joining the channel, nevertheless, hit me up at marcus@accessible-vue.com.
#Action Steps for this chapter
- Check out Vue A11y
- Consider following a few links from this chapter :-)
- Consider keeping on learning