Opened 5 weeks ago
Last modified 3 weeks ago
#8427 new enhancement
Proposal to update `accessibility-ready` tag moderation in the theme directory
| Reported by: | joedolson | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Theme Directory | Keywords: | needs-patch |
| Cc: |
Description
During the WordCamp US 2026 contributor day, @alh0319, @joedolson, @otto42, and @nullbyte discussed an updated mechanism for moderating the accessibility-ready tag in the theme directory. The current system has always been flawed, because tags are fully under the control of the theme author, which greatly limited the ability to control the usage of tags that required additional testing steps to verify. The only specific example of this is the accessibility-ready tag, and the consequence has been that our only enforcement tool has been to delist a theme from the directory.
The proposal is to make display with the accessibility-ready tag have a dependency on also carrying a second tag, tentatively to be called accessibility-approved. A tag with the accessibility-ready tag alone will not show as having any accessibility status - that tag stands as a request for review from the theme author.
Once approved, a member of the accessibility team can manually add the accessibility-approved tag to the theme record, and it will show up in lists. If the theme ships an update that later compromises accessibility, the tag can be removed..
This creates numerous benefits for the team:
We no longer have to penalize themes for failing to meet voluntary standards by de-listing their themes from the directory.
If an accessible theme regresses in accessibility, we can remove it from the lists immediately
If a theme is accessible, but has not added the accessibility-ready tag, it can be added to the list even without an update.
This gives the accessibility team control over which themes are promoted as accessible without imposing any penalties on theme authors for non-compliance.
It also prevents themes from being listed either because they added the tag by accident (common in themes cloned from accessible base themes or child themes), or from being listed as accessible prior to getting a review, since the review process frequently requires additional accessibility fixes.
The development of this change would be driven by @otto42, who has agreed that this is one of the simplest paths to achieving the controls we want to implement. This would modify the impact of the accessibility-ready rule changes previously announced, as themes would merely be removed from the tag listings rather than being delisted.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)