IBM Accessibility Checklist

This is the IBM Accessibility Checklist - Version 7.0. It replaced IBM Accessibility Checklist for Software - Version 6.1, IBM Accessibility Checklist for Web and Web-based Documentation - Version 6.1 and Documentation checklist version 2.1 on July 18, 2017.

This unified checklist and its checkpoint pages ensure that products comply with the Revised US Section 508 standards. It also captures additional requirements needed to meet European standard EN 301 549. See the Impact Analysis for how requirements have changed from the prior checklists.

Each section indicates whether it is relevant to web ( Web ), non-web software ( SW ) or support documentation ( Doc ). Review Using the IBM Accessibility Checklist for more information. The Summary of Changes lists all substantial modifications to this checklist since its release.

Contents

WCAG 2.0 Checkpoints

Web SW Doc These checkpoints apply to all electronic content, whether web or non-web software or documentation.

Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

1.1.1 Non-text Content. All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. (Level A)

Guideline 1.2 Time-based Media: Provide alternatives for time-based media.

1.2.1 Audio-only and Video-only (Prerecorded). For prerecorded audio-only or video-only media, an alternative provides equivalent information. (Level A)

1.2.2 Captions (Prerecorded). Captions are provided for all prerecorded audio content in synchronized media. (Level A)

1.2.3 Audio Description or Media Alternative (Prerecorded). An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media. (Level A)

1.2.4 Captions (Live). Captions are provided for all live audio content in synchronized media. (Level AA)

1.2.5 Audio Description (Prerecorded). Audio description is provided for all prerecorded video content in synchronized media. (Level AA)

Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.1 Info and Relationships. Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

1.3.2 Meaningful Sequence. When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

1.3.3 Sensory Characteristics. Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)

Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.

1.4.1 Use of Color. Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

1.4.2 Audio Control. If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

1.4.3 Contrast (Minimum). The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, with a 3:1 ratio for large-scale text. (Level AA)

1.4.4 Resize text. Text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

1.4.5 Images of Text. If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text. (Level AA)

Principle 2: Operable - User interface components and navigation must be operable.

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

2.1.1 Keyboard. All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level A)

2.1.2 No Keyboard Trap. If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

Guideline 2.2 Enough Time: Provide users enough time to read and use content.

2.2.1 Timing Adjustable. For each time limit that is set by the content, the user can turn off, adjust, or extend the limit. (Level A)

2.2.2 Pause, Stop, Hide. For moving, blinking, scrolling, or auto-updating information, the user can pause, stop, hide, or adjust the information. (Level A)

Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.

2.3.1 Three Flashes or Below Threshold. Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)

Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

2.4.1 Bypass Blocks. A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) *N/A for non-web documents and software

2.4.2 Page Titled. Web pages, non-web documents, and software have titles that describe topic or purpose. (Level A)

2.4.3 Focus Order. If content can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

2.4.4 Link Purpose (In Context). The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context. (Level A)

2.4.5 Multiple Ways. More than one way is available to locate a Web page within a set of Web pages except where the Web page is the result of, or a step in, a process. (Level AA) *N/A for non-web documents and software

2.4.6 Headings and Labels. Headings and labels describe topic or purpose. (Level AA)

2.4.7 Focus Visible. Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

Principle 3: Understandable - Information and the operation of user interface must be understandable.

Guideline 3.1 Readable: Make content readable and understandable.

3.1.1 Language of Page. The default human language of Web pages, non-Web documents, or software can be programmatically determined. (Level A)

3.1.2 Language of Parts. The human language of each passage or phrase in the content can be programmatically determined. (Level AA)

Guideline 3.2 Predictable: Make content appear and operate in predictable ways.

3.2.1 On Focus. When any component receives focus, it does not initiate a change of context. (Level A)

3.2.2 On Input. Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)

3.2.3 Consistent Navigation. Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA) *N/A for non-web documents and software

3.2.4 Consistent Identification. Components that have the same functionality within a set of Web pages are identified consistently. (Level AA) *N/A for non-web documents and software

Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.

3.3.1 Error Identification. If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)

3.3.2 Labels or Instructions. Labels or instructions are provided when content requires user input. (Level A)

3.3.3 Error Suggestion. If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)

