-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix accessibility of the edit site global styles Variation #59508
Conversation
Size Change: -36 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
e226a6e
to
d8ae148
Compare
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
d8ae148
to
0a8a142
Compare
I rebased this. |
This makes sense to me, but it's a change in the design so I'd like to hear from someone with a design opinion |
The styles variations have changed a lot on latest trunk at the point I'd prefer to start over with a new PR, when I have time. Closing this one. |
Fixes #59459
What?
The global styles Varaition are made with foucsable
div
elements instead of native buttons.When using
div
rather than a button, all the native button features and intereaction should be re-implemented. That appears to not be the case with the current implementation.Why?
Overall, given the amount of code that would be required to make a focusable
div
element fully accessible and behave like a button, it's way better to use a button element. There's no reason to not use a button element a smodern browsers allow to fully style them.More importantly, custom implementation should be avoided as they defeat the purpose of building a library of reusable component in the first place. It's unlikely that custom implementations have the same level of accessibility and the same design consistnecy of the base components. Instead of implementing custom interactive controls in the UI, the base component should be used and if a new variant of a base component is desired that should be added to the base component.
This PR replaces the focusable
div
elements with a Button compoennt, becuase the Button brings in all the accessibility, interaction, and base styles like focus style that we need to make a better usable and accessible UI.How?
div
custom implementation with a Button component.Testing Instructions
src/wp-content/themes/twentytwentyfour/styles/maelstrom.json
file and add a description to the style variant e.g.:"description": "This is the Maelstrom description"
Maelstrom
variant button does have a visually hidden descriptionThis is the Maelstrom description
.aria-current="true"
attribute, this hasn't changed.Maelstrom
variant button does have a visually hidden description.Testing Instructions for Keyboard
Screenshots or screencast
Before with focus and active states. Notice the states difference is basically only a color change of the visual outline (although there's a barely noticeable change in the outline thickness). Basically this is color alone, which is insufficient.
Before with focus and active states: