One-page-applications are not accessible

Craig Abbott
3 min readApr 4, 2018


A deliberately complex user interface which shows all of the information on one page, including graphs, charts, statistics and maps.

One-page-applications are on the rise. With them you get funky animations and cool transition effects. Some are a real beauty to behold.

Building them used to be a chore. You needed a lot of AJAX requests and complex call-back functions. You needed to manipulate the DOM (Document Object Model) a lot using Javascript or jQuery.

But, now we can use WebSockets instead of AJAX and we can use frameworks like Angular or React. This makes actually developing a one-page-application easier than ever.

This seems like a good thing, right?

So, why are one-page-applications bad?

Well, theres things that could hurt you unless you’re clever about it.

The most obvious place to start is a reliance on Javascript. Some users don’t have it enabled. How does your app work for them?

Then there’s search engines. These crawl through your URLs, and you will only have 1. So Google can’t see most of your content, which will affect your visibility and your traffic.

Your analytics will be difficult. You usually tie interactions to a URL which allows you to look at the data in-scope. If you only have 1 URL, you’re going to have to create complex work-arounds by creating virtual pages.

Creating a work-around takes time and effort. If you’re going to create a great experience and a great one-page-application, you’re going to need a few. It will be hard. It will take sweat. Tears. Frustration. There will be bugs. There will be refactoring.

All browsers have common behaviours. The back button. The forward button. The stop (or cancel) button. The focus. The caching of the scroll position. These are all thing that users have learned subconsciously by surfing thousands of websites. Your one page application must be consistent with what people know, or they won’t use it.

Accessibility and one-page-applications

The biggest problem with one-page-applications, is they create a terrible experience for people using screen readers.

There is a cognitive issue. Users have to maintain a mental image map of the page in all it’s states. If they click something, and some new content appears. How does your user know what has changed? How do you make them understand what they cannot see? How do you orientate this to their mental map they have been building?

Changes can be subtle or drastic. Sometimes, the whole page can change. If so, has the focus or scroll position changed? Or have you left the focus on the hidden content?

If you’ve loaded all your content into the DOM and hidden it, will a screen reader still read it out? If I don’t use a mouse, can I still tab to the hidden content? If so, your user will quickly lose context and become disorientated.

If you do load all your content into the DOM, will it cause performance issues? Will the initial load of the site be slow? Do you need a loading progress bar? How do you alert a screen reader to the loading time as it updates?

I’ve seen issues where the DOM was so huge the screen reader actually became unusable. This was using JAWS). The time between pressing a key and hearing the content was over 4 seconds. A delay of over 400ms makes any application annoying. But, a delay of more than 2 or 3 seconds makes the application unusable. IBM figured this out in the 80’s, it’s sometimes referred to as the Doherty Threshold.

If you don’t replicate all these behaviours, it won’t just be disorienting. It will make navigating your site impossible. And depending on which sector you work in, this could actually make your site illegal.

So, if you have to do so much extra work to make your one-page-application behave like a regular one. Why not make a regular one in the first place? Do people really want fancy transitions rather than a solid and performant experience?

People do amazing things. I don’t doubt for one minute that a good accessible one-page-application is possible. But I’ve not seen one yet.

Originally published at