3.3.4 Error Prevention (Legal, Financial, Data). For content that causes legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, the user can reverse, correct, or confirm the action. (Level AA)

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

4.1.1 Parsing. In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

4.1.2 Name, Role, Value. For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

4.1.3 Accessibility-supported technologies only. Use accessibility supported technologies. Any information or functionality that is implemented in technologies that are not accessibility supported must also be available via technologies that are accessibility supported.

Revised 508 Non-Web Software Checkpoints

SW These checkpoints must be completed by all software applications that are not web-based, including mobile apps.

502 - Interoperability with Assistive Technology

502.2.1 User Control of Accessibility Features. Platform software shall provide user control over platform features that are defined in the platform documentation as accessibility features.

502.2.2 No Disruption of Accessibility Features. Applications shall not disrupt platform features that are defined in the platform documentation as accessibility features.

502.3.1 Object Information. The object role, state(s), properties, boundary, name, and description shall be programmatically determinable.

502.3.2 Modification of Object Information. States and properties that can be set by the user shall be capable of being set programmatically, including through assistive technology.

502.3.3 Row, Column, and Headers. If an object is in a data table, the occupied rows and columns, and any headers associated with those rows or columns, shall be programmatically determinable.

502.3.4 Values. Any current value(s), and any set or range of allowable values associated with an object, shall be programmatically determinable.

502.3.5 Modification of Values. Values that can be set by the user shall be capable of being set programmatically, including through assistive technology.

502.3.6 Label Relationships. Any relationship that a component has as a label for another component, or of being labeled by another component, shall be programmatically determinable.

502.3.7 Hierarchical Relationships. Any hierarchical (parent-child) relationship that a component has as a container for, or being contained by, another component shall be programmatically determinable.

502.3.8 Text. The content of text objects, text attributes, and the boundary of text rendered to the screen, shall be programmatically determinable.

502.3.9 Modification of Text. Text that can be set by the user shall be capable of being set programmatically, including through assistive technology.

502.3.10 List of Actions. A list of all actions that can be executed on an object shall be programmatically determinable.

502.3.11 Actions on Objects. Applications shall allow assistive technology to programmatically execute available actions on objects.

502.3.12 Focus Cursor. Applications shall expose information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface components.

502.3.13 Modification of Focus Cursor. Focus, text insertion point, and selection attributes that can be set by the user shall be capable of being set programmatically, including through the use of assistive technology.

502.3.14 Event Notification. Notification of events relevant to user interactions, including but not limited to changes in the component’s state(s), value, name, description, or boundary, shall be available to assistive technology.

502.4 Platform Accessibility Features. Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) listed below:

  1. Section 9.3.3 Enable sequential entry of multiple (chorded) keystrokes;
  2. Section 9.3.4 Provide adjustment of delay before key acceptance;
  3. Section 9.3.5 Provide adjustment of same-key double-strike acceptance;
  4. Section 10.6.7 Allow users to choose visual alternative for audio output;
  5. Section 10.6.8 Synchronize audio equivalents for visual events;
  6. Section 10.6.9 Provide speech output services; and
  7. Section 10.7.1 Display any captions provided.

503 - Applications

503.2 User Preferences. Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor.

EXCEPTION: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2.

503.3 Alternative User Interfaces. Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services.

503.4.1 Caption Controls. Where user controls are provided for volume adjustment, ICT shall provide user controls for the selection of captions at the same menu level as the user controls for volume or program selection.

503.4.2 Audio Description Controls. Where user controls are provided for program selection, ICT shall provide user controls for the selection of audio descriptions at the same menu level as the user controls for volume or program selection.

Revised 508 Authoring Tools Checkpoints

Web SW These checkpoints must be completed by all applications that include tools for authoring content.

504 - Authoring Tools

504.2 Content Creation or Editing. Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility.

EXCEPTION: Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code.

504.2.1 Preservation of Information Provided for Accessibility in Format Conversion. Authoring tools shall, when converting content from one format to another or saving content in multiple formats, preserve the information required for accessibility to the extent that the information is supported by the destination format.

504.2.2 PDF Export. Authoring tools capable of exporting PDF files that conform to ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1).

