Green by 2014: Let's get to zero automated accessibility test failures in the Accessibility module

Executive summary

We want an accessibility testing green board for Drupal. Currently, the testing platform and tests are under development and progress is solid, thanks in major part to Kevin Miller (kevee). The tests register 257 failures currently, although some might be false positives and duplicates. We need developers, testers and reviewers to get us to robust test coverage and zero failed tests against Drupal 8 by 2014.

We’re calling this effort Green by 2014.

Please tag all issues with accessibility and Green by 2014.

Current efforts to improve accessibility in Drupal 8

The Drupal 8 development cycle has included concerted effort to improve the accessibility of administration features and content. But we’re not satisfied by uneven improvements. We want Drupal 8 to be the most accessible content management system in the world.

The accessibility module describes itself as “a common framework for checking accessibility of a webpage". It provides facilities to check content and code against standard accessibility guidelines.

This module and its tests are still under active development. We need developers to assist us in bringing these efforts to conclusion within the Drupal 8 development timeframe so that we can declare with conviction and evidence that Drupal 8 meets Section 508 and WCAG AA standards.

Update the Accessibility module code to be compatible with the latest D8 HEAD APIs

Drupal 8 HEAD, although largely stable, still undergoes occasional pattern and API changes. Given this reality, we need to spend time updating the Accessibility module’s 8.x branch to keep up with these changes. Our effort to get to a automated testing green board must start with updating the Accessibility module so that testers can run it locally.

We need individuals who are familiar with Drupal 8 module development in order to advance development of the accessibility module. These folks will:

1. Create issues in the the Accessibility module issue queue.
2. If you can, propose patches to resolve them.
3. Patch reviewers. Please follow issues that you can contribute to!
4. Please tag your issues with Green by 2014.

Making Drupal more accessible

The Accessibility module helps us identify where Drupal’s access support falls below that of Section 508 and WCAG standards.

This testing tool runs many tens of tests across numerous pages of a Drupal installation. You can either run the tool locally through the Accessibility module or view the daily run at Drupal Accessibility Status (beta).

The tool is not perfect yet, though. Some tests return false positives, meaning that an identified issue is not really an issue. In this case, we need to adjust the test to remove the false positive. For legitimate test failures, we must log an issue against Drupal core and propose a patch to fix the issue.

Logging accessibility issues against Drupal core

In cases of an actual accessibility issue, we must first create an issue to describe it and then address that issue with a patch. The Accessibility module reports issues in a table layout. The test name, theme hook, theme item (function or template) and and output markup are provided. I’ve given one example here in a list format.

• Test: Text has appropriate contrast
• Theme hook: page
• Theme item: core/themes/bartik/templates/page.html.twig
• Element:

mgifford gives us a great example of a focused issue that arose from the automated tests and anandps provides a patch to review.

drupala11y.org finds two new color contrast issues.

In this issue, mgifford gives us a reference to the failed test, the specific code that’s failing and a possible path for a solution.

Text has appropriate contrast
page: core/themes/bartik/templates/page.html.twig

<div class=\section clearfix\></div>
<div id=\name-and-slogan\></div>

Does have color contrast problems according to this new Chrome Color Contrast plugin.

In your issues, you are not expected to provide a solution. Simply logging the issues gives us a great start to addressing it.

Drupal already has great issue documenting guidelines in how to create a good issue report. Please follow those guidelines when creating a report.

Please tag your issues with accessibility and Green by 2014.

False positives

The automated testing tool might report an error that occurs becuase of a poorly written test, not because we have an issue with Drupal core code. This is a false positive failure. Most likely the parameters of the test need to be adjusted. You should always first consider, when addressing a test failure, if the test might be at fault if you find in your investigation that the Drupal output passes your manual testing.

False positives must be fixed in the QUAIL project directly on Github. To address them, take the following steps (as far as you are able).

1. Create an issue in the QUAIL project issue queue.
2. Tag the issue false positive and Green by 2014.
3. If you can, propose a patch to resolve it.

Documenting our coverage

It’s well and good to have great test coverage, but we need to communicate that coverage to the outside world. Specifically if we are to make claims of conformance, we must be very sure that our tests convey conformance.

That requires us to correlate our existing tests to sections of the specification and explain how the test satisfies that section. The current state of correlations is documented in the Test guideline alignment.

Send a pull request to update any of the documentation in the QUAIL github repo.

Verification tools

You might try the following browser tools, among numerous others, when verifying accessibility tests.

Wave plugin for Firefox
Color Checker for Firefox
Chrome color contrast tool

Please help out!

We intend to make Drupal 8 the most accessible content authoring and management tool ever. And we intend to make that claim verifiable in part through robust and wide automated testing coverage. We need your skills, dedication and compassion to make it a reality!