4. Creating Digital Accessibility Culture
Assessing an Organization’s Current Digital Accessibility Status
One of the the accessibility committee’s first tasks is to determine where the company is in terms of its compliance with accessibility guidelines and to identify gaps where improvements are needed. Since you do not have an accessibility expert on staff, you decide to look into firms that provide accessibility auditing services.
Choosing an Accessibility Auditor
Unless there is already an accessibility expert on staff, organizations likely want to hire a third-party auditor or find a person to hire on as one.
It is typically easier to find an auditing service than to find an accessibility expert to hire. Depending on the size of the company, and the amount of digital information it produces, you may or may not want to hire a permanent accessibility person.
Finding a reputable auditing service can also be a challenge. With the growing public awareness of accessibility issues, there are a growing number of so-called accessibility experts popping up, taking advantage of the market for these services that has emerged with this awareness. You want to evaluate these auditor services to ensure their reputability.
Factors you might take into consideration when selecting an accessibility service could include:
- The number of years the service has been in business (the longer the better)
- The clients they have served (potential references)
- The accessibility of the service’s website (dead giveaway to search elsewhere, if their site is not accessible)
- Whether their process aligns with accessibility auditing best practices (not required, but advisable)
- Whether they provide self-service tools (most good firms provide automated test tools)
- Whether accessibility auditing is their primary business (be wary of firms offering accessibility auditing as an add-on service for an unrelated primary business)
- Whether they offer training (the ability to train your staff is a good sign)
There are a number of reputable international services, so companies do not necessarily need to choose a local auditor. Since most accessibility regulations are based on WCAG, most international and local services audit based on those guidelines (or they should).
Self-Assessing
Automated Accessibility Checkers
There are quite a number of automated tools for testing web accessibility with varying degrees of coverage and accuracy. Much like choosing an accessibility auditor, choosing a good testing tool also requires a little critical evaluation. You may refer to existing evaluations of these tools and choose based on your needs. You may also want to adopt a number of accessibility checkers that complement each other.
Keep in mind that no automated accessibility checker can identify all potential barriers. In most cases, some human decision-making is required, particularly where meaning is being assessed. For example, does an image’s text alternative describe an image accurately, or does link text effectively describe the destination of the link? Both require a human decision on the meaningfulness of the text.
There a number of different types of web accessibility checkers. Depending on your needs, one type may serve your organization better than others.
API-Based Accessibility Checkers
API stands for application programming interface. An API allows developers to integrate the accessibility checker into other web-based applications, such as web-content editors, to provide accessibility testing from within the application. For instance, with a content editor, the checker assesses the contents of the editor while creating and editing content. Tenon and AChecker provide APIs that can be used for integrations with other applications. To take advantage of an API, a developer would need to create the integration in many cases, though some applications may already have an integration with an accessibility checker.
Text-Based Accessibility Checkers
Text-based checkers typically output a list of accessibility issues it has identified; and, in some cases, provide recommendations to correct those issues. Some checkers may also categorize issues based on their importance or whether an issue is either a definite barrier or a potential barrier, which would need to be confirmed by a person. Some checkers evaluate single pages while others spider through a site and produce a site-wide accessibility report. These checkers often ingest one of the following: a URL of a web page, a user-uploaded HTML file, or copied and pasted HTML code; then, they produce a report based on the input provided. AChecker is a good example of a text-based accessibility checker, which also provides an API for integrations.
Visual Accessibility Checkers
A third type of accessibility checker provides a visual presentation of a web page, pointing out where the issues appear on a page. The WAVE accessibility checker is a good example of a visual accessibility checker.
Browser Plugin Accessibility Checkers
Some accessibility checkers are available as a browser plugin, making it easy, while viewing a web page, to click a button and get an accessibility report. The WAVE Chrome Extension is a good example of a browser-based plugin.
Other Accessibility Checkers
The accessibility checkers mentioned above are just a tiny sample of the tools available. A well-crafted Google search, using terms like “accessibility checker” turns up many more. Or, you can browse through the list of accessibility checkers compiled by the W3C at the following link.
Other Types of Automated Testing Tools
While using automated web-accessibility checkers is a good start for assessing the accessibility of an organization’s web resources, there are likely other tools needed to assess different types of content. Examples of such tools include:
- Colour Contrast Checkers
- Text Readability Testers
- HTML Markup Validation Testers
- PDF Accessibility Checkers
Manual Testing
As mentioned above, automated testing cannot identify all potential accessibility barriers. There are a few easy manual tests that can be used to identify issues automated checkers may not pick up.
- Tab Key Test: Determines whether all functional elements in web content are keyboard accessible. Place a mouse cursor in the location field of your web browser, then repeatedly press the Tab key on your keyboard and follow the cursor’s path through the web page. Any functional elements like links, buttons, tabs, or forms, among others, should all receive focus while tabbing through the page and, while in focus, should operate by pressing the Enter key or spacebar.
- Select-All Test: Determines keyboard accessibility also. While your mouse cursor is focused on a web page, press CTRL+A (CMD+A on Macs) to select all the content on the page. Any items that are not selected are potentially not keyboard accessible.
- Screen Reader Testing: A little more involved than the two tests above. Install a screen reader and navigate through a web page using the Tab key or arrow keys (in most cases). While listening to the output of the screen reader, determine if the output make sense; if not, there could be accessibility and usability problems. We recommend that web developers have a screen reader installed to test web content before it goes public. The ChromeVox screen reader works well for this purpose, installing as an extension for the Chrome web browser.
- User Testing: Though not always required, having actual users with disabilities navigate your company’s web content can turn up a variety of usability issues that an accessibility expert may not identify. When recruiting people with disabilities for testing, ensure they are comfortable navigating the Web and are able to use their assistive technologies effectively to get meaningful feedback on usability issues. Novice assistive-technology users may encounter problems related to their inexperience, rather than problems with the accessibility of the content.