Refs #4770 - Accessibility acceptance tests for blocks

[tedw87]

Update and fix #4781

[netlify]

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	3e37073
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/6745a4cd1b5cbe000849fed2

[ichim-david]

@tedw87 be specific when tests are done and they pass within the changelog of what blocks you've added a11y tests for
if you are done with adding the tests.

[ichim-david]

@plone/volto-accessibility @plone/volto-team I am ok with this work as it's an addition to what we already had.
I have some questions regarding the placement of these tests, if we shouldn't change a bit the organization of these tests.
For instance for Volto "content types" I've asked Ana to place the tests within a11y.js from the content folder in this pull request https://github.com/plone/volto/pull/6339/files.
Similarly to me, it would make more sense to have the block a11y testing within this folder https://github.com/plone/volto/tree/main/packages/volto/cypress/tests/core/blocks (blocks-a11y.js).

I would keep the basic a11y.js for the routes and content views such as the contact-form, frontpage, and whatever else we want to test.

Should we be so neat in the test organisation or do you prefer a single long file? Personally, I am in favor of splitting each concern making it also easier to navigate but I need to know also the opinion of our community.

[pnicolli]

I had not thought about it but now that you mention it, I like the idea of separating concerns and splitting files.

[JeffersonBledsoe]

Agreed on splitting things out to make it easier to debug test failures and review component behaviour, as long term I would like to see more a11y tests that aren't just "Run axe and assume it's accessible if it passes".

I would keep the basic a11y.js for the routes and content views such as the contact-form, frontpage, and whatever else we want to test.

Lets rename a11y.js to something a little clearer to avoid this file being bloated in the future? "Automated route accessibility" or something?

[sneridagh]

@ichim-david @JeffersonBledsoe @pnicolli in all our projects, we have a specific folder for that, then inside a file per component/view/block etc, using common sense. More than one level nesting is not needed, I guess.

@tedw87 maybe you can start with that one in here? We could even split the actual GHA tests to just test the A11y separately. I can take care of that in another PR.