Plan

The goal and expectation is that all products and websites fully conform to accessible standards and are inclusive of users with disabilities. At IBM, it’s part of our corporate policy.

Some products may not achieve that goal in a single release. With the adoption of agile practices, releases are typically “works in progress.” One of the aims of this toolkit is to ensure that accessibility progresses with each release, just like other product features.

The three levels described in Pace of completion form a natural progression for releases. Based on a product’s accessibility risk assessment, managers should establish the accessibility target for a release, then communicate that target to the team.

For most major projects, except where accessibility poses significant risk, a first release will probably target completion of Level one accessibility topics. Subsequent releases will progress through Level two and three topics. Especially within design and development, topics are aligned to these levels across the disciplines. Design must complete their Level one tasks before development can complete the corresponding Level one tasks. This is discussed in Shift left for easier adoption.

Most products have at least a few videos associated with them. Your app or website may have a quick video introduction, or video may be a key part of your marketing or training. If video is a possibility for any of your documentation, you must plan to make it accessible.

Most videos fail accessibility. Many lack captions, almost all lack audio descriptions, and the video players themselves rarely meet requirements. In all, between the US and European accessibility standards, almost two dozen criteria specifically touch on video.

Video accessibility problems persist because they must be addressed across the product lifecycle. Video players are often chosen at the start of a project or release. Video content is often conceived or developed at a different time or by a different team than most other content. Finally, multiple accessibility needs must be assessed. Tactically, we recommend teams start by planning for captioning.

Even where teams generate captions for their video content, the outcome may not be accessible. That’s because the player needs to display captions in very specific ways to meet accessibility requirements. Use these criteria to assess the players under consideration:

Meeting these four criteria will allow you to address many requirements.

If your product or service will be offered for sale, you’ll likely need to complete an Accessibility Conformance Report (ACR) to document the level of conformance.

When a team creates an ACR for a release that does not achieve all three levels of this toolkit, some parts or features will not meet some requirements. You record these requirements as “partially supports.” To plan your release, it is important to understand the meaning and value of a release that partially supports accessibility as published in its ACR.

The ACR defines several levels of conformance for each requirement, including:

The ACR also provides a Remarks and Explanations area, where detailed comments can explain or justify the conformance achieved.

Potential purchasers and users of a product can use the ACR and its comments to assess the relative accessibility of a product. The more instances of “Partially Supports” or “Does Not Support” that exist, the less attractive a product becomes.

We planned this toolkit in such a way that a team completing only the Level one tasks will still achieve valuable accessibility. Many of the requirements likely to be most important to an evaluator will meet “Supports.” However, a product that does not follow all the guidance in this toolkit may end up with requirements in each category of conformance.

The Launch section shows how remarks can explain where the product doesn’t fully support the requirements. Clear improvements between releases of a product can help assure evaluators that accessibility is being addressed in a product. “Partially Supports” can still reflect progress.

View the ACR for an IBM product on IBM’s Accessibility Conformance Reports site.

Note: Websites do not typically publish ACRs, since they aren’t a product for sale. In that case, an accessibility conformance statement can be added to the website to document the level of conformance. As with ACRs, conformance statements can indicate progress, even when a conformance level has not been achieved. The W3C provides information about how to make conformance claims for a website.

Consider the following topics for product releases which face increased risk if they are not accessible.