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).

In the last blog post, A specific app idea, I outlined a raw concept for the actual demo app that I plan to showcase in popular JavaScript frameworks. The feedback on this "bookstore" concept has been very good, so I will go for it. What's also been laid down now is the feature set for the demo app's first iteration:

  • Focus Management
  • Modals/Dialogs
  • Popover Menus
  • Routing
  • Notifying users of changes
  • Data Tables
  • Off Canvas Navigation

Routes

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":

Using JavaScript, it is possible to dynamically change parts of a page without requiring the entire page to reload — for instance, to update a list of search results on the fly, or to display a discreet alert or notification which does not require user interaction. While these changes are usually visually apparent to users who can see the page, they may not be obvious to users of assistive technologies. ARIA live regions fill this gap and provide a way to programmatically expose dynamic content changes in a way that can be announced by assistive technologies.

Moving Focus

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

React

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.

Vue

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.

Angular

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!