Accessibility techniques are a way to create a more usable experience for all users. An accessible experience can be viewed as a continuum, and this post is an introduction to techniques that span that continuum. We will start with accessibility techniques that are most likely to fix issues that block users with disabilities from successfully navigating your application. As we get comfortable with the most impactful techniques, we will move into techniques that create a more inclusive experience and provide equal access to even more people.
When I started learning about accessibility techniques, I was quickly overwhelmed and found it difficult to find a good jumping-off-point that humanized the techniques. These techniques may be "just the beginning", but they will provide the most impact during initial development, and are where I like to start.
Keyboard navigation
Testing and improving keyboard accessibility can unblock navigation for users with motor disabilities. It can also be a good gut check when creating content to be navigable by users relying on screen readers. Ensuring your page is navigable by keyboard is the most impactful action to take. Start here and build more advanced techniques on top of this base.
I like to think about keyboard accessibility as two categories. The first, focus, enables keyboard navigation on the current state of the page. The second, toggling visibility, ensures that when content is dynamically added or removed, keyboard navigation is still meaningful.
Focus
The TAB key is used for navigation through actions within a web application. As you hit tab, the next element in the tab order receives focus and can accept action.
- Favor Native Elements: Some elements naturally receive focus when
TABis used to navigate to them. The most widely used examples are<a>,<button>, all types of<input>, and<textarea>. Focus works splendidly when these elements are used appropriately. However, when a<div>looks like a button, it does not receive focus, and blocks access to content presented by clicking the "button". - Provide a Tab index When Necessary: When a native element isn't an option, a
tabindex="0"will enable an element to receive focus in the normal tab order. Atabindex="-1"will remove an element from the navigation flow. - Supplement Hover Actions with Focus: Controls should not be hidden behind hover actions, like those to display navigation menus. Hover actions cannot be triggered while navigating the page with a keyboard, so supplement hover actions with focus actions to ensure that your content is able to be presented to more people.
- Design Useful Focus Indicators: The focused element should stand out while navigating with the keyboard. A good trick is to close your eyes, hit tab a couple times, then determine if the focused element is obvious to pinpoint.
- The Tab Order Should Be Natural: As you navigate the DOM using the keyboard, the order of focused elements should be natural and follow the presentation of content. No one wants to jump from the logo, to the footer, and then back up to the navigation bar as they tab through your application.
Toggling visibility
As dynamic content is displayed or hidden, ensure that keyboard navigation is still meaningful.
- Preserve a Meaningful Tab Order: Newly presented content should gain the focus of both the user and the keyboard. It should be added to the DOM in the most logical order for presentation to screen readers. Move focus outside the hidden content after closing, because it's very disorienting when focus is completely lost from the page.
- Close with Escape: When new content is presented on screen with modals, slide out side-bars, etc, ensure there is an "escape path" to close the content by pressing the
ESCkey. - Buttons vs Links: What would happen if a screen reader user asks for support and is told to click a button in the UI, but it's actually a styled link? Buttons and links have specific purposes. The decision to use one over the other does have an impact on the conveyed meaning of an action.
After becoming comfortable with the most impactful techniques, these are great places to continue learning:
Getting Started with Aria
Aria is a set of html attributes that define Accessible Rich Internet Applications. There are many aria attributes, and each provide a way for screen readers to convey semantic meaning to users with vision disabilities. I started with these attributes while learning about how to add contextual information using Aria.
- Aria landmarks: When visually displayed content is presented through a screen reader, the main semantic structure of the document is lost. Defining landmarks within the page will convey this meaning to a screen reader, so that areas of the page like navigation and content have meaning to users with visual disabilities as well.
- Aria roles: Aria roles provide more context about how an element is used, like a
menuwithmenuitems. This is especially important when elements aren't used in their intended way. This provides a way for a screen reader to understand that adivthat looks like a button behaves like one, too. - Aria states: Aria states provide more context about the current characteristics of a dom element to a screen reader to convey that a
divthat looks like a checkbox ischecked.
Visual Representation
- Favor higher contrast: Text and information that is conveyed visually should have high color contrast. This will ensure that users with vision disabilities, users with poor eyesight, or users on a mobile phone in the sun can understand the information. Using patterns in addition to colors will also ensure that users with colorblindness are able to understand information presented with graphics.
- Provide alternative tex: Alternative text takes the form of
altattributes on images, transcripts for videos, tablular data in addition to a bar chart, or even just explaining a graphic in a surrounding paragraph. The purpose is to provide the context and information to screen readers. As an added benefit, alternative text increases the searchability of the content being presented to a user.
Tools for your accessibility test suite
Static testing is nice but doesn’t replace manual testing. Static tests can only look at the current state of the DOM, and are missing context to make determinations about usability. There are some checks that can be very effectively analyzed by a static tool, though.
Here are the tools that we recommend adding to your accessibility test suite for static testing:
- The aXe tool suite created by Deque and centered around the aXe core JavaScript library.
- The Pa11y Command Line and JavaScript accessibility testing pal.
- The tota11y accessibility visualization toolkit created by the Kahn Academy.
- The a11y Project, a community-driven effort to make digital accessibility easier.
Start taking action today, as any action will improve the usability of your site.
