DataViews: add labels to "in-filters" #56001
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewhayward
added
[Type] Enhancement
|
Size Change: +1.64 kB (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
youknowriad
reviewed
Nov 9, 2023
| value={ activeValue } | ||
| prefix={ | ||
| <InputControlPrefixWrapper | ||
| as="span" | ||
| as="label" | ||
| htmlFor={ id } | ||
| className="dataviews__select-control-prefix" | ||
| > | ||
| { filter.name + ':' } |
There was a problem hiding this comment.
Aside: Just saw this, I think we should either remove the : or use sprint and __ here, not all locals support this notation I think. cc @oandregal
There was a problem hiding this comment.
👍 This is going to become "Author is" when the new component is ready.
There was a problem hiding this comment.
I'll wait until this PR is merged to fix it – or if you'd rather do it yourself, @andrewhayward, you're welcome :)
There was a problem hiding this comment.
@oandregal I'll let you do that in a separate PR. Scope, etc!
oandregal
reviewed
Nov 9, 2023
| @@ -18,12 +19,16 @@ export default ( { filter, view, onChangeView } ) => { | |||
| ? '' | |||
| : valueFound.value; | |||
|
|
|||
| const id = useInstanceId( InFilter, 'dataviews__filters-in' ); | |||
There was a problem hiding this comment.
Nice, thanks. Could we use as id something like dataviews__filters-in-author instead of dataviews__fisters-in-0?
We could take the field name from filter.field (author, status) and they are unique. filter.name is more of a user-facing name (can have spaces, etc.) so it wouldn't work that well I guess.
There was a problem hiding this comment.
Should we use React's useId instead of useInstanceId? Feels like the latter should be deprecate these days.
There was a problem hiding this comment.
Happy to go with whatever works for the team. If we're confident that filter.field is unique, and each filter type will only appear once on the page, then makes sense to use that – in which case, we won't need to apply either useInstanceId or useId.
oandregal
approved these changes
Nov 9, 2023
|
Flaky tests detected in 5041584. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6825227413
|
cbravobernal
pushed a commit
that referenced
this pull request
Nov 14, 2023
* Add labels to data views "in" filters All user inputs should have an accessible name, ideally provided by a visible label. This patch ensures that data views "in" filters semantically associate the visible label with the select input, ensuring that the input has an accessible name.
oandregal
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This patch ensures that "in-filter" inputs have accessible names.
It is an alternative approach to that explored by #55977, tackling the issue closer to the problem. Given the likely short-term lifecycle of the filter implementation, this is more economical alternative to #55963.
Why?
All user inputs should have an accessible name. This is currently lacking in data view filters.
How?
The visible label is updated to use a
<label>element, and semantically linked to the select input with afor/idcombination.The alternative of setting
label/hideLabelFromVisionprops on the parent<SelectControl>was considered, but this approach has the benefit of physically associating the label with the control as well as semantically, so clicking on it will focus the input.Testing Instructions
Nothing should visually change.
Using developer tools, a screen reader, or similar, confirm that the filter inputs have accessible names, derived from the visible labels.