Develop – IBM Accessibility

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.

Level 1

Essential tasks with high user impact, normally with the least investment. Completing these tasks addresses many of the top concerns of people with disabilities.

Level 2

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.

Level 3

Completing all three levels achieves compliance with the A and AA criteria of the Web Content Accessibility Guidelines (WCAG).

Release targets

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.

Reducing effort

“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 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

Unit testing

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 several requirements including 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

Accessibility Checker passes without violations

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.

Addresses 1.4.4 Resize text and 1.4.10 Reflow.

Text can zoom to 200% without becoming truncated or hidden

Content can zoom to 400% without horizontal scroll bars appearing

Break points match responsive design specifications

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.

Checks 2.1.1 Keyboard and 2.1.2 No Keyboard Trap.

You can perform all interactions for a widget with the keyboard

You can traverse all items in forward and reverse order

Components support standard keyboard interaction, or provide clear and accessible documentation for keyboard interactions

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:

You can press the Tab key to reach all operable parts of the content*

From the bottom of the page, you can press Shift+Tab to reach all operable parts of the page

Elements take tab order in a way that preserves meaning or operation

At each tab stop, there is a visual focus indicator

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.

Confirms 2.4.3 Focus Order and 2.4.7 Focus Visible.