Add an Accessibility Conformance Report (ACR) to Core

Adding SC

Adding WCAG 2.1 listings.

Also worth noting that I published this:
https://www.drupal.org/docs/getting-started/accessibility/accessibility-... →

I have a sample of this for D10 here:
https://github.com/CivicActions/openacr/blob/main/openacr/drupal-10-15.yaml
https://htmlpreview.github.io/?https://github.com/CivicActions/openacr/b...
https://htmlpreview.github.io/?https://github.com/CivicActions/openacr/b...

What I don't know is if it makes sense to provide a .zip of these or even just provide the .yaml file. I'm also not through the issue queue yet, marking issues for WCAG SC.

Would love people's opinions of bundling this in with Drupal Core and keeping it up-to-date.

Where would these files be located in the project directory structure? Is the idea that this would be public like the output of a robots.txt or humans.txt file or would they exist at the same level as the composer.json? I can see a lot of advantages to being able to leverage these internally, but I'm guessing large orgs aren't going to want to publicly declare their accessibility shortcomings.

Thanks @kreynen I was thinking that these would be best with the other text files in /core

Could be in a single zip'd file or just:
/core/drupal-accessibilty-10-15.yaml
/core/drupal-accessibilty-10-15.html

There isn't any precedent for putting this in a robots.txt or humans.txt file. Not sure if it would be something folks would find there.

I like the idea of a humans.txt simply pointing to /core/MAINTAINERS.txt

This isn't about a large organization declaring their accessibility barriers, but rather Drupal Core. All of them could be fixed in the organizations implementation.

There isn't any precedent for putting this in a robots.txt or humans.txt file.

Sorry. I didn't mean to put the information from the ACR in those files. I was just using those files as an example because they are public. Anyone can access https://www.drupal.org/robots.txt → and https://www.drupal.org/MAINTAINERS.txt → . While many organizations harden their codebase by removing those files or block access with a WAF rule or something like that, the information in the ACR is more akin to keeping a file called /KNOWNSECURITYISSUES.txt. I know that sites are already fingerprinted and probed for known vulnerabilities, but I'm worried organizations aren't going to be keen on publicly sharing the known accessibility issues in their codebase.

To be clear, I'm all in on the direction you are going with this and machine-readable accessibility reporting in general. I'm just concerned about the reaction even organizations leaning into accessibility (like every entity doing business with the state of CO impacted by HB21-1110 next year) will have if the ACRs are publicly accessible by default.

I'm also jumping ahead and thinking about tooling that could provide an aggregate of ACRs in a project if these were included in both core and contrib similar to how we can now report on all the licensing and known security issues in the PHP dependencies of a project. We have the same issue there that if a contrib maintainer chose to include an ACR in their module, it could have real legal consequences or generate nuisance filings.

Ah yes. Like why folks don't always put a VPAT up publicly, but request that procurement teams ask for it. That's a messy system. Hopefully one that can be avoided. It's incredibly wasteful and really stops accessibility issues from being a priority.

Ultimately, if we publish it on Drupal.org or inside the /core folder it won't really much matter for the ambulance chasers in the USA who are looking for someone new to sue. And totally fine for clients to either delete or block the .txt files if they think it is a concern. I've always seen folks who do that as being bigger targets. After all, if you are transparent about good security hygiene, if I was a hacker I'd go somewhere else. I think it's far more likely that folks who hide the CHANGELOG.txt are a few releases behind than those who proudly will show they are using the latest version of the code. Now I suppose, someone could just scrape that with every release and only change the CHANGELOG.txt file, but that seems unlikely.

I do totally like where you are going with the nested ACRs. Not sure if you'd seen

https://gsa.github.io/openacr-editor/about

We totally want to be pointing to CKEditor 5's OpenACR (when they produce one) and for that mater to be included in the Webform OpenACR (when it becomes a priority). A service that is built with Drupal might just want to include Drupal as a linked ACR so that they could properly attribute which upstream errors our community is responsible for.

I wasn't familiar with https://oit.colorado.gov/accessibility-law - that is pretty cool. Way to go Colorado!

So these are the two files I'm thinking should be added:

https://civicactions.github.io/openacr/drupal-10-16.html
https://civicactions.github.io/openacr/drupal-10-16.yaml

Can you clarify how you'd see the ACR files being maintained in different releases? According to https://git.drupalcode.org/project/drupal/-/blob/34162e77f14553bebba1dd8... and https://git.drupalcode.org/project/drupal/-/blob/bc2fa363c69549326c69170..., the version reviewed is drupal-10-16... which I'm assuming translates to 10.0.16, but it could also mean 10.16.0.

I think the file names and versions in the ACR need to reflect semantic versions. drupal-10-0-16.html would allow for drupal-10.1.16.html. Not sure how you'd support that otherwise.

Regardless of the version of D10 reviewed, MR is for 11.x-dev.

I'm assuming that you wouldn't just role the version forward with each as part of the release process like https://git.drupalcode.org/project/drupal/-/commit/1c5335de2322b7c232d9a... as the ACR is the version that was reviewed, but including a review of 10.0.16 in the 11.x-dev branch seems odd too as the major version number change indicates major changes in the versions of the code previously reviewed.

Wouldn't it make more sense to target the 10.1.x-dev branch?

Does it make sense to include any 10.x.x review in the 11.x-dev branch? Would it make more sense to remove it at the start of each major version release and add it as part of the beta process?

mgifford → closed merge request !4413

My bad - kreynen thanks for pointing that out. I had intended to do drupal-10-0-16.html & drupal-10-0-16.yaml

But frankly, since this is in Drupal core it probably would make more sense as openacr-drupal-10-0-16.html & openacr-drupal-10-0-16.yaml

I've got to update the ACR though. Moving it to D10 is preferred. I wasn't sure if it would be too late to include this in D10. Shouldn't be, but I wasn't sure.

Ideally we'd put out updated ACRs with every release. That might be more than we can maintain. They should align with the best practices known at the time of the release though. It might be better to just keep it as openacr-drupal-10-0.html & openacr-drupal-10-0.yaml committing to only do an update at that interval, and not for every security release. Updates and changes which get into core, could always be included in the file. All of the changes would be managed via version control.

Certainly, I'd only want to see one .yaml & .html file per Drupal release, not the whole history.

I've pulled the issues from the issue queue, so some of the issues are going to really be D11 issues, rather than D10. If we know about a bug, but can't fix it in D10, it is often pushed ahead to D11. It is most of the time still a concern for D10.

I think the main reason that there would be differences between the D10 & D11 branches is that functionality with accessibility barriers have been removed from Core, or we are embracing a different level of accessibility or different browsers. For instance, in D10 we no longer have to support IE (thank goodness).

These are good questions and I look forward to hearing where folks should go (and then rolling a new patch).

Because this is only adding static files, you might still be able to get it into 10.1.x. That said, my guess is the blockers will be related to the process of managing what is in these files.

What I'd recommend is to maintain a patch that organizations interested in accessibility can add their current D10 build process with something like...

"extra": {
    "patches": {
      "drupal/core": {
        "Add Drupal core ACR files": "https://www.drupal.org/files/issues/add_acr-3335955-19.patch"
      }
    }
  }

Focus on the process of maintaining the ACR as if it was already in core through the D10 releases and then shift to getting the files into D11 as that gets closer to a release.

Right now it's just you and I having this conversation and I'm already sold on the advantages of including ACR files in core and contrib. Having a patch that is easily added to a build will make it easier to socialize this.