PDFTron is now Apryse. Same great products, new name.

Web App Accessibility: 5 Step Checklist

By Liam Ross | 2020 Sep 01

5 min

Use Native Elements

The simplest way to ensure that your application will function predictably is to use native elements such as button, a, and p. Merely using these will ensure that any users relying on keyboard navigation can focus and interact with all the content. For example, by using a native button element, the user can focus on a specific item using tab and click with the space or return key. This method is much easier than manually adding listeners and tab indexes to your elements to make them function like buttons.

Sometimes, people avoid using native elements because it can be a pain to remove any default browser styling from them. The easy fix to that is either adding global styling to remove browser-specific styles. Our solution was to add a Sass mixin that could be easily added to any elements to remove the default button styles for a clean slate.

@mixin button-reset {
  // These are just to remove some of the
  // default browser styles on buttons.
  padding: 0;
  border: none;
  background-color: transparent;

  // This becomes `html:not([data-tabbing='true']) .your-class`
  // at the root level, ensuring that when the data-tabbing
  // attribute is not true there will be no button focus style.
  @at-root html:not([data-tabbing="true"]) #{&} {
    outline: none;
  }
}

Ensure Proper Labeling

Generally, screen readers can parse an element's content, such as a button or anchor, by reading the text contained within. This is great for buttons with text, but what about icon buttons? These generally include nondescript SVGs or icons that screen readers are unable to get valuable information from. In cases like these, it is important to add a description of the element to the aria-label attribute. The screen reader will read from the aria-label when that element is focused, so the user can determine its purpose.

If your application is internationalized, ensure that you also translate the aria-labels, not just the element text!

const translatedLabel = t("next_page");

<button aria-label={translatedLabel}>
  <Icon i="right_arrow" />
</button>;

Focus Styles

Removing focus styles is one of the worst things you can do for accessibility. Developers have a tendency to go outline: none as they style a button. This is OK, so long as you make sure to implement some indication that an element is being focused. Many UI kits implement custom styles for their focused elements. A downside here, however, is focus rings can appear whenever elements are clicked, even though users navigate without their keyboards.

In our new UI, we hit a sweet spot: focus styles only appear when using keyboard navigation, and they stay hidden when navigating with a mouse. This keeps application styling until indicators are actually needed: i.e., whenever the user presses the tab key or steers with the keyboard in a menu component. And once the user clicks, these indicators disappear.

Skip to Content

Implementing a “skip to content” box feature helps keyboard-navigating users get where they want quickly without tabbing through the entire UI. In practice, the skip box remains hidden until the user begins tabbing, at which point it should be the first thing they encounter.

Implementing Keyboard Navigation

If you have implemented everything with native elements, you should avoid having to implement custom keyboard navigation. However, you may encounter specific cases where custom navigation is required. For example, you may want to trap user focus in a modal, to prevent the user from tabbing out, or enable easy navigation within a menu.

When you tab to a menu, it is focused normally.

But once you click it, instead of using tab the user will use the keyboard up and down keys to cycle through elements.

This mimics the functionality of native select elements. Implementing something like this is relatively easy, and can be achieved in a few steps:

When the element opens:

Add a keydown listener to the document
Store a reference to the currently focused element (this will be the button that opened the menu)
Track all focusable elements within the bounds of the menu. (you can use a simple DOM string with querySelectorAll -- here’s an example of the string we use in the WebViewer React Toolkit)

When the keydown listener is triggered:

If the key is up arrow, move the focus to the previous focusable element (if it’s already the first one, you can choose to ignore it, or cycle to the last element)
If the key is down arrow, move the focus to the next focusable element (same as up arrow, you can decide whether to cycle focus or just stop at the last element)
If tab or escape are pressed, close the menu and return focus to the reference you stored to the button that opened the menu. Tabbling will continue as expected, as the element will be focused prior to the default action (moving to the next item)

Once you've implemented these steps, the result should look like this:

Resources

I covered many of the high impact changes you can make to improve accessibility across your application. However, there are many tools and resources available to ensure that your front end is set up for all users.

https://accessibilityinsights.io/ - A tool created by Microsoft to audit your front end for accessibility bugs and improvements

https://a11yproject.com/checklist/ - A web application accessibility checklist to ensure your site meets the Web Content Accessibility Guidelines standard

https://www.pdftron.com/samples/web/samples/advanced/accessibility/ - Our up-to-dateWebViewer 7.0 accessibility demo implementing all the latest accessibility standards