-
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
Updates to the Font Size Picker #9802
Conversation
Does the size progression of the 'A' hinder accessibility? Seems like now, the UI relies on vision. |
The buttons have tooltips for "Small", "Medium", "Large". |
b470109
to
4bc0b28
Compare
@jasmussen should we make the input match the height of the select now? |
Yes I think so. |
Pushed 6a4f92d. Worth noting that navigating in a |
This commit does a few things: 1. It makes the panel heading the same color as the down chevron. 2. It adds a label to the font size picker, grouping it all together 3. It tightens the margins between switch and contextual help text. 4. It relaxes the margins for base controls inside panels, to make them a bit lighter. Together with #9784 it reduces the weight of panels in the sidebar.
- Add "huge" and "normal" variants. - Normal equals a "reset".
6a4f92d
to
18ba6db
Compare
return ( | ||
<Fragment> | ||
<BaseControl | ||
label={ __( 'Font Size' ) } |
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.
The BaseControl renders a <label>
element with a for
id that is not associated to any element. It's an orphaned label which basically doesn't do anything. So, the visible text "Font Size" shouldn't be a <label>
element.
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.
The BaseControl renders a
<label>
element with afor
id that is not associated to any element. It's an orphaned label which basically doesn't do anything. So, the visible text "Font Size" shouldn't be a<label>
element.
@afercia Noting this after my comment at #9802 (comment) . If I understand correctly, the issue was more that a label
element was being rendered, but without the necessary for
attribute? Am I correct in thinking that there should either be a for
attribute assigned, or no label (i.e. text) at all? As merged, the implementation was changed to render a span
in place of the label
, which doesn't feel quite right to me when there's clearly an input related to the label's text.
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.
Yep I've just commented on #10925 (comment) using the same screenshot :D
When the font size picker was changed to a custom component, the label was an orphaned label.
Am I correct in thinking that there should either be a
for
attribute assigned
The size picker custom component is made of buttons so a label with a for
attribute wouldn't be appropriate.
or no label (i.e. text) at all?
I guess the text is necessary for visual purposes.
For the records: I wasn't happy with the new size picker, it's non-native and its semantics and interaction are problematic. That change was introduced without even asking for some initial accessibility feedback. Alas, this is what happens when visual design considerations take priority on semantics and accessibility.
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.
Could the label
element have directed to the button
rendered by the custom dropdown (what appears in the screenshot above as "Normal" dropdown-looking element)?
Separately, considering how we might help avoid this scenario in the future: It would be fairly trivial to create an ESLint rule which forbids a BaseControl
that includes label
prop but omits id
. One problem with this may be, as you point out, that a visual text may be appropriate as long as the inputs assign aria-label
? Scanning those child elements would be more difficult to enforce. Arguably in those scenarios I might suggest the visual label be rendered as just another child, not using the label
prop. That way, we can support both cases and ensure that label
prop, if present, must have a corresponding id
.
By above, what I mean is that both of these would be valid:
<BaseControl label="Font Size" id="my-input">
<input id="my-input" />
</BaseControl>
<BaseControl>
<span>Font Size</span>
<input aria-label="Font Size" />
</BaseControl>
And the following invalid (a case very similar to #10925):
<BaseControl label="Font Size">
<input id="my-input" />
</BaseControl>
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 might suggest the visual label be rendered as just another child, not using the label prop.
Seems the most appropriate thing to do!
</ButtonGroup> | ||
) } | ||
renderContent={ () => ( | ||
<NavigableMenu aria-labelledby={ labelId }> |
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 don't see this aria-labelledby
rendered in the DOM, so the whole menu is unlabelled.
Ah ok I see now it's rendered on the menu when it's open. However, this is a problem as when the menu is closed, the toggle button will just say, for example, "Normal" without telling what it's about.
This design is using an UI control to communicate a setting state, and not the available action. As mentioned several times this is an anti-pattern for a11y.
className="components-range-control__number" | ||
type="number" | ||
onChange={ onChangeValue } | ||
aria-label={ __( 'Custom Size' ) } |
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'd suggest to clarify and use "custom font size". Also, since this is invisible to the eyes, it doesn't need to be title cased.
In Safari, I see the arrows just triggers |
renderContent={ () => ( | ||
<NavigableMenu aria-labelledby={ labelId }> | ||
{ map( fontSizes, ( { name, size, slug } ) => ( | ||
<Button |
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.
As the NavigableMenu
uses a role="menu"
, all the menu items within it should have a role="menuitem"
.
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'd be great to have a lint rule that checks for role="menu"
in children of any NavigableMenu
.
Not certain how to reproduce the Safari bug, for me Up/down arrows only navigate the font picker. |
@@ -7,7 +7,8 @@ function BaseControl( { id, label, help, className, children } ) { | |||
return ( | |||
<div className={ classnames( 'components-base-control', className ) }> | |||
<div className="components-base-control__field"> | |||
{ label && <label className="components-base-control__label" htmlFor={ id }>{ label }</label> } | |||
{ label && id && <label className="components-base-control__label" htmlFor={ id }>{ label }</label> } | |||
{ label && ! id && <span className="components-base-control__label">{ label }</span> } |
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.
The use-case does not feel legitimate. I don't think we should support BaseControl
with a label
and not an id
. The label should always direct to an input, even in the case of the font size picker.
This leaves open the possibility for error like described at https://github.com/WordPress/gutenberg/pull/10925/files#r257248594 .
This PR aims to add a bit more clarity and simplify the font-size control. It removed the S M L XL denotations in favor of size reference. It also groups the custom size input with the reset and on the same line. Furthermore, it disabled the display of the slider by default.
Sizes are rendered at their correct value (as supplied by the theme). "Normal" is the same as "Reset".
In Progress
To Do:
NavigableMenu
?.Select
based onDropdown
?)