Special Projects Accessibility CLI Tool

What is the Special Projects accessibility (A11y) CLI tool?

The Special Projects Accessibility CLI is a tool developed by the Special Projects Team to evaluate potential accessibility (a11y) issues that a website may have. The tool optionally outputs results to ███████████████ and/or creates GitHub Issues for tracking and addressing the issues it finds.
The tool was built as part of our larger Standardizing the Standards ███████████████ effort and uses the axe-core library by Deque labs.

Where do you find the tool?

Install the CLI tool using the instructions on the repo’s README.

If you run into any issues installing or using the tool, you can troubleshoot by reaching out to the Special Projects Engineering team in Slack, or you can open an issue in the tool’s repo.

How do you use the A11y CLI tool?

The tool can be accessed with the command t51a11y

t51a11y http://wordpress.com --save

When using --save the results are posted on ███████████████. Don’t know exactly which options you want? Just run t51a11y and the tool will ask you a series of questions and set the options for you.

Available commands

The tool has the following commands:

t51a11y to trigger wizard mode
t51a11y [url] to view results in Terminal
t51a11y [url] --save to post results in P2
t51a11y [url] --inapplicable to also include in the report results from inapplicable tests
t51a11y [url] --passed to include in the report accessibility tests that passed

Inapplicable tests are scenarios where an A11Y rule couldn’t be tested. For instance, if no <video> or <audio> tag is present on the page, the tool cannot check whether or not this site is using captions.

When do you use the A11y CLI Tool?

For new projects, the tool should be used in two possible ways:

To audit a potential partner site that is already using WordPress
At or immediately after the QA portion of site development

Addressing issues

Launch Items

Find the item in our Launch Checklists for “Run the site through the A11y CLI Tool” under the “Development QA” checklist
- Either a TAM or the Contractor developing the site can run the tool in order to generate results
Post the results to an issue in the A11y CLI Tool Github repo using the CLI tool’s wizard mode
Visit the A11y CLI Tool Repo and copy the issue link into a new issue within your development site repo
Once we’ve tested the changes on develop and have pushed our work to trunk, we’ll want to run this tool again and confirm all issues are resolved

Maintenance

If we are running this tool after a site is launched or as a regular maintenance check, we’ll want to move the action items in to a GitHub Issue for a developer to address.
- Either a TAM or Contractor can run the tool in order to generate results.
- Post the results to an issue in the A11y CLI Tool Github repo using the CLI tool’s wizard mode.
- Visit the A11y CLI Tool Repo and copy the issue link into a new issue in the site’s Repo to address all the issues. Be sure to include how or why we need to fix the issue.
- Create a Dev Request via Slack so that our engineering team can assign a developer.
- We still want to follow the same ███████████████ in using Feature branches as we do with any other update to a site.
- Once we’ve tested the changes on develop and have pushed our work to trunk, we’ll want to run this tool again and confirm all issues are resolved.