On the plugin single test page ( Gutenberg plugin test page ) and also on the current live plugin single ( Accessibility Checker example ) there are three accessibility problems with the button to favorite the plugin.

Accessibility Issues

1. This is incorrectly coded as a link instead of a button.
2. The accessible name changes.
3. When activating the favorites button, the page reloads and focus in not set on the element.

Screenshot of the element:

Element Code

This is the current code from the Gutenberg test page:

 <div class="plugin-favorite"> <a href=" https://test.wordpress.org/plugins/wp-json/plugins/v1/plugin/gutenberg/favorite?_wpnonce=490b4e5bd7&amp ; favorite=1" class="plugin-favorite-heart"> <span class="screen-reader-text"> Favorite Gutenberg		</span> </a> </div>

When the plugin is favorited, the accessible name (in this case, added as screen reader text) changes:

 <div class="plugin-favorite"> <a href=" https://test.wordpress.org/plugins/wp-json/plugins/v1/plugin/gutenberg/favorite?_wpnonce=490b4e5bd7&amp ; unfavorite=1" class="plugin-favorite-heart favorited"> <span class="screen-reader-text"> Unfavorite Gutenberg		</span> </a> </div>

Detailed problem explanation

Incorrect Role

This element has an incorrect role - links go somewhere; buttons do something. This should be a button, not a link. Having it as a link is especially confusing because if I go to the Favorites button with a screen reader, instead of hearing something like "Button, Favorite Guttenberg, Pressed" I hear "Visited, link, Unfavorite Gutenberg, article."

Inconsistent Accessible Name

It can be very confusing for screen reader users if the name of an element changes. Users don't expect labels to change on elements and may look for the original label but be unable to find it.

Rather than changing the screen reader text from "Favorite Gutenberg" to "Unfavorite Gutenberg," this should be coded as a toggle button that indicates if it has been pressed or not with aria. That way the screen reader text does not need to change.

@alexstine may have additional thoughts about this.

Loss of Focus on Activation

Because this is a link, when activated the page reloads. Screen reader users are dumped at the top of the page and need to then find their way back to this button if the want to undo the action or if they want to proceed down the page.

Recording

Here's a recording of interacting with this element and what I hear in VoiceOver:
https://github.com/WordPress/wordpress.org/assets/13153456/c9338086-39e6-41c3-96a3-26f8564e2f4b

Recommendation

In an ideal world this would be rebuilt with a button tag. If that is not possible, it can have role="button" added to it and a spacebar handler added so that it function as a button (buttons should be able to be triggered with the spacebar and return key). See role=button documentation .

The accessible name should always be "Favorite $Plugin-Name" and then you use aria-pressed to indicate if it's been set as favorite or not.

Ideally, this would activate with JavaScript and not require a page reload. If the page reload is kept, then there should be something that returns keyboard focus to the button on reload of the page.