504.3 Prompts. Authoring tools shall provide a mode of operation that prompts authors to create content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 for supported features and, as applicable, to file formats supported by the authoring tool.

504.4 Templates. Where templates are provided, templates allowing content creation that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 shall be provided for a range of template uses for supported features and, as applicable, to file formats supported by the authoring tool.

Revised 508 Documentation Checkpoints

Web SW Doc These checkpoints must be completed for all products, whether the documentation is integrated into the application or provided separately.

602 - Documentation

602.2 Accessibility and Compatibility Features. Documentation lists and explains accessibility and compatibility features, including keyboard access.

602.3 Electronic Support Documentation. Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0.

EN 301 549 Additional Requirements

The following additional checkpoints are required to meet the European standard used in government procurement of accessible products. These are additional requirements of the EN 301 549 standard that aren't covered by the Revised Section 508 Standards.

ICT with Video Capabilities

Web SW Requirements in clause 7 apply only to web or non-web software which is a video player or contains an embedded video player. Only applications which are video players need to complete 7.1.3, 7.2.3 and 7.3. For applications that contain embedded players, only 7.1.1, 7.1.2, 7.2.1 and 7.2.2 need to be completed.

7.1.1 Captioning Playback. Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

7.1.2 Captioning Synchronization. Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions.

7.1.3 Preservation of Captioning. Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 and 7.1.2.

7.2.1 Audio Description Playback. Where ICT displays video with synchronized audio, it shall provide a mechanism to select and play available audio description to the default audio channel.

7.2.2 Audio Description Synchronization. Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.

7.2.3 Preservation of Audio Description. Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

7.3 User Controls for Captions and Audio Description. Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

Non-Web Documents

Doc Requirements in clause 10 apply to documents that are not web pages.

10.2.39 Caption Positioning. Where ICT is a non-web document that contains synchronized media with captions, the captions should not obscure relevant information in the synchronized media.

10.2.40 Audio Description Timing. Where ICT is a non-web document that contains synchronized media with audio description, the audio description should not interfere with relevant audio information in the synchronized media.

Interoperability

SW Sub-clause 11.3 covers non-web platform software.

11.3.2.3 Use of Accessibility Services. Where the software provides a user interface it shall use the applicable documented platform accessibility services. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.

Authoring Tools

Web SW Sub-clause 11.6 covers the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.

11.6.4 Repair Assistance. If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web content) or 10 (Documents) as applicable, then the authoring tool shall provide repair suggestion(s).

Using the IBM Accessibility Checklist

Checkpoints are divided into sections that match the standards they reflect or enforce.

502 Interoperability with Assistive Technology and 503 Applications are parts of the Revised Section 508 requirements.

Platforms, software development toolkits, and software applications must comply with the 502 Interoperability checkpoints. Applications must comply with 503 Applications.

Examples of platforms are operating systems (including mobile), web browsers, plug-ins to web browsers which render a particular media or format, and sets of components which allow other applications to execute.

Applications may be web-based or client-side software. Examples of applications are email clients, word processors, help desk systems, content management systems, and e-learning courseware. There are some additional notes in the rationales or general techniques of some checkpoints on how to apply WCAG 2.0 to non-web software, or if a checkpoint does not apply to non-web software. These notes are specific to non-web software and should be disregarded by web development teams.

Revised 508 Documentation Checkpoints

Support documentation for any content must be confirmed for accessibility, whether the documentation is integrated into the application or provided separately.

EN 301 549 Additional Requirements

The Revised Section 508 standards and the European EN 301 549 standard are closely aligned. However, these additional requirements of the European standard aren't covered by the Revised Section 508 Standards.

Hardware and Closed Systems

IBM teams can read about the status of IBM hardware and closed systems, as related to 508 Refresh, on the legacy internal IBM hardware page.

Note that hardware products that include any new or revised documentation or software (such as for remote connectivity or operation) must complete the new checklists for these items and produce the Accessibility Conformance Report (i.e., VPAT), even if the hardware itself is exempt from meeting the hardware requirements in the Revised 508 Standards.

Testing and Compliance Reporting

IBM teams must use this checklist in conjunction with the following internal resources, as well as other information available ONLY internally on w3.ibm.com/able:


Copyright © 2001, 2017 IBM Corporation

Many links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.