Introduction
The inventor of the web, Sir Tim Berners-Lee, famously said:
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
We share Sir Berners-Lee’s vision.
Guided by the W3C’s accessibility guidelines, we are developing the game to be playable by all across a wide range of devices and browsers, including via the use of assistive technology.
Here we share the standards we use to train our remote team on web accessibility.
Front End Accessibility Standards and Testing Process
A11y is used as shorthand for accessibility.
Because a11y covers so much we use WCAG (Web Content Accessibility Guidelines) 2.1 AA standards to guide us. The WCAG standards are a set of guidelines and best practices curated by experts to help us to address a11y in a methodical way.
First Steps
If you are new to a11y, first understand who a11y is for and why it matters.
Next, complete this course to gain a complete understanding of a11y in development: Web Accessibility by Google provided by Udacity. The videos in this course refer to WebAIM's WCAG 2 Checklist.
The W3Cs recommended standards were updated in June 2018 to version 2.1. The training course was created before this update but the webaim checklist does include these updates.
Our Approach
These are our steps to understand incorporate a11y into design and development:
- Mockups and designs need to be assessed for a11y as much as possible. Recognizing this can take practice so this step can be done by the more experienced a11y devs.
- Develop to W3C standards
- Understand where the resources are that can help you
- Conduct a11y testing
1. Assessing Designs and Mockups for A11y
Things to look out for in designs:
- Heading order - important to provide the content structure to assistive technology
- Linear structure of HTML - visual structure is not available all users so check that the potential HTML structure will make sense.
- Make sure information is not conveyed through color only
- Analyse forms for accessibility - make sure that labels and input instructions are present and appear near the form controls.
- Hover only is not an option - hover is not available to touch interfaces or keyboard users so take this into account.
- Consider anything that may not work in a responsive layout
- Think about any custom components that are introduced in the designs and how these could be achieved accessibly
2. Development to W3C Standards
- Write semantic HTML where possible.
- When there is no element available understand how to use the ARIA attributes available to create custom components.
- Apply WCAG 2.1 guidelines
W3C Standards:
Whilst these documents are the standards and are very useful for reference they are also very long documents. To assist in applying the standards the following external resources section links to shorter and easier digested guidance.
3. Resources
Overview checklists:
Technique References
- W3C's Understanding WCAG 2.1 Guidelines
- Wuhcag's Guidance on each guideline - (note that this guide lists version 2.0 requirements. Additional criteria added in version 2.1 are demonstrated in Webaim's checklist)
Other useful resources
- MDN HTML Element Reference
- HTML5 Doctor
- MDN's ARIA resources
- W3C's Using ARIA
- W3Cs ARIA Practices
- A11y Project resource list
- Inclusive Components
4. A11y Testing Process
Use checklists to track and guide testing of component, widget, page or process.
If you are new to a11y use WebAIM's reference for approaching testing along with one of the overview checklists and reference against the technique references.
General steps
Run automated testing using either of the WAVE or aXe audit tools:
- Chrome Webaim WAVE Evaluation Tool - visual feedback about accessibility of web content. Chrome or Firefox.
- aXe page audit tool. Runs a11y audits in browser.
- The W3C validator can also help to determine whether any code is misspelled or is missing closing tags.
Fix any of the issues raised by the automated testing.
Do manual testing
- Use keyboard to navigate around interactive elements
- Use screen reader to test content makes sense when not visually consumed
- Test content scaling
Testing Tools
- Testing with WAVE
- NoCoffee Vision simulator - Chrome addon to simulate what users with different visial impairments will see
- High Contrast Simulator
- Understanding how to tab through interfaces - What is focus?
Browser Zoom
- Testing with TalkBack (Android Screen reader)
- Testing with VoiceOver (iOS screen reader)
Understanding Screen Reader Testing
Free Screen readers:
- NVDA (Windows Only)
- VoiceOver (iOS)
- Fangs screen reader emulator (Firefox only)
Browser and Screen Reader combinations to test with
Depending on the browser (UA) and screen reader (AT) combination used in testing you will get different results. Some UAs & ATs work better together than others, and some simply fail to work together much at all.
- IE + JAWS
- Firefox + NVDA
- Safari + VoiceOver
- Mobile Safari + VoiceOver for iOS
- Firefox + TalkBack for Android
In Screen readers and web browsers – what's the best pairing for testing?, Scott Hollier suggests Android TalkBack and Google Chrome
Game Accessibility Decisions
Browser zoom will cover the text resizing requirement - 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA). Also see Browser Zoom Great for Accessibility
Other Sources and further reading
Accessibility Guidance for Designers
To build an accessible game we need to understand what this organisational commitment means. This document aims to provide information for designers and design decision makers to achieve this.
What is Accessibility?
We use a set of standards - WCAG 2.1 (Level AA) - to guide us in supporting a multitude of people and technologies.
These standards help to provide all potential players with a better web experience. They mean:
- If any of our users cannot fully use a sense such as sight then the narrative context and game play can still perceived.
- The UI can be operated by keyboard, touch, mouse and a multitude of assistive technology.
- All our users can understand the UI and the content.
- The underlying code is robust enough to be consumed by a large amount of user agents (including browsers and screen readers).
What does this mean for designers and design decisions?
The underlying code is heavily influenced by the desired design and look and feel of the game so the front end developers have to take designs and evaluate the following:
How to communicate anything implied by the design to a player that would not experience it visually
Meaning that all context needs to be present even if it visually hidden and only made available to devices only consuming the underlying code.
How to achieve a flexible interface
A flexible interface means that text and content layout can adapt to the width available on a screen.
In addition, the game is data driven which can mean the data can change over time - the UI elements containing this content must be flexible enough not to break when data changes. This is also consideration for internationalisation.
The design must complement the content. All the UI elements designed will become the blueprints for the same elements across the game. If there is a design decision to limit characters for design purposes this needs to work in all uses across the game and that this limitation does not hinder the understanding of the content.
The content and its structure
Assistive technology uses the structure and order of the HTML to provide a user with an understanding the content of the page.
Why does this affect designers?
- Because HTML headings and heading levels provide a hierarchy to a non-visual user.
- Because instructions need to appear before an action or be related to an action
- Because headings, links and form controls are used to navigate the page and to find content.
- Because when game play processes take the user across several pages this content has to be findable.
So it is important that designers appreciate that structure and context matters when visual clues are not accessible by the user.
Guidelines for Designers
Videos used in these guidelines are from the free Google course on Web Accessibility provided through Udacity and refer to WebAIM's WCAG 2 checklist.
1. Color cannot be the only visual means of conveying information
Some users will not be able to see context provided by color alone so use color to highlight or complement what is already there.
- Watch Don't convey with color alone (2:02 mins)
2. Ensure sufficient color contrast
- Watch Meeting contrast requirements (3:07 mins, first 2 are applicable)
There is a ratio to ensure sufficient color contrast for all users. The contrast ratio should be at least 4.5:1. This applies to text but should also apply to icons or other elements that provide context.
To ensure an accessible color palette, designers are required to use a contrast checker tool. As the designer will choose the color palette it is more efficient that this is checked at the point of design rather than at the point of development.
Tools available for this:
- WebAIM's Contrast Checker
- Juicy Studio's Contrast Ratio Analyser
- The Paciello Group's Standalone tool for Windows or OSX
3. Provide visual focus indication
This requirement is for users that navigate the interface with a keyboard. It means they are able to understand which element currently has focus. The browser will provide a default focus ring but this can also be styled to complement the design.
4. Consider Structure Order and Content Context
Content order and content context matters to users of assistive technology. Watch these videos to understand of why the structure order and content context makes a difference.
- Watch Navigating with a screen reader (7:21 mins)
- Watch Other navigation options(0:22 mins)
- Watch Other navigation options example (3:40 mins)
- Watch Link anti-patterns (3:15 mins)
5. Clarity for forms and input controls
Rules to follow:
- Labels need to be placed near form controls to provide visual association.
- As a rule a label should be positioned to the left or above an input control.
- With the exception of checkboxes and radio buttons where they are positioned to the right.
- Input placeholders will not be considered as sufficient labeling as this label is then lost when the element has focus.
- Input controls must have visible boundaries.
- Help avoid mistakes by providing input instructions where appropriate.
- Place input instruction so it can be visually and structurally associated with the input control.
- We will not disable controls, instead we will have them enabled and will show an error message when the user clicks them. A disabled style can be applied as long as it adheres to the required contrast ratio.
Very occasionally exceptions to the rules are reasonable. For example, the search form is so common that it does not always need visual labeling. However in the game it is possible that different search functionality has different context so labeling may be needed.
Please check any deviation from these rules with the front end developers.
6. Hovering alone is not sufficient to provide additional information
Hover is not available to keyboard or touch so consider this when providing additional information that requires interaction to display. Also ensure styles are distinct enough for users to identify interactive elements such as links and buttons.
7. Touch Target
Aim to make make touch targets a minimum of 40px by 40px, ideally 44px by 44px, with a margin between targets
8. Browser zoom
Understand why we need sections to stack and different navigation for smaller screens and for browser zoom:
9. Create consistent navigation
Ensure consistent presentation of navigational aids so that they are easily identifiable.
Definitions
Assistive Technology
Assistive technology is an umbrella term for a broad range of devices, software and tools that help any person with a disability complete a task.... In the context of web development we're still talking about a diverse range of technologies that we want to support. People may interact with your website using a screen reader or braille display with a screen magnifier, via voice control, using a switch device, or some other form of assistive technology which adapts the page to create a more specific interface that they can use.
-- Google: Web Accessibility Course provided by Udacity, Assistive Technology Lesson
User Agent
A user agent is any software that retrieves, renders and facilitates end-user interaction with web content. User agents include web browsers, media players, add-ons (plug-ins & extensions), and web applications that help in retrieving, rendering and interacting with web content.