Building accessible-app.com: Project status, side benefits, and Routes
It has been a long time between this blog post and the last one, but rest assured: The #accessibleapp project is still alive! It is only progressing somehow slower than I had hoped in the summer.
This is part 4 of an article series on building "accessible-app.com".
Read the other posts:
During the last weeks, I was on a longer vacation, had some customer projects without direct reference to accessibility - with one exception: An agency approached me for accessibility advice on a single page app they were building. Funnily enough, I was recommended to this agency by a friend who noticed the #accessibleapp project. And even better: They planned to create their web app in vue.js. That was very convenient for me, because it's is my favorite JS framework, and I already did some research for accessibility in vue.js in general. During that, I have noticed that vue.js unfortunately still has to catch up when it comes to plug-and-play accessibility solution (or at least documented strategies on how to achieve accessible components). In this regard, React is ahead of them (see the advanced guide on a11y in their docs or the Reach/Reach UI project).
- Focus Management
- Popover Menus
- Notifying users of changes
- Data Tables
- Off Canvas Navigation
During the aforementioned counseling job, I did some research on how to solve the "Routing" part in vue.js - which also has to to with "Notifying users of changes" and "Focus Management". Why?
In short: Screen Readers expect a document to be static. Due to a Single Page Application's asynchronous nature, some parts of the HTML will be changed without a page reload and without the document title being read again. Sighted users will usually notice that something has happened, but developers have to take care that Screen Reader users are notified of these changes. There are two strategies to achieve this:
Sending announcements via ARIA live regions
To quote MDN on "Aria Live Regions":
Basically, programmatically messing with focus is not recommended, but in that case, it seems legit. Current general advice on how to handling Routes is actually moving focus to the new, loaded content. What I learned in my research is that I got different assertions regarding concurrence of aria-live announcements and focus changes:
- Deque University states that an announcement like "Loading content" and moving focus is usually not necessary when the loading time is short, which should be applicable for the most situations
- Whereas Marcy Sutton advises using them both for Route changes in her chapter "Accessibility in Times of Single-Page Apps" in the great Smashing Book 6, page 68.
For now, I will work with Deque's advice since a live region can always be added later.
Framework's ready-made routers and focus management
Ryan Florence of React Router fame has started the Reach project where he plans to supply accessible React components. The first of this is Reach Router. Its pragmatic solution on Route change is to send focus to the container where the new component will be loaded into.
Unfortunately, there is no vue.js equivalent to Reach router. But due to Vue's architecture, you can register a watcher when the there's a Route change using vue-router. I played with some focussing strategies in the past and will write a separate blog post on the topic.
I actually have not dealt with Angular, but I have seen an example where the
viewContentLoaded event is used to set focus on a particular element after a certain delay.
Which route(r) to take?
To reiterate this again: I won't be able to build #accessible app in all of the three big frameworks by myself, I can handle the Vue part if I'm lucky. So if you happen to know better solutions or pre-made plugins in regard to Routing (but also the other topics), please get in touch via
Thank you in advance!