You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Darn, I just realized that my recording didn't get the screen reader audio, but you can read what it's saying on the speech viewer on the page. If anyone wants me to re-record, let me know and I'll post a new video.
There was conversation about adding a tool-tip to this button starting here: #265 (comment)
It brought to my attention that in 15 years of using WordPress I have never understood what this does or how to even view my favorites.
I think it might be better for users if this button triggered an accessible modal with two things:
Favorite Plugin button
View Your Favorites link
This is something similar that we did for a client site a while ago. It's more complex than we need (it has checkboxes because they can have multiple places to save things), but this is what I mean by a modal.
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
Screenshot of the element:
Element Code
This is the current code from the Gutenberg test page:
When the plugin is favorited, the accessible name (in this case, added as screen reader text) changes:
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.
The text was updated successfully, but these errors were encountered: