Multiple headlines with same text on a page receive the same id, which leads to dublicated ids a11y violation

[jackahl]

Describe the bug
When multiple blocks such as text or listing on a page contain the same text they receive the same html id. This is both a a11y violation as well as a usability problem for anchor links.

To Reproduce

1. Edit a page
2. Add 2 text blocks with text "My headline" and set them to h2 format
3. Save and check the ids of those items --> both have the id "my-list"
4. run the axe a11y tests on this page --> Test will fail with duplicate-id-active issue

Expected behavior
All headlines should have unique ids independent of their text content

Screenshots

[jackahl]

related: https://github.com/kitconcept/kitconcept.intranet/issues/199

[jackahl]

@tisto I had a discussion about the issue with @polyester @gforcada. We agreed that a technical solution to this problem is most likely not feasible. The 2 main ways we could (theoretically) solve this in theory are:

• A: somehow add a random string to the id to make it unique. For actual accessibility (not just technical compliance) this makes things actually worse for people relying on screenreaders, as they will get those random ids read out to them.
• B: build some sort of mechanism that warns editors about duplicate ids in the UI (maybe on save?). The problem here is that this has a high degree of technical complexity for debatable actual use. Technical depth here stems from the fact that all sorts of blocks, be it from core, addons, projects, etc. have headlines with ids (e.g. Slate, Grid, Listing, Maps, etc.). Blocks from third party addons could also use ids generated from user input, that is impossible to be taken into account.

@polyester also argued that it is not realistic anyways to solve problems created by editors through the technical means in the CMS. E.g. Editors could also mix up the orders of headings, which we do not check. His suggestion was to rather recommend AXE browser tools to editors who have a desire to create fully accessible content.

I personally think that we should not spend too much resources on fixing problems that are actually only there to satisfy automated tests in CI, but affect actual users very little.

[jackahl]

On that note, I was thinking that a a11y checker volto-addon, that lets editors check their pages easily from the Plone UI, might actually something interesting. Maybe idea for a GSOC?