Accessibility best practices

Best practices while building

One of the biggest reasons cited for not focusing on accessibility during development is the perceived impact it has on your ability to launch on time. To many, accessibility is just one extra step to add to an already saturated workflow.

However, it’s vital that you interact with your online store as you build it, to check whether the changes you make are working or not. This is especially true when tweaking things with regards to accessibility, where testing and demoing changes can flag any issues or unveil additional opportunities. Here are a few key areas to examine and keep in mind while building out your store on Shopify:

Keyboard navigation

While you’re going through your theme build, pause and review your code with some rudimentary accessibility testing. The keyboard navigation test is one of the easiest, most unintrusive, and low cost techniques you can use to assess accessibility within your build workflow. Keyboard navigation is an important tool used by people with visual disabilities, impaired motor function, and many more conditions. 

Essentially, this test requires you to try to navigate your website by relying solely on the tab & arrow keys on your keyboard. This allows you to evaluate the ease of which a user can navigate your site when trying to reach a given element via their keyboard. The keyboard navigation test also helps identify if interactive elements and modals can still be triggered without touching the mouse. 

Screen readers

Screen readers are programs that allow visually impaired users to understand any text that is displayed on a web page. They accomplish this by “reading” the on-page text, or alt text, of a specific element out loud when a user tabs through the web page elements.

While it may be tempting to run your screen reader and keyboard navigation tests simultaneously, it’s recommended that you don’t. Many screen readers offer their own keyboard shortcuts and functionality, and thus could impact the results of your navigation test.

Use screen readers (examples below) with the browsers they were designed for. If you test your site with unsupported browsers, you can end up wasting time tracking down problems that users won’t ever encounter. Many devices such as Apple and Android phones also feature their own screen readers as part of their accessibility toolset that you can use to assess how your site reads on mobile devices.

ARIA

ARIA is an acronym for “Accessible Rich Internet Applications.” It’s a set of HTML attributes which allow web application developers to create accessible, custom components or interaction patterns using non-semantic or non-native HTML elements. 

ARIA acts as a bridge between non-native HTML elements and assistive technologies (like screen readers) by generating semantic meaning for custom components. ARIA helps to answer the question of, “What is this thing and what does it do?” for custom components. Assistive technologies consume these attributes and announce their presence to users who in turn are able to understand and interact with the components.

ARIA can be broken down into:

• Roles: define what an element is or does.
• Ex. Identifying an object as a ‘button’
• Properties: express characteristics or relationship of an element.
• Ex. an ARIA-label (accessible name) provides more context on an element
• States: define the current conditions or data values associated with the elementLike disabled/enabled - describes the state of an element
• Ex. You could have an element described with the role of checkbox, an ARIA-label of 'Apple Checkbox' and a state of ARIA-unchecked. This would allow a screen reader (for low vision users) to have the element read-out as 'Checkbox, Apple Checkbox, unchecked' (the order may differ depending on the tool they use). This enables a low-vision user to understand that they are currently hovering over an unchecked apple checkbox.