Making WordPress.org

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.

Change History (3)

This ticket was mentioned in ​Slack in #accessibility by joedolson. ​View the logs.


5 weeks ago

This ticket was mentioned in ​Slack in #accessibility by joedolson. ​View the logs.


5 weeks ago

This ticket was mentioned in ​Slack in #accessibility by joedolson. ​View the logs.


3 weeks ago

Note: See TracTickets for help on using tickets.