Skip to main content


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:

  • 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 4.1.1 Parsing 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.

    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.

    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.