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:

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.

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).

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.

Verification tools

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!

If you'd like to write a test against a WCAG 2.0 technique, start an issue in the QUAIL issue queue and link to the technique. Every technique's details page has a Test header that describes how to structure a test and the success criteria for the test.

This mapping would be really great as we can give users additional information. It would be better to add the technique-id in the json file as a id. It would then possible to create automatic links, overviews and statistics.

So, I'm envisioning a set of UIs for the Accessibility module that pivot around the specifications. Maybe a wall of checkboxes for each item of the guideline that has a test, with config options for a test if appropriate. The form could have a couple pre-baked combos like WCAG A compliance and AA compliance. Or "content creation" tests or "site navigation" tests. Maybe the QUAIL library could expose these configurations to the Accessibility module rather than the module knowing about how to construct these combos. It would make QUAIL more useful to non-Drupal implementations.

The thought of making the module use the quail.js as it's source of information resonates very much with me! +1 to that concept - I know that it'll put focus on quail.js as the canonical reference and I see that being a big selling point for getting more people from more techno-communities (node.js, ruby, php) involved in supporting it.