Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Lessons in Accessibility for Single Page Applications – Part 1

Written by: Tyler Padley


Over the course of my latest project here at Dev 6, I’ve had to study up on web accessibility standards and how to apply them to web development principles. This post aims to distill some of my experience in making a single page application more accessible for users.


Our client specifically requires compliance with the WCAG 2.0 standard, Level AA. But what does that really mean in terms of development? The spec contains a wide array of information about maintaining an optimum set of rules for users with various levels of ability, from color and contrast restrictions to mouse and keyboard restrictions right through to screen reader access for non-sighted users.

Making your site accessible will have impacts at the design level as well as the implementation level, so it’s important to consider these standards early on in the process. For example, use of color alone may not be enough to properly convey information to a user, and this may impact design choices. I will outline some basic recommendations in this post and will get in to more detail in future posts.

Keep It Simple

My first recommendation in terms of accessibility is simplicity. If your site requires an interaction that may have to be custom built, it could be inaccessible to some users. Avoid unnecessarily complex controls.

Color and theme is another area where simpler is better. Avoid positioning text over images or gradients and ensure your background color provides plenty of contrast. Maintain adequate spacing between elements to ensure magnification doesn’t break your design.

If your design relies heavily on hover states to convey additional information, perhaps there’s a way to include that information within the design itself. If you must use hover, ensure they remain on active focus as well.

Declare your Intent

If some text on your website is a heading, use a heading tag. The same can be said for navheaderfootermainsection and p tags as well. Links should take you to another location while buttons should perform an action. Semantic HTML tags can be used without hindering style capabilities, but can also provide additional information for screen readers out of the box.

Stick with standard web components, like radio buttons, checkboxes, text fields and select boxes. There is a whole subset of additional information that these components provide to screen readers that are difficult to replicate with custom built solutions. 

The one potential exception to this rule may be the dreaded table. Many developers choose third party components or layout libraries in place of standard HTML table tags, as table tags have historically poor performance. It is important to consider the information that a table conveys that a non-sighted user may not have access to.


Lastly, I would highly recommend adopting the WAI-ARIA specification when developing accessible websites. The spec provides screen reader metadata that can allow you to properly describe and annotate a whole host of components, layouts and content. I will demonstrate the use of the ARIA spec in future posts in this series.

In summary, the guidelines outlined above should help any developer get into the proper mindset when considering building an accessible website. In Part 2 of this series I will further examine what it means for a site to be keyboard accessible and how developers can ensure their sites are navigable without a mouse.