May I ask for a review of this PR? 🙏🏼

Thanks for the feedback @Falke-Design.

For me personally: The links are very "hard to read" and I don't think that a new plugin contributer will read through it.

Those documents are authoritative and are often referred to in the accessibility dev world, but they may take some time getting used to. I don't expect developers to read it all, but more so for them to know that they're there, and that they mean something. And they can choose to use them (and learn how to use them) if they wish. Perhaps they should be replaced with- or accompanied by e.g.:

• https://developer.mozilla.org/en-US/docs/Learn/Accessibility
• https://github.com/mfairchild365/a11y-resources
• https://developers.google.com/web/fundamentals/accessibility/how-to-review

That second resource even covers what we're discussing here 😋:

Standards can be complex and hard to read, and therefore are often only referenced as a last resort. I'd argue that they should be consulted first. They are the most authorative source of how things should work.

(https://github.com/mfairchild365/a11y-resources#standards)

It would be good if there would be a list of common mistakes (specially for Leaflet)

I did consider that, but how many would be enough, or too few? Generally the issues in Leaflet and plugins are issues that are common to all web sites. I.e. issues with: focus delegation, focus visibility, missing accessible names (and then I suppose I'd have to explain what an accessible name is and that it may be derived from: text from element/aria-label/title, which those resources would otherwise explain), etc. But these things are generally covered by the testing tools (which I do expect developers to use) or easily discovered during manual testing with a keyboard, and a screen reader (thus I recommended manual testing, and added a list of tools).

Apart from this PR, would you have the time to create PRs for each accessibility issue? If not it would be very helpful if you can write into the issues what should be changed (from this into this), then we create PRs

I believe each issue should have a proposed solution already. I will try to find time to look over the issues tomorrow to clarify them, perhaps by using headings, such as "Motivation" and "Solution". 👍

[...] to know that they're there, and that they mean something. And they can choose to use them (and learn how to use them) if they wish

Good point 👍

how many would be enough, or too few? [...] are common to all web sites

Yes I understand. I looked into your links and they have so much informations, that I closed the sites fast again 😉 But you are right there are enough tools out there. And you added already a good list to start.

to look over the issues tomorrow to clarify them

Thanks. I think you have the most experience so it would be good to have clear suggestions and then we can change this in Leaflet 👍

I think this is a good addition as is, it could be tweaked later if necessary.