Skip to main content

Core considerations

Developers can quickly improve products by the simple act of unit testing for accessibility. Run an automated tool to capture detectable violations. Check zoom and reflow of the content. Then before you check-in your code, put your mouse aside and make sure you can fully operate the components with a keyboard. Checking as you go with a keyboard is the easiest way to improve accessibility and reduce future effort and risk.

Incorporate and run verification tools

IBM has taken several steps to ease accessibility testing and improve automation. As developers, you can manually run the Accessibility Checker for Chrome or Firefox from your browser or IDE. You can view issues by element or by accessibility requirement. You can also add accessibility into your continuous integration testing. Ensuring that checkers run without violations helps developers meet 4.1.1 Parsing and 4.1.2 Name, Role, Value.

Checkmark
Accessibility Checker passes without violations
Checkmark
Resolve recommendations and issues which need further review

Check that the content can be zoomed

Developers can quickly validate whether they can adjust the content size while remaining accessible. Use the browser to zoom the content to 200% and ensure that text still fits in its containers and nothing odd happens to positioning of controls and other elements. Then keep increasing up to 400%. Ensure that the breakpoints match the design specifications. All content should be visible without requiring horizontal scrolling.

Checkmark
Text can zoom to 200% without becoming truncated or hidden
Checkmark
Content can zoom to 400% without horizontal scroll bars appearing
Checkmark
Break points match responsive design specifications
Checkmark
Content reflows according to design specifications

Confirm component keyboard interaction

Every component must be keyboard operable. As developers confirm the success of the keyboard operation (which should be indicated in the wireframes), they also confirm they never become stuck in a keyboard trap. Keys used for interaction are Escape, Space bar, Enter, Home, End, Page Up, Page Down, and the arrow keys. Complex interactions may also use modifier keys such as Shift, Ctrl, and Alt. IBM recommends the ARIA authoring practices as a model for keyboard interaction. Developers can also use this interaction test to confirm that visual indicators for states (selected/unselected, expanded/collapsed) align with the UX design.

Checkmark
You can perform all interactions for a widget with the keyboard
Checkmark
You can traverse all items in forward and reverse order
Checkmark
Components support standard keyboard interaction, or provide clear and accessible documentation for keyboard interactions
Checkmark
Visual indicators of states exist

Check tab order

When testing a larger portion of the content, repeatedly press the Tab key to traverse all interactive elements or groups of elements. This allows you to reconfirm several things:

Checkmark
You can press the Tab key to reach all operable parts of the content*
Checkmark
From the bottom of the page, you can press Shift+Tab to reach all operable parts of the page
Checkmark
Elements take tab order in a way that preserves meaning or operation
Checkmark
At each tab stop, there is a visual focus indicator
Checkmark
Actively look for items missing from or incorrectly added to the tab order.

*Acceptable behavior for complex components and groups of widgets, such a menus or toolbars, is to use a single tab stop, with arrow key navigation between the items in the group or complex component.