-
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
Use aria-describedBy to communicate border button style and color state #54469
base: trunk
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeryj Can you switch to using VisuallyHidden from wordpress/components
?
</span> | ||
</Button> | ||
<> | ||
<div id={ descriptionId } style={ { display: 'none' } }> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hiding descriptions makes them inaccessible.
<div id={ descriptionId } style={ { display: 'none' } }> | |
<VisuallyHidden id={ descriptionId }> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, since descriptions are attached to the button via aria-describedBy
, they get announced when focus is on the related button. Using <VisuallyHidden/>
it was announced twice: once before the button, and once while focus was on the button.
I was going off of @afercia's comment:
Add an aria-describedby attribute that points to an element containing the additional information. This element can also be hidden with display: none, screen readers will announce the description anyways.
I feel like one announcement semantically linked to the button is better than it announced before the button and again with the button, but I'm also aware I'm not a pro screen reader user so I'll defer to your judgement :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeryj Yeah, I tested it and display: none;
is not allowing the updated description to be read. It just has the default not selected message even after selecting a color.
Should probably place the description outside of the button though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll go ahead and change it to VisuallyHidden
. Which screen reader + browser are you testing on? I'm curious to see if I can use display: none;
and still get it to update the message after selection so it's not as verbose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeryj NVDA with Firefox.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, did you test with the current version of this PR that is using <VisuallyHidden/>
? Or did you edit it to go back to the display: none
method? I'll update this PR to the display: none;
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeryj I just tested the current version of the PR but I created a similar situation in a local testing file. If you revert back, will be interested to see if it works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the PR to use display: none;
. If it doesn't work, then one possibility is that it doesn't work reliably after a selection due to the description div being removed and remounting when the component updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeryj I think it might be the re-mounting issue. It no longer works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened an issue to discuss and work on this: #55362
<> | ||
<div id={ descriptionId } style={ { display: 'none' } }> | ||
{ toggleAriaDescription } | ||
</div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
</div> | |
</VisuallyHidden> |
Flaky tests detected in 87a07f2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6590188245
|
import type { ColorObject } from '../../color-palette/types'; | ||
import { isMultiplePaletteArray } from '../../color-palette/utils'; | ||
import type { DropdownProps as DropdownComponentProps } from '../../dropdown/types'; | ||
import type { ColorProps, DropdownProps } from '../types'; | ||
|
||
const getAriaLabelColorValue = ( colorValue: string ) => { | ||
const getAriaDescriptionColorValue = ( colorValue: string ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this function should be renamed to remove anything to do with aria
. Small point but this seems to just be stripped var()
from any CSS vars am I right? In which case let's
- Rename to better advertise it's purpose
- Consider extracting to a file and adding some quick unit tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this could be made into a more generic utility function. Looks like it would be useful elsewhere too. Would you be OK with this also being a follow-up? It's starting to expand the purpose of this PR a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have a number of tasks that should happen as follow ups. Whilst I'm fine with them being follow ups I really think that whilst we're in the guts of this it would be good to leave the code in a better place than we found it if possible 🙏
colorValue: CSSProperties[ 'borderColor' ], | ||
colorObject: ColorObject | undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this function need to know so much? Can it not simply accept a colorValue and the consumer can pass the appropriate value. This could reduce the number of confusing conditionals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see it needs to get the name
from the object....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In which case it could accept
colorValue
colorName
That way it would not need to know about the structure of a colorObject
. It can then simply compute appropriate strings based on what you provide it.
Again let's not do this refactoring without tests 🙏
@@ -65,68 +66,77 @@ const getColorObject = ( | |||
return colors.find( ( color ) => color.color === colorValue ); | |||
}; | |||
|
|||
const getToggleAriaLabel = ( | |||
const getToggleDescription = ( | |||
colorValue: CSSProperties[ 'borderColor' ], | |||
colorObject: ColorObject | undefined, | |||
style: CSSProperties[ 'borderStyle' ], | |||
isStyleEnabled: boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this boolean signify? What is "style enabled"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm honestly not sure -- I only renamed it to feel more accurately named and used what I needed from it. I haven't looked into it further. I do agree a refactor would be nice, but I'd prefer it as a follow-up.
@@ -65,68 +66,77 @@ const getColorObject = ( | |||
return colors.find( ( color ) => color.color === colorValue ); | |||
}; | |||
|
|||
const getToggleAriaLabel = ( | |||
const getToggleDescription = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to extract this function and write some simple tests for the various conditionals. These are outlined in your test instructinos for the PR and it would provide a lot of confidence if they were encoded into tests:
- No style, no color
- Style, no color
- Named color, no style
- Named color, with style
- Hex/rgba color, no style
- Hex/rgba color, with style
I would also say it's worth refactoring it with the aim of removing the branches and conditionals but that could be done in a follow up and should not even be attempted unless we have tests in place 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this should all get refactored. As I was working within the context of what was here, I didn't want to change up things too much since I only wanted to provide a better description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It needs tidying up. I appreciate that's a big ask for this PR though. Feel free to add as a follow up task if you like.
I would help but I don't have bandwidth at this time 🙇
70dd01f
to
634864f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ready to go code wise - what is holding it back? I do agree with @getdave 's follow up points but the PR itself achieves its goals.
An approval :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeryj Looks good.
Follow-ups:
- Code quality/refactor.
- Fix the screen reader description re-rendering bug.
Need to fix the failing tests and add a changelog entry.
Size Change: +6.93 kB (0%) Total Size: 1.66 MB
ℹ️ View Unchanged
|
The previous approach appended a long message to the aria-label to communicate the state of the color selection. This is not desireable, as it changes the accessible name of the button. The accessible name of the button should be stable and brief, and not be used to communicate state. By using aria-describedBy, we can communicate the state in a way that is similarly announced but keeps button name and state separate.
87a07f2
to
9315c6a
Compare
What?
Communicate border color and style via
aria-describedBy
using an approach explained by @afercia in #54439 (comment)Why?
The previous approach appended a long message to the aria-label to communicate the state of the color selection. This is not desireable, as it changes the accessible name of the button. The accessible name of the button should be stable and brief, and not be used to communicate state. By using aria-describedBy, we can communicate the state in a way that is similarly announced but keeps button name and state separate.
How?
Switches from appending state to the aria-label and adds an aria-describedBy attribute with hidden text (via
display: none;
, as the text will be read via focus on the button and doesn't need to announced otherwise.Testing Instructions
Screenshots or screencast