Check with users and work with designers upfront to save time as you begin to:
- implement color combinations with accessible contrast
- determine focus outline styling
- improve keyboard focus order
- define landmark roles, and heading hierarchy
Coding
Use proper accessibility coding practices for custom-built interactive elements.
Help users who can’t see the user interface identify an element’s role, what an element is (button, menu, etc.), as well as any other attributes associated with that element. Being clear about these things helps make the user’s interaction with your interface more intuitive.
Take away tips
Prepackaged toolkits are often not accessible
Pre-packaged JavaScript widgets don’t necessarily have accessibility built in. Many toolkits may say they are “Section 508 compliant”, but most have not been updated to meet the Revised Section 508 standards.
Use native elements
Standard platform and HTML elements typically have all of the accessibility features built-in, with no additional work. Use styling like CSS to change the look (but not the behavior) of these elements. Make sure they have text content, a label or alternative text.
Determine your needs for mobile support
Mobile platforms beyond iOS have varied accessibility support, so it is important to learn the limitations of the platform you’re developing in to avoid the pitfalls of inaccessible elements. When in doubt, adopt platform-provided accessibility and make decisions in harmony with the IBMaccessibility checklist.
Learn more
Keyboard
Enable keyboard access to empower users who are unable to effectively use a mouse.
Users who cannot use a mouse include the blind and those with physical disabilities that affect their fine motor skills or hand motion. Native elements have keyboard access built in with no additional work, but if you build custom elements, you will need to code it in manually.
Common keyboard interactions include using the Tab key to navigate to different interactive elements and using the Enter key or the Spacebar to activate an in-focus element. Arrow keys are used to navigate within more complex elements, like menu items in a menu.
The order in which interactive elements receive focus should be logical and predictable. In the web you create the tab flow hierarchy by using the order of the source code to arrange the order of the keyboard navigation. Begin with the header, followed by the main navigation, then page navigation (from left to right, top to bottom), and end with the footer.
Take away tip
Give users clarity and control.
Keep the keyboard focus as a different visual affordance from the selection status. Make it as visually obvious as you can so the user can see it easily. Provide a “Skip to content” option when there is lengthy navigation so a user may access main content faster.
Contrast
Use coding techniques for accessible contrast.
For Web content, any CSS background images will be turned off in Windows high contrast mode. If the background image conveys any information, provide a visible alternative in its place—such as a meaningful text equivalent—that will appear instead of the image.
In high contrast mode, pages are reduced to a basic set of four colors: text (foreground), background, selection and links. If a background image is used to make white text appear on a darker background, this means the text might disappear when a “High Contrast White” theme is used. In this case, provide icons that are more easily viewable in high contrast mode.
For non-high contrast mode, take care to utilize the accessible color combinations specified in the design for text against its background color. If the text or background color’s opacity or saturation are changed, the color contrast must be retested to ensure the WCAG 2.0 Level AA minimum contrast requirement is met.
Take away tips for accessible content
Add labels
Make certain all form UI elements have labels.
Represent data in more than one way
If a data visualization cannot be made accessible, it must be conveyed to the user in another way that provides the same insights and meaning. One way is to include a data table.
Provide multiple means for understanding
Provide instructions for understanding and operating content that do not rely solely on components’ sensory characteristics, such as shape, size, visual location, orientation, or sound. For example, clarify guidance like, “Click the red button on the right”.
Make actionable content obvious
Reread to confirm a link’s purpose is clear on its own. For example, avoid vague terms like, “Click here” or “More...” or add programmatic context for someone who can’t see what these links are referring to.
Include the global community
Build designs to adapt to written and spoke languages of all origins. Content-focused product should work just as well when read right-to-left as left-to-right.
Reduce distraction
Check that dynamically changing content grabs a user’s attention when it is important but doesn’t interfere with the user when it is not.
Structure
Structural markup provides people who can’t see the user interface an idea of the overall layout and purpose.
For web content, the heading structure, HTML semantic elements and WAI-ARIA landmark regions provide a table of contents to help the user understand and navigate to the underlying structural areas of the content. Native software has constructs that provide structure, such as groups, menus and lists.
- Ensure each page has an H1 tag and that it is the first heading found on the page. Any other heading tags should be in logical order and no levels should be missing.
- Program using semantic HTML (nav, header, article, etc.) for built-in accessibility and don’t rewrite native elements.
- 1. Make sure all your image tags have alt attributes. If you are using SVGs, include a title element. If the image does not convey meaning, like when the image is an avatar, include an empty string as the alt text.
- Check that the default human language of each Web page can be programmatically determined by including a lang attribute in the html tag.
<div>
<h1>Follow your users</h1>
<section>
<h2>Empathy can't be outsourced</h2>
<p>When a team directly interacts...</p>
</section>
<section>
<h2>Where you come in</h2>
<p>When you keep users...</p>
</section>
</div>
The page header should be given an H1 tag and subsequent headers should be given sequential ordering (H2, H3, etc.).
Testing
Perform accessibility automated and manual tests.
Studies have shown that the earlier bugs are found, the less expensive they are to fix. You can learn accessible programming practices by using the Dynamic Assessment Plugin to check your web code.
DAP testing helps you:
- Identify issues early to prevent propagation of the same code errors into multiple modules.
- Become more proficient at putting in the accessibility code as you work rather than adding it in later.
- Scan a page quickly and instantly have full interactive reports of issues found in the content.
- Review on-page highlighting of each issue using the tool’s guidance on how to fix it.
Check as you go
Assess the tools
The Dynamic Assessment Plugin (DAP) for Chrome and Automated Accessibility Checker (AAT) on Bluemix allow you to test quickly and resolve accessibility violations before an application is deployed.
Verify using keyboard
Check your focus indicator, tab order and component keyboard interaction, and bypass blocks. Make sure there’s a keyboard equivalent for any mouseover actions. It is important to actively look for items missing from the tab order, or hidden items that should not be in the tab order, not simply to follow along with the visual focus indicator.
Confirm page interaction
Trigger context changes when users activate a control by pressing Enter or Tab to move to the next component. When a dialog or new page replaces a user’s current focus, the user should return to their prior focus once that overlay is dismissed to maintain the user’s point of regard.