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.1.
The Revised Section 508 Standard in the US requires that electronic support documentation, both web-based and non-web-based, must conform to WCAG 2.0 A and AA success criteria. In Europe, EN 301 549 V2.1.2 requires that the same documentation must conform to the same levels of WCAG, but at version 2.1 of the standard. This is a departure from the reduced accessibility requirements formerly applied to documentation in these jurisdictions.
Rather than have a separate documentation checklist, IBM now requires that when the support documentation is provided in electronic format, it must meet all checkpoints in the WCAG section of the 7.0 checklist.
Some examples of how documentation can be made accessible are:
- If the documentation is a video, captions and audio descriptions are provided.
- If the documentation contains illustrations, they include alternative text descriptions.
- The documentation is fully usable with only a keyboard.
Instructions: Test the documentation against all WCAG checkpoints. Pay particular attention to these common issues:
- 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.
- 1.3.1 Information and relationships: Define information, structure, and relationships, including in forms, lists and tables.
- 1.3.2 Meaningful sequence: Define document reading order.
- 1.4.1 Use of Color: Any information that is conveyed by color is also evident without color.
- 1.4.3 Contrast (Minimum): The contrast between text and its background color meets sufficient levels for visibility.
- 1.4.11 Non-text Contrast: The contrast between important non-text content (a UI component or meaningful graphic) and its background meets sufficient levels of visibility.
- 2.1.1 Keyboard: Provide an accessible method to navigate long and protected documents.
- 2.4.2 Page Titled: Documents have titles that describe topic or purpose.
- 2.4.4 Link Purpose: The purpose of each link can be determined from the link name or associated text.
- 2.4.6 Headings and Labels: Headings and labels describe topic or purpose.
- 3.1.1 Language of page: Define the default language.
- 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input.
Ensuring that documentation meets WCAG 2.0 Level A and AA success criteria will have similar considerations regardless of the technology platform being used. Each section of the Technology-specific techniques provides links to vendor- or third-party-supplied information that can help create accessible content for different technologies.
Word has built-in features for people with different abilities and includes an accessibility checker that locates elements that might cause problems for people with disabilities. Visit Microsoft for more information on Word accessibility.
Because PowerPoint presentations usually consist of many images and decorative flourishes, people who are blind or have low vision can have trouble reading them. Visit Microsoft for information on how to Make your PowerPoint presentations accessible.
A spreadsheet is rarely used as a tool for documentation. For situations where Excel is used for documentation, see Microsoft’s documentation Make your Excel spreadsheets accessible.
Microsoft HTML Help
Most help systems contain substantial information on how to produce accessible content. See the Microsoft article Making Your Help System Accessible.
EPub is, at its foundation, HTML. If instructions to make HTML accessible are followed, documentation can be exported as accessible EPub. Visit Adobe for guidance for creating EPub documentation with InDesign.
For other authoring tools that create EPub documents, locate and implement accessibility features of those tools.
Electronic support documentation in PDF format must be accessible. Visit Adobe for information on how to Create and verify PDF accessibility. Review non-vendor documents, such as AIIM's Achieving WCAG 2.0 with PDF/UA and PDF Techniques for WCAG 2.0. Consider using the US Department of Health and Human Service's PDF checklist or their making accessible PDF resources.
If using DITA to produce electronic support documentation, follow techniques to ensure accessibility of DITA output.
Many links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.1. W3C Recommendation 05 June 2018: http://www.w3.org/TR/WCAG21/
Copyright © 1994-2019 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.
Copyright © 2001, 2019 IBM Corporation