Automated tools have advanced a lot over the last few years, and we should be able to add accessibility testing either within our CI/CD process. At the very least, we should be able to evaluate a daily snapshot, which would allow us to test various components of Core with an automated tool. Automated testing will never catch 100% of WCAG 2.1 issues, but it will catch the easiest to catch barriers.
What most developers have focused on recently is Deque's axe core. This is both open source, and built to avoid false positives. Deque's rule-set and accompanying resource library helps developers understand and resolve issues when they arise. A Deque study suggests that up to 57% of accessibility issues can be identified through axe, which is much higher than previous estimates.
Axe is incorporated into the base of many tools like Google Lighthouse, Accessibility Insights, Pa11y and many others. There is even a Drupal module ( Accessibility Scanner → ) that uses axe to scan the site.
This is in some ways getting back to this Green by 2014 initiative, to build in more automated testings, including an accessibility Test Swarm → . Much of this was discussed at DrupalCon Portland in 2014.
Maintaining Drupal's accessibility will be easier if we are able to easily and regularly evaluate key functionality.
We need to be able to define the key functionality that we would want to test, would likely need to use a module like Realistic Dummy Content → , to ensure that there is more there than just Core, but might also want to use Umami → .
It would then be possible to either crawl the dummy site, or hit a set number of URLs. The advantage with the latter is that it would be easier to control, and thus understand if there is an increase or decrease over time. Perfection is not the goal, the goal is to be more inclusive today than you were yesterday.
The CivicActions Drupal team discussed this briefly earlier in the week. Would be terrific to be able to build on some of the existing initiatives within the Drupal community.
Nightwatch → is already built in, and so it would be trivial to add in nightwatch-axe-core to make accessibility testing easier. Some folks use Cypress & Cypress-axe, but best to build on what we have.
If we are moving to GitLab CI/CD, then there is support for pa11y already. We'd need to make sure that axe-core is included. Always great when others have paved the way. We should be able to publish Accessibility Reports with GitLab as well.
The Pa11y Dashboard might be the easiest way to provide a historical view.
This isn't intended to be a complete list. This could all be done with Pa11y & axe-core.
We would likely need to use start writing Nightwatch-axe-core tests to evaluate the interactive functionality.
---
We should keep things like https://github.com/tenon-io/tenon-drupal and https://github.com/Asqatasun/Asqatasun on our radar as a potential way to add accessibility checking in an automated fashion.
Earlier efforts to build a JavaScript test swarm: https://groups.drupal.org/node/366873
Active
Policy
It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
It would be great to get a list of the URLs that are presently being covered by axe. There are some issues sneaking into Core that should have been caught by automated testing.
As with any good CI/CD process, it is important to monitor that list of URLs on a regular basis to ensure that we are using the best sampling that we can.
Phase 1 & 2 in the description identified some key URLs. It is unclear (without digging into the code) which URLs are being tested.