Skip to content

[Tracking issue] Enhance accessibility-ready guidelines with classic vs. block theme information and examples how to achieve the guidelines #332

Open
0 of 15 issues completed

Description

@luminuu

URL
Page URL: https://wpaccessibility.org/docs/accessibility-ready/ and all subpages

Title
Guidelines for the WordPress accessibility-ready tag, and all subpages

What Needs Editing?
While working through the new accessibility-ready theme guidelines I noticed that the guidelines explain the what and why, but not how to implement any of the requirements. While I understand that the guidelines have been written with the testing process in mind, I think it would be helpful to add technical details on how to implement the requirements for both the tester and the theme developer who might have to fix these things.

For example regarding examples, the Skip to content links are a good example. While in classic themes you need to manually add them to the templates, for block themes it is as simple as adding a group around the Content block and setting the group to use the <main> element and WordPress itself will generate a skip link as a main element is found.

Under the Meaningful landmark roles and names section, from a developer perspective it is not clear what to actually do in block themes, especially as additional attributes cannot be added to the elements. My understanding is that it's sufficient enough to use the appropriate HTML tags like header, footer, main etc. but the guidelines do not clarify that.

Another example would be that some things are not applying to block themes anymore as things are handled by Core, labelled form fields could be one if a theme does not add any additional form elements, or the navigation-widgets mentioned under Meaningful landmark roles and names.

In the theme testing workshop held by Equalize Digital on May 21st, an attendee raised an issue with a theme she was testing, as she tried to assign the menu locations but couldn't, as the theme she tested was a block theme and not a classic theme. Block themes work differently than classic themes, so there should be different testing instructions, especially for those who are new to the testing process.

With this ticket I want to start the discussion about how we can implement these information alongside the requirements. Pinging @joedolson to connect the dots for the questions I asked in Slack and in the workshop :)

Activity

  1. rianrietveld commented on May 22, 2026

    @rianrietveld
    Member

    Hey @luminuu, great points!

    In addition I want to point to issue #326, we want to add links to the a11y docs with the requirements.

    We can also add links to the WordPress documentation, for example on how to handles menus in the customizer.

    For this we needed a new design, so the reader doens't drown in links, (#331) this is almost finished.

  2. rianrietveld commented on May 22, 2026

    @rianrietveld
    Member

    Addtional:
    This is a great starting point to adjust and expand the documentation in the standards and best practice section to be less generic and more WordPress focussed.

    I would love to discuss this at the contributor day at WordCamp Europe.

  3. changed the title [-]Enhance accessibility-ready guidelines with classic vs. block theme information and examples how to achieve the guidelines[/-] [+][Tracking issue] Enhance accessibility-ready guidelines with classic vs. block theme information and examples how to achieve the guidelines[/+] on Jun 6, 2026
  4. rianrietveld commented on Jun 22, 2026

    @rianrietveld
    Member

    Hey @luminuu
    How shall we proceed from here?
    Shall I create sub issues per topic, and the you can work from there?

  5. rianrietveld commented on Jul 8, 2026

    @rianrietveld
    Member

    Hey @luminuu
    I've created sub-issues, each sub issue is an accessibility-guideline. I skipped issues for Accessibility statement, Must not recommend inaccessible plugins and screen reader support, as they are straight forward,I guess.

    With each sub-issue also added links to related pages from the "Standards and best practice" and "Test for accessibility" sections, so you know what is already there.

    If you want to place content not with the guideline but within the standards section, please do. I want to avoid duplicated content, but on the other hand also avoid that people have to often switch pages to get to the content they need. Up to you to find a balans :-)
    If you want to discuss approaches, DM me or Joe Dolson, or ping us in the accessibility-docs channel.

    People to ask for a review:
    @rianrietveld
    @joedolson
    @samikeijonen
    @amberhinds

    Thank you so much 🌷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions