Validators

When attempting to build an accessible web site or web application, the very first and most important step is to make sure that the markup and code you are writing has valid code syntax. Any errors in coding, and the browsers and assistive technology won’t be able to correctly parse and interpret the content, layout, or choices available to the user. This is necessary to provide a robust and accessible code base.

As mentioned in Chapter 4, one way to perform this validation is using the traditional W3C web-based validators.

W3C Markup Validation Service

The Markup Validation Service¹ shown in Figure 6-1 allows you to provide HTML content via URL, File Upload, or Direct Input (copy-and-paste).

Ideally the results will come back clean, but the first time you run the tool you’re likely to get a number of warnings and errors. In Figure 6-2 there are a few warnings, but nothing that would pose a problem for accessibility.

Note that while you can use this tool manually, there are a number of variations of the checker intended for command line or continuous integration use. See the Nu Html Checker web site² for more information.

Note

All tools have limitations and purposes for which they were built. When choosing a tool make sure you know what those are. For example, Nu Html Checker specifically states in their documentation that:

“The Nu Html Checker should not be used as a means to attempt to unilaterally enforce pass/fail conformance of documents to any particular specifications; it is intended solely as a checker, not as a pass/fail certification mechanism.” ²

W3C CSS Validation Service

Similar to the HTML service, The CSS Validation Service³ (Figure 6-3) allows you to provide CSS content via URL, File Upload, or Direct Input (copy-and-paste).

When the CSS is clean and error-free, you not only get a friendly message of congratulations, you are told exactly what CSS level your page supports and even presented with valid CSS buttons you can include on your web site like it’s 1998 again. See Figure 6-4.

Note that even if no errors are found, there may be a long list of warnings, particularly in the case of vendor-specific extensions or pseudo-elements. This tool remains mostly useful for manually spot-checking pages or files, although it is downloadable⁴ as a Java command-line utility.

If using a CSS precompiler such as SASS, LESS, or Stylus, the need for CSS validation is diminished as most errors will prevent the CSS from being compiled. However, spot checking that vendor-specific markup is present can be useful for cross-browser compatibility.

Development Environment

Most development environments, from text editors to IDEs, will provide some level of syntax highlighting for HTML, CSS, SASS/SCSS, LESS, JavaScript, and TypeScript (among others). This provides you with excellent real-time feedback when writing new code, and it is recommended to keep this feature activated at all times.

In the following example (Figure 6-5), Visual Studio (VS) Code is using red text and underline to mark errors, and green underlines to mark warnings.

In the next example (Figure 6-6), the HTMLHint extension⁵ uses a similar set of markings to indicate errors and warnings in an HTML file.

Command Line

Used together within your build process, these tools are capable of automatically checking for formatting and syntax errors that can cause problems down the line with accessibility and can help prevent bugs at the same time. This can be implemented at any time but should definitely be completed by Phase 3 in your Action Plan as indicated in Chapter 5.

Content Testing

One of the primary goals of accessibility is to make content available to all. Therefore, the content itself is as important as its structure. Considerations of audio, video, and animation content, as well as color contrast, have all been discussed in Chapters 1 and 4. But textual content may also need to be reviewed.

The structure and word choice in your textual content can reduce accessibility to the information. Education level, reading ability, and cognitive or neurological disabilities may all factor into the ability for a person to comprehend the content on your web site or application.

The Readability Test Tool,⁶ shown in Figure 6-7, can help you ensure that the reading level of your content is appropriate to your audience. The tool can be embedded on your web page but, like the validators mentioned earlier, you can also run it directly via URL or Direct Input.

Conformance Testing

While we can’t entirely replace manual testing, there are a large number of success criteria tests that can be automated. The tools presented in this section handle this task in a variety of ways. Typically, these tools will run in a browser, either manually or through a headless browser (a browser without a graphical interface, usually run via a command line), in order to evaluate a page in its full context. Because of this, cross-browser support may become a critical issue for your accessibility projects.

Visualization

If you’re just getting started with web accessibility, one of the challenges is understanding how a browser or assistive technology sees the web page. Tools that overlay accessibility information over the existing content can be extremely helpful in understanding what’s going on behind the scenes.

Tota11y

The Tota11y⁸ visualization tool from Khan Academy is very interactive, allowing you to choose what is highlighted, while continuing to interact with the page normally. Tota11y is a simple JavaScript file that can be embedded on your pages. It can also be installed as a bookmarklet, allowing you to run the tool without including it directly on the page. See Figure 6-8.

WAVE

WebAIM’s WAVE⁹ (Web Accessibility Evaluation Tool) can also provide visualizations on the page. Running the browser extension adds visual “tags” to the page which can be interacted with for additional information. Figure 6-9 shows the wave toolbar to the left of the web page. The tool overlays markers to show significant structure items such as the navigation, headers, and alternative text.

The output is highly configurable, including selecting by conformance level or even excluding individual guidelines or success criteria. Figure 6-10 shows the individual categories expanded. Each category (Errors, Alerts, Features, Structural Elements, HTM5 and ARIA, Color Contrast Errors) can be selected to show visual indicators of the element or error on the page or deselected to hide the indicators and reduce distraction.

When reviewing the results, selecting information icon will take you to documentation on the success criteria straight from WCAG, including links directly to the relevant WCAG guidelines and criterion. Figure 6-11 shows the wave browser plug-in’s documentation view.

Assessment

While exploratory assessments and visual assessment of the page are extremely useful during development, these methods would be extremely labor intensive to use as the primary mode of evaluating conformance on a continuing basis.

Axe

