Accessibility Conformance Report (ACR) Process

Introduction

You’ve probably landed here because there is a contract that you want to win that requires an accessibility compliance report or VPAT. The following document will help you understand: if you need an ACR; how the Drupal community is managing this, and how it can benefit your project. 

Generally, the steps include:

1. A bid or tender has asked you for an ACR or VPAT. Some projects may choose to be proactive because they anticipate a client requiring it. 
2. In cooperation with potential vendors, determine what to evaluate. (Is it just the website, or a combination of hardware, software and digital documents?) Also keep in mind that the client may ask for a specific ACR format.
3. OpenACR should be sufficient to create a report that follows either the VPAT 2.4 Section 508 or WCAG format. The EU & INT formats are really only relevant if hardware, software and digital documents are being evaluated. 
4. The ACRs all have a section of success criteria which need to be evaluated. For the web, these align with WCAG. You will need to assess relevant user interfaces to determine if there are accessibility barriers. 
5. It is important to provide comments explaining if Success Criteria agree either “Supports” or “Partially Supports”. If there is an open issue queue, it is useful to link each of these comments to known issues. If there is a timeline to address these barriers, this should also be noted.

Do You Need An ACR?

For reviewing websites, the Drupal community recommends using the W3C’s WCAG Evaluation Methodology and the WCAG-EM toolkit. These tools provide guidelines for reviewing websites as part of a regular reporting process. Organizations should consider implementing a review, with both automated and manual tests, on an annual basis.

Many organizations, especially those in the USA, require an Accessibility Conformance Report (ACR) as part of the procurement process. The most popular ACR is the Voluntary Product Accessibility Template (VPAT®). There are multiple versions of VPAT which depend on what is being bought/sold. For web projects, the most commonly used MS Word VPAT templates are for Rev WCAG and Rev 508.  VPAT 2.4 Rev WCAG is currently aligned to WCAG 2.1. Some contracts may ask for VPAT 2.4 Rev 508, which aligns with the older Revised Section 508 standards. WCAG 2.1 had not been released when Section 508 was revised, so it still reflects WCAG 2.0 AA requirements, which were published in 2008.

We use the US Government’s OpenACR tool, to help provide an accessible, machine-readable ACR. This open source tool was built by CivicActions, and built to meet either WCAG 2.0 AA or WCAG 2.1 AA reporting requirements. The OpenACR tool helps guide users through the process of creating a meaningful ACR.  The HTML report produced by the OpenACR tool can be submitted as a VPAT, because it follows the same format.

Drupal Core

As with most software projects, our single-source-of-truth is our issue queue. This in turn is based on our git repository. Drupal’s issue queue has the complete record of accessibility barriers which have been reported. These are visible to everyone.

To help manage our future reporting, the Drupal Accessibility Team is encouraging folks to tag specific issues along with their WCAG Success Criteria.  So WCAG 2.1’s 1.3.1 issues can be found with “wcag131” and WCAG 2.1’s 1.4.11 issues can be found with “wcag1411”. This should allow us to easily collect new issues and identify which issues have been resolved.

We should also be tagging those elements which are specific to the authoring/administrative views and not specific to what a non-authenticated user would be likely to see. We are striving to meet ATAG 2.0, and for ACR reporting, it is necessary to separate authoring issues. Issues that are clearly tied to patterns that are intended to be for authors/administrators should be tagged with “atag”.  As an example, any issues tied to administrative themes like Claro would be tagged with “atag” even though they could be used for any theme.

In creating the OpenACR, it is important to also include the issue’s node ID. This way, people viewing the ACR will be able to quickly identify the known accessibility issues in Drupal, and contribute to resolving them.

The ACR of known accessibility issues should be included with every release of Drupal, with both the YAML and HTML files.

Drupal involves a number of open source projects, for instance Symfony and CKEditor. It is also used to power over a million sites. Some of these sites are products which may require an ACR, such as Opigno LMS or Open Social. OpenACR documents can have parent/child relationships, so it is possible to highlight specific projects in the Drupal ecosystem.

Projects on Drupal.org should be building towards the new Accessibility Coding Standards. The Drupal Core team has worked hard to see that the defaults we provide are accessible, so it is generally safe to stick to those. We have also provided guidance on how to do an accessibility review, which may be useful

Drupal’s OpenACR is released under CC BY-SA 2.0 license, as with other documentation in Drupal. Please respect that if it is reused or modified.

See details about execution in https://www.drupal.org/project/drupal/issues/3335955

Drupal.org Projects

If you want to build an ACR for a Drupal-related project, then you can include Drupal Core in your ACR. You should have an issue queue that has tagged any accessibility issues. Most Drupal themes and modules have not done extensive accessibility testing; however, there are notable exceptions, such as the Webform module.

In the Drupal community, accessibility issues are understood to be bugs. If you do not have accessibility expertise on your project, you can reach out on the #accessibility channel on the Drupal Slack. It is important that ACRs are completed after a thorough review of the user interface. If you do not have experience in the project to do this, there are multiple vendors that can provide an ACR.

Please include a copy of your OpenACR in the root directory of your project and reference it in your README. Your repository should include both the YAML and HTML files.

Please consult the Accessibility Coding Standards and guidance on how to do an accessibility review, which may be useful.

Modules & Themes on Drupal.org can release their OpenACR under CC BY-SA 2.0 license, as well. Please respect that if it is reused or modified.

Other Projects

If you are required to submit an ACR for your project, which uses Drupal, but is not otherwise tied to Drupal.org, much of this advice still holds. If you do find issues upstream in either Drupal Core or related themes/modules, please contribute to the issue queue on Drupal.org. Having a factual ACR is good, but getting the bugs fixed for everyone is always better. 

The ACRs for projects which leverage Drupal but are not hosted on Drupal.org, can be done in any way that satisfies the project maintainers. Making sure to link to related ACRs is something that can lighten the load of an ACR implementation. 

Good ACRs are usually done by 3rd party teams that are able to look at the UI objectively. Usually this doesn’t address all interfaces in a site, but should include the paths involved in a user’s top tasks.

Note: These are primarily useful in the United States, because often they have been seen as simply a sales document. ACR’s are supposed to be an attestation by the company of their efforts to build accessible interfaces. This is part of the US Government’s Section 508 process, and it was supposed to encourage innovation by incentivizing investment in accessibility. Sadly, this has often become a box-ticking exercise, rather than something to actually encourage digital accessibility.