Accessible Coding Practises

Introduction

We have a responsibility to build products that are accessible to all our users. In addition to designing accessible layouts, we must ensure that our HTML and CSS accommodate a wide range of needs and browsing technologies.

These technologies include

• Screen readers and voice browsers
• Keyboard based input
• Alternative input methods, such as eye-gaze, trackballs and pointing devices

By writing accessible code, we can create content that is accessible to broader audiences, and avoid unintentional discrimination.

Accommodating screen readers

Screen readers do more than simply read aloud the screen. Most modern screen readers read from the DOM, not just the visible page. This allows them to communicate more meaningful information to the user. It also allows them to navigate websites in many ways by interpreting semantic HTML5 elements and ARIA labels. Try using a screen reader like NVDA and you’ll quickly see how difficult it can be to navigate websites that do not consider accessible code. The following measures can create a more seamless (and less infuriating) experience for screen reader users.

Correct HTML Order

HTML should be ordered in a way that directly corresponds to the order of elements on the page.

Semantic Headings

Headings must be contained in a correct heading tag, such as h1, h2, etc. Screen readers often provide the option to jump between headings, providing an easier user experience. Correct heading hierarchy is also essential for SEO.

ARIA attributes

ARIA (Accessible Rich Internet Applications) is a set of attributes that can be applied to your HTML to make web content more accessible to people with disabilities. ARIA attributes, like aria-label or aria-hidden, also provide additional screen-reader specific functionality. For more information on ARIA, see the MDN web docs. The MDN also provides an ARIA tutorial that will familiarise you with all the core concepts.

Codebots uses the following attributes to provide an accessible user experience:

• aria-label - used on buttons and links where the text doesn’t precisely describe the link destination without visual context, to give descriptive context
• aria-live - tells the screen reader user that the page content has changed when we render new elements or change content client-side
• aria-hidden - hides DOM content from screen readers

Landmarks

Landmark regions are a core part of ARIA that communicate visual structural information to screen reader users. Think of them like fast-travel points in a video game. They allow for a more effective, efficient and less frustrating experience on the web. If you’re correctly using semantic HTML5 sectioning elements, like <main>, <nav> and <article>, these landmarks are already handled for you. This is one reason why it is necessary to use the correct semantic elements whenever possible. See the HTML elements reference for more information on semantic elements, in particular those used for ‘content sectioning’.

Alt text

Images should have descriptive and useful alt attributes. This is especially important for icons. However, if the image is used purely for decoration and does not provide substantive meaning to the page, the alt attribute should be set to an empty string (alt=” “), rather than left out all together. Be as descriptive as necessary, and not more. Do we need to know that the smiling man is wearing a blue t-shirt, or is it enough to just know that he is smiling? See WebAIM’s guidelines for more information.

Accommodating keyboard-only input

Not all web users are able to use a mouse. Ensure that tab based navigation behaves the way the user expects.

Correct HTML order

The order of the HTML should match the order and hierarchy the end user sees. This ensures that tab based navigation behaves as the user would expect. Ensure that every item that can be interacted with can be accessed using only the keyboard. If not, include tab indexes to force this interaction.

Skip to content button

Adding a “skip to content” button in the header enables users to skip to content areas, so they don’t have to tab through the entirety of navigation to reach the main content, or so that they can more quickly reach the navigation options. This can be either hidden until the user begins tabbing, or always visible.

Creating focus states

All selectable elements require clear focus states using the :focus selector. This includes buttons, input fields and links, as well as showing the current card in card-based layouts. For checkable items, such as radios and checkboxes, ensure the focus and selected states are different, and both states can be identified when layered.

Accommodating alternative input methods

Web users with physical and motor disabilities may use a wide range of supportive technologies. These include eye-gaze, trackballs, joysticks and pointing devices. Larger clickable areas and well spaced content supports the decrease in fine control afforded by these devices.

Clickable areas

With links styled to look like buttons, ensure the entire button is clickable, not just the text. Check that padding is applied to the the clickable element and not to its parent - generous spacing is useless if the space isn’t implemented correctly.