Developers can shorten the path to accessibility by understanding and addressing some key considerations.
Pace of completion
We designed this site to allow teams to adopt accessibility at their own pace. It divides tasks and considerations into three levels that help achieve the IBM accessibility requirements.
Essential tasks with high user impact, normally with the least investment. Completing these tasks addresses many of the top concerns of people with disabilities.
You should complete these tasks in addition to the first level to address the next-most important issues that may keep certain users from fully using your product.
Completing all three levels achieves compliance with the A and AA criteria of the Web Content Accessibility Guidelines (WCAG).
Product teams should include accessibility targets in each release. As they do, each team member takes on specific tasks to ensure the product is set up for success. Improved, sustainable accessibility is the outcome. Remember, every feature you make more accessible improves the experience for some users. You don’t have to solve it all to improve.
“My mindset towards accessibility changed when I realized that my job as a developer is mostly to make sure I’m not breaking anything.”
During research for our new guidance, IBM found that experienced
accessibility developers have learned that certain decisions both increase accessibility and reduce effort.
As one developer said, “For the most part, the web is accessible when we use semantic HTML. Our responsibility as developers is to make sure we use the elements for the purpose they were intended. A simple example: why create a button as a
onClickevent when we can use the
buttonelement? Bottom line is that we have to pay attention to the implementation decisions we make during development because they might prevent users of assistive technologies from using what we build.”
When developers use native HTML elements, they get a lot of things for free:
- Programmatic information for name, role and value
- Default appearance
- Keyboard interaction
HTML elements automatically meet 4.1.2 Name, Role, Value, IBM accessibility requirements. If developers don’t change the default appearance of elements, they are also exempt from meeting visual requirements for 1.4.11 Non-text Contrast, IBM accessibility requirements. Finally, developers need not handle built-in keyboard events. For example, an HTML
selectelement has built-in keyboard interaction, including allowing users to jump to any item by first letter. And, almost all browsers support the selection of multiple contiguous and non-contiguous items via the Shift and Control/Command keys.
One of the important activities in the plan phase covers considerations for choosing an accessible framework or component library. If the architect has followed this guidance, developing accessible content becomes a lot easier. But there are always limitations to frameworks.
- Get familiar with the accessibility features and documentation
- Review and open accessibility bugs against the framework
- Adapt existing components with caution (don’t break things)
- Recheck the accessibility of components you use or tweak
If a project must use custom widgets, there are several things developers can do to ensure better accessibility. Browsers and assistive technologies support the Accessibility Rich Internet Applications (ARIA) technical specification from the W3C. Applying the correct role to an element will give assistive technology users critical context and semantics. But applying the wrong role will confuse them.
The ARIA authoring practices, W3C provide component-specific guidance and recommended keyboard interaction. Take time to learn the following:
Developers get some things “for free” from design. Contrast and color design decisions cover many accessibility areas. All developers need to do is follow the wireframes as normal with no accessibility-specific tasks. The WCAG requirements built into the design should include:
- Enough contrast, for both text and non-text content
- No reliance on color as the only way to distinguish content
- No triggers for seizures from flashing content
- Videos with captions
Use native HTML elements where possible
Understand the abilities and limits of your framework
Know how to use ARIA guidance to make custom components more accessible
Understand what you get free from design
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.
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.
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.
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.
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:
*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.