Deque axe¹⁰ is an open source rules library for accessibility testing. While the library is available for you to integrate into your own projects and custom tools, the most common way to use axe is through one of the supported browser extensions. Once installed in Chrome, for example, you access axe through its own tab in the DevTools. Simply load up the web page you want to test and click Analyze. Figure 6-12 shows the Axe tab in the dev tools ready to analyze the page.

After running the analysis, you receive a list of issues, which can be filtered by type. There are arrows for navigating between issues (which will highlight them in the browser window) and specific information about the violation and the code that caused the issue. Clicking the “learn more” link will open a page of documentation which includes WCAG success criteria as seen in Figure 6-13.

It is also possible to integrate axe directly into your continuous integration or automated testing suite. There are a variety of integrations¹¹ including Mocha, Jest, Jasmine, Karma, Cucumber, Jenkins, PhantomJS, and Selenium allowing for automated, headless testing in most web client environments.

Lighthouse

Google Lighthouse¹² is an automated page analysis tool which includes Accessibility, in addition to Performance, Progressive Web App standards, Best practices, and SEO. As shown in Figure 6-14, Lighthouse is built into the Chrome DevTools and can be accessed from the Audits tab.

The Accessibility report in Figure 6-15 shows an accessibility score, and lists passes and failures, audits it didn’t/couldn’t perform, and suggestions for manual testing. Lighthouse is powered by axe but provides value in its convenient reporting, which can also be downloaded as JSON. When reviewing results manually, each item has a “Learn more” link which opens the same documentation page as the same link in axe.

In addition to running the report manually, Lighthouse is available as a Node.js CLI which allows it to be scripted. Note that you will still need Chrome on the system that runs the script.

While the Lighthouse report and accessibility score are extremely valuable for scoping your accessibility project and providing an indicator of success, the big limitation is that it is tied directly to Chrome. For nearly all projects it will be important to perform testing in other browsers as well to ensure accessibility is universal and not specific to one device or browser.

Pa11y

Pa11y¹³ is the name of the team, project, and set of open source tools for accessibility testing. It will be a good choice when your team is ready for Phase 3 or 4 and wants to put some work into automated accessibility testing. While Pa11y can be run successfully from the command line, it can also be integrated into a JavaScript or Node.js project for complete control over the automation. The report output can be in CSV or JSON for further processing. There is also a Dashboard¹⁴ tool which is able to provide scheduled testing and show the status visually to your entire team.

Simulators

Simulators display an altered version of a web page in a manner that attempts to simulate a specific disability. For more details, please see the section on Simulators in Chapter 3. In that section you’ll see screenshots from a WebAIM Simulation¹⁵ and a selection of simulations from Funkify.¹⁶

Another simulator option is NoCoffee,¹⁷ which is available as a free Chrome browser extension. This may be used to manually inspect the color, contrast, and layout of a web site (including in mobile view) for scenarios where it may be extremely difficult to use due to diminished vision (including situational effects such as glare from bright sunlight).

Screen Readers

Just like their name implies, Screen Readers convert text to audio by “reading” the content and structure of a web page. But they actually go a step further to making applications accessible to those who are unable to interact visually by providing sophisticated keyboard navigation for the content. Most screen readers are able to enable form completion, quickly skim the text on a page, and navigate by sections and paragraphs. Some also support additional forms of input and output such as braille and Optical Character Recognition (OCR).

The first time you use a screen reader without looking at the screen, you should begin to understand what is happening behind the scenes. All of the information that sighted users receive visually must have a structured nonvisual representation as well, so that the screen reader can provide the necessary context.

When implementing accessibility on your web sites or web applications, it is important to understand how screen readers impact usability and your testing effort. In the same way that web developers understand the need to test various combinations of device, operating system, and browser, screen readers add an extra layer of complexity. The same screen reader may exhibit one set of behaviors when run through Firefox, but in another way when run through Chrome. Simply conforming to WCAG does not guarantee a good experience with a screen reader.

Adaptive Strategies

Many operating systems, including Windows and MacOS, have some built-in accessibility features intended to make a computer easier to use. Web browsers also have accessibility features available, either through settings or extensions. However, these features usually need to be specifically enabled by the user.

Sticky Keys is a feature which reduces the need for simultaneous key presses, but turning the SHIFT, CTRL, and ALT keys into toggle keys (similar to the Caps Lock and Num Lock keys).

Often Magnification is available, to expand one section of a screen to be much larger and more readable. Page zoom is supported by most web browsers as well, and often the default text size may be adjusted to be larger or smaller.

There are High Contrast color modes to help with text readability and with overall navigation within applications.

Mouse Keys , Caret Browsing , and similar features allow the pointer to be controlled using the keyboard arrow keys instead of a mouse or trackpad.

It will be important to understand which of these features, along with the many others available, are in use by your users while they are accessing your web site. Analytics will not provide this information, so you will need to interview or survey your users directly to gather this information.

These features may interact with other assistive technology or with the style sheets or JavaScript within your application in ways that render it unusable. Manual testing with these features should definitely be part of your accessibility practice, as your team and your company become more experienced.

Password Managers

While it is commonly understood how password managers improve personal security online, they may also be used as an accessibility tool. For example, a strong password, with suitable length and entropy, may be nearly impossible for users with cognitive, neurological, or visual limitations to read and type correctly. And as password length recommendations increase year after year, passwords become harder to remember. Add in the fact that every site has slightly different rules for what passwords are permitted, and the recommendation to use a unique password for every site, and quickly password managers become the only real option for most users to keep their credentials straight.

This means your web site or web application should avoid interfering with password managers. You should also test all forms in your application, including login, to be sure the the password manager works as intended. Some popular password managers as of this writing include LastPass,¹⁸ 1Password,¹⁹ and KeePass.²⁰