“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.
- Use native HTML elements
- Understand the abilities of your framework
- Know how to use ARIA guidance
- Understand what you get free from design
Use native HTML elements where possible
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
div with an
onClick event when we can use the
button element? 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
select element 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.
Understand the abilities and limits of your framework
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
Know how to use ARIA guidance to make custom components more accessible
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:
- Specify correct ARIA roles, names, and descriptions on Design patterns and widgets
- Follow ARIA keyboard guidance per component
- Use ARIA landmark regions to denote content structure
Understand what you get free from design
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