I investigated possibilities that are possible to make single page application (SPA) navigation as accessible as possible. SPA is by far not something new these days, so I was negatively surprised when I discovered that it is actually not quite standardized. I really hoped that developers of browsers and SPA’s would find a solution for it when we think about the problem for this kind of technology is there for at least a decade (opens in new window).
I will not go into extensive research why this is the case, but it seems to me that responsibility for accessibility was pushed aside on the path to technological progress. Developer experience won over user experience to say it differently.
There are solutions out there though, and some experts did also user testing to back them up, but on the other hand there is still no standardization and that’s quite a strange for me. In this post I will try to reflect on most popular solutions.
But first – how does classical navigation work again?
To be able to compare we should begin with understanding of classical navigation. The multi-page application (MPA) or website if you want to call it like that. I think we need to check exactly how it works before we want to fix the SPA navigation’s problems with accessibility.
How do screen-readers announce page navigation?
When using screen-readers we sometimes just accept how they work and use their features like they are presented. With some screen-readers we can actually adjust some preferences and it really depends on the screen-reader what is possible.
Mobile screen-readers are way less complex than desktop screen-readers and with that we can say that JAWS and NVDA have way more options than Narrator and VoiceOver. I did not research all the possibilities as I prefer to use default settings, but we must be aware of the fact that sometimes users adjust their screen-readers quite a lot and sometimes they don’t.
Default navigation on classical, multi-page applications, seems to be quite similar across screen-readers, with small deviations;
Title being read, focus on body (top), automatically started reading the title and page content. Some screen-readers announce page loading process and busy, most do not.
Please note that results can vary because of versions, bugs and so on. This overview is just a simple one. Be sure to test yourself, more important, test with your users!
What does React do?
Well React is the most popular JavaScript framework (opens in new window) for making single page apps as far as I am concerned. At least today it is, but I guess that also in the near future. I will not go into why and why not others but let’s just accept the reality and check what it has to offer.
Accessibility when using React Router
Well, React itself does not have anything out of the box that can make navigation more accessible, besides using semantic links for navigation. We need a router to be able to simplify the navigation and one of the most popular routers there is is React Router (opens in new window). Their docs do not mention accessibility, so I checked their GitHub and found an issue opened back in 2017 (opens in new window). Still not resolved today…
It does not mean that using React Router is not accessible by definition, but it does mean it is not accessible by default. There are a lot of different solutions that I will also try to describe later, but we have to make them either a part of the dependency or from scratch.
I am not advising against usage of React Router, but please do make sure you will test and make it accessible as it is not there by default.
Accessibility when using Reach Router
React Router claims “Accessibility is a first-class concern for Reach Router, so, naturally, it’s baked in.” (opens in new window). That does not mean it is perfect though. Focus management is there and it seems to work OK, but if you need to support different screen-readers, like for example TalkBack on Android you should be aware that it is not perfect there. I’ve even discovered an open bug for usability issues with TalkBack on Reach Router GitHub page (opens in new window).
Accessibility when using Next.JS
Seems like there were some glitches but it seems to be working well now – as far as I could tell without digging into source they are setting focus on the body after navigation. GitHub issue that seems to back this up concludes with this anyways (opens in new window). I’ve tested briefly with screen-reader and it was actually quite well.
Accessibility when using Gatsby
Leaving best for the end – you have probably read the Gatsby article on accessible client side-routing written by Marcy Sutton already (opens in new window). It’s a brilliant article and I really liked them involving real users to base their findings upon.
Their solution is a bit different than NextJs’s and they have chosen to use a aria-live announcement (aria-live=”assertive” and aria-atomic=”true”) that announces “Navigated to ” and page title.
At the same time focus is moved to a wrapper div with tabindex=”-1″ that is wrapping the whole page (so similar to focusing on body actually).
As they really tested their solution with real users I would actually like to think this is the best solution as per today, but still suggest that you test with your users if possible.
Respect established patterns and test with users
I think that it’s difficult to say what is best with no context. “It depends” strikes once again. So try to respect established and well-known and accepted patterns and also test with different users and different screen-readers and browsers. Unfortunately the landscape to support all combinations is not unified, so testing is the best way to be sure.
In most cases I think that Gatsby and Next are doing it OK, but again, test, test test.
You can and probably should create your own test scenarios, but thanks to Marcy Sutton – you can also use her testing scenarios (opens in new window).
