#7980 closed defect (bug) (invalid)
Add accessibility ready plugin business model
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | |
Cc: |
Description
Background
WordPress themes are already marked with an accessibility ready tag. This makes it easier to find themes that meet the minimum requirements defined by the Theme Review Team. This gives WordPress users the chance to select a theme for their project that is already fundamentally accessibility ready. See: https://make.wordpress.org/accessibility/handbook/which-themes-can-you-use/
My following suggestion arose from numerous presentations on accessibility at WordCamp Leipzig 2025 yesterday. The videos of the presentations held in German should be available on wordpress.tv shortly. In one of the presentations, it was noted that themes are already very advanced, but plugins often pose a problem for accessibility. I am taking this up for my proposal here.
For plugins, an accessibilitytag is already used by many plugins, which is a great way to find them. However, this tag is not subject to any checks (unlike themes). It is also not immediately recognizable as a possible filter (unlike themes).
Proposed Changes
In addition to marking plugins as "Community" and "Commercial", I also suggest marking them as "Acceesibility Ready". This would give you a 4th tab at the top right of https://wordpress.org/plugins/ and the plugins that already do this would not only be easy to find, but acceesibility would also become more important for plugin developers.
In order for plugins to be found here, they would have to send a request to plugins@… (as with the marking for commercial). However, the Plugin Review Team would then (unlike with "Commercial") have to check the plugin according to criteria yet to be defined and provide feedback. This can either include information on necessary improvements or confirmation that the plugin has been marked. In the latter case, the plugin could then be found under the new filter.
Prerequisites
The criteria to be used for the check as well as the check methods could be adapted by the theme team if necessary. This saves the effort of reinventing the wheel.
Change History (3)
#2
@
2 months ago
Without a specific strategy and personnel availability to perform the accessibility testing, this isn't a practical goal. The Plugin Review team is not specialized in accessibility, and the accessibility team doesn't have the time available to do this.
The theme review process has methods for testing, but that's because themes offer a relatively fixed set of interfaces serving very specific purposes. These are predictable, and can be tested according to a consistent set of rules.
Plugins, however, do not have any such limitations. The time required just to identify *what* needs to be tested for many plugins is greater than the total time required to test a theme.
So before any consideration can be given to a mechanism to label plugins as accessible, there needs to be enough labor available to actually do this.
I would also agree with @Otto42 that the business model is not a sensible place to have this information. It makes the most sense to keep it as a tag, but introduce testing procedures. But we can't underestimate just how much work that would be to maintain.
#3
@
2 months ago
Additionally, any reviews for accessibility on plugins would likely be constantly outdated.
Plugins development often iterates much faster and changes the HTML structure of the plugin admin pages / front end, etc, fairly often.
Themes are much less likely to have large changes that require re-review.
"Acceesibility Ready" is not a business model. Doing this would make no sense.
You could add accessibility ready as a tag or a category, if you like. But as a business model, it does not make any sense.