For a digital product to successfully become an accessible product, all members of the team must be committed to accessibility in their roles. We like to visualize these roles as “the six pillars” of product accessibility. Each of these pillars is equally important:
The Six Pillars of Accessibility
- Leadership must verbalize that accessibility is a priority, and be willing to commit time and money to make it happen.
- User experience designers must keep the workflows logical and concise.
- Visual designers must ensure that the visual design works for all user types.
- Developers must use semantic HTML that uses the appropriate ARIA attributes and roles when needed.
- Content managers must write clear, easy to understand content that is free from superfluous speech and avoids ambiguous or jargon-filled language.
- QA testers must test for relevant personas in a meaningful way.
Sometimes, however, developers can be willing to implement accessibility in their code, but they don’t yet have the support of the other pillars. Whether or not we have the support of the other pillars, the developer can make progress in their domain.
That domain covers the technical implementation of accessible applications and extends from their own work through to their team and community.
Better Accessibility in Your Work
In your day-to-day work, you can improve the accessibility of your output by learning and following the Five Rules of ARIA. Following these rules will get you pretty far in your goal of building an accessible web application, but you also need to test your work.
Rule #1: If there is a native HTML element, use it.
Do this:
<button> Submit Form </button>
Don’t do this:
<a href="#">Submit Form</a>
Or:
<span>Submit Form>/span>
The biggest and easiest way for a developer to implement accessible code is to use the tools they already have! In web development, HTML is often used with less rigor, probably because it is implicitly error tolerant and flexible. Semantic elements, like the button, could be used, but div or span elements could also be used instead; the HTML will still render on the page.
This is in contrast with today’s most frequently used scripting languages; if something isn’t done correctly, the build will fail and errors will display. This has, in some ways, led to a kind of false equivalency- “If it builds, it’s correct!” However, by ignoring the semantic elements in HTML5, developers will be ensuring that their product is missing out on the default functionality that browsers have implemented for these elements and the assistive technology that depends on it.
For example, the following semantic elements provide easy wins:
- Heading Elements: Screen readers will allow users to navigate around the page using the h1-h6 tags. In NVDA, for example, users can use the INSERT + F7 keyboard shortcut to bring up this option.
- Button Elements: Button elements natively have a tabindex, have keyboard interactions (ENTER/SPACE), and the native role of button, which means you do not have to tell assistive technology that it is, in fact, a button.
Using non-semantic elements (such as an anchor instead of a button) means you’ll have to implement:
- JS functionality for SPACE (the element has the native functionality for ENTER, but not SPACE).
- The role of “button” (for assistive technology).
- CSS to make it look like a button.
It’s even more difficult to use a span instead of a button. You’ll have to implement:
- JS functionality for the mouse click
- JS functionality for SPACE and ENTER keyboard interactions
- a tabindex attribute
- CSS to support focus
- CSS to make it look like a button
- The role of “button” (for assistive technology)
Rule 2: Do not change native semantics.
Do this:
<div role="tab"><h2>Heading</h2></div>
Don’t do this:
<h2 role="tab">Heading</h2>
To change the native semantics properly, you’d have to remember to change all of the JavaScript and CSS functionality to match so that assistive technology recognizes it as it should. It’s far easier to use the native semantics that the appropriate HTML5 elements provide.
Rule 3: All interactive controls must be usable with a keyboard.
If a user can interact with some part of your code using a mouse or touch, they must also be able to interact with it while only using a keyboard. If you don’t do this, you are providing a fundamentally different experience to different subsets of your users, which means it’s not accessible.
Rule 4: Do not use role=”presentation” or aria-hidden=”true” on a visible, focusable element.
Don’t do this:
<button role="presentation">Submit Form</button>
Don’t do this either:
<button aria-hidden="true">Submit</button>
If you use these attributes on visible, focusable elements, you hide them from a screen reader, which breaks the accessibility of that feature.
Rule 5: All interactive elements must have an accessible name.
Do this:
<label for="firstName">First Name</label>
<input type="text" id="firstName" />
This is also okay:
<label>First Name <input type="text" /></label>
Don’t do this:
<label>First Name</label>
<input type="text" />
Don’t do this either:
<div>First name <input type="text" /></div>
Providing an accessible name allows the assistive technology to read a relevant identification for that element that may otherwise be obvious to a sighted user.
Verifying the Rules
Following the rules will only be successful if you validate their effects. You should use the aXe Extension to ensure they (and other helpful rules) are followed consistently. You should also use a screen reader to verify the user experience of someone who only uses a keyboard.
aXe Extension
The aXe Chrome Plugin will show you accessibility issues as you are developing your application. If you’d rather work with this in your development environment than your test suite, install this extension.
Screen Reader
Investing a little time learning how to use already-available tools is invaluable. There are accessibility efforts that span most of the JS frameworks and common CMS solutions. A significant way to ensure that your product is accessible is to learn how to use a screen reader, and options are available for common development environments.
Mac Development Environment
- Voiceover is available for use with Safari; it comes bundled with the macOS system.
- Here’s a cheatsheet for the VoiceOver keyboard commands (PDF)
Windows Development Environment
- While there are other options, NVDA is a free screen reader that works with Firefox; this is the combination we recommend for developer use.
- Here’s a cheatsheet for the NVDA keyboard commands (PDF).
- Tip: Turn off the speech synthesizer by right clicking on the NVDA icon in the system tray, navigating to Preferences > Synthesizer, and selecting “No Speech” for the Synthesizer option. You can then use the Speech Viewer (Tools > Speech Viewer) and see what the screen reader would otherwise be saying out loud.
Better Accessibility in Your Team
aXe/ember-a11y-testing
The best way to set yourself up for success is to use the ember-a11y-testing addon. It uses the industry standard axe-core tool to test web pages for accessibility issues. With this addon, we can integrate that testing into our test suite, providing that level of protection to our application.
To use it, set up a series of tests to navigate to relevant screens, then execute the audit. Violations will fail the test.
Other Ember Tools
As part of the Ember A11y community team, we’ve contributed to ensuring solid support for developers who use the Ember.js framework. In addition to ember-a11y-testing, a number of other add-ons have been created specifically to make developing accessible code a bit easier.
- ember-a11y: supports relevant context focus for single-page applications (SPAs), and could be considered an upgrade to “skip links”. The current implementation of this addon will immediately apply focus to the most relevant piece of content based on actions users take (clicking buttons, links, etc). This allows screen readers to catch changes and read the right information, thus providing a much better experience for blind users.
- ember-a11y-landmarks: this addon helps by adding the correct landmark role to the element automatically.
- ember-component-attributes: this addon is great for adding accessibility to existing components. It allows the developer to add HTML and ARIA attributes without extending or reopening the component, which can help speed up development.
- ember-cli-template-lint: adds a test for each template, and asserts that all of your style rules have been satisfied.
Better Accessibility in Your Community
There are a few Slack places where you can participate in an accessibility-focused community:
The Ember community has a #topic-a11y channel in Slack, where we provide support and advice for Ember developers who are actively building code and have questions about what to do! If you are not using Ember (yet!), there’s also the A11y community Slack, where you can ask questions in dedicated channels for specific accessibility topics.
There are also places where you can contribute, to make accessibility support better for developers! Look to see if there’s a local A11y meetup that you can join. If you use open source software (OSS), visit the GitHub repo and see if there are accessibility-related issues that you can help fix, or even if accessibility is being considered at all.
By looking at accessibility from these three perspectives, you can see that developers are able not only to create better (new) code by learning the basics of accessibility but also able to improve existing code with each pull request. Thoughtful implementation of code can also lead to constructive conversations with the rest of the pillars of the team, providing a well-lit path to understand how we are all responsible for and can benefit from, a fully accessible product.
