Custom interactions in control styled as a native control

[karlgroves]

Custom interactions in control styled as a native control

• Severity: Medium
• Affected Populations:
  • Low-Vision
  • Motor Impaired
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Block Panel

Issue description

In the Block panel, where the font size can be selected, users see what
appears to be a select element. However when keyboard users reach this
component, they cannot use standard keystrokes to change the value, such
as Up-Arrow or Down-Arrow, or Alt+Arrow to open the submenu. Instead,
users need to press Enter to view the submenu.

Keyboard users will expect this control to work the same as a native
select element. Speech recognition users often speak out keystrokes to
perform standard actions on native components, and these would not work
on custom components like these.

Issue Code

    <button type="button" aria-expanded="false" aria-label="Font size: Normal" class="components-button components-font-size-picker__selector is-button is-default is-large">Normal</button>

Remediation Guidance

Use a native <select> element in place of a custom button+submenu
setup.

Recommended Code

    <fieldset class="components-base-control__field">


        <legend class="components-base-control__label">Font Size</legend>


        <label for="font-size-picker">Choose basic size</label>


        <select id-"font-size-picker" class="attachment-filters">


            <option value="normal" >Normal</option>


            ...


        </select>


        <label for="custom-font-size">Custom font size</label>


        <input id="custom-font-size" class="components-range-control__number" type="number" value="">


        <button type="button" disabled="" class="components-button components-color-palette__clear is-button is-default is-small">Reset</button>


    </fieldset>

Relevant standards

• 2.1.1 Keyboard
  (Level A)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-68 in Tenon's report

[melchoyce]

Screenshot from the full report:

[afercia]

This custom component was introduced in #9802. Previously, the font size controls were a set of buttons. Worth revisiting this custom implementation in favor of a native <select> element.

[nicolad]

@afercia do we need design feedback on this since using <select> we will lose that visual cue related to the sizing?

[afercia]

@nicolad I'd say yes, at least some design feedback is necessary. Personally, I'm not sure the size "preview" in the control is really necessary, as the size change can be immediately seen in the block content.

Regarding the suggested markup, I'd like to discuss it with the accessibility team. As mentioned also in #15307, related form controls don't necessarily need to be always grouped within a fieldset + legend. Better semantics is always welcome but it's always necessary to take into consideration how markup affects the way controls are actually perceived by assistive technologies.

For example, some screen readers repeat the legend for any control in the fieldset. When the control label already contains the words "font size", I don't see a great practical value to also have a legend that says "font size". That would be just repeated the control gets announced, see screenshot below:

[mapk]

There was a conversation about this in today's Design Triage in slack.

While there was a desire to visually represent the actual font sizes in the dropdown, we understand if it causes issues with assistive devices. It doesn't appear that styling the select box options works across browsers to give the same visual appearance.

Here's a couple thoughts...

1. Current implementation with added functions
Is it possible to keep the current implementation and code it so that it works similarly to a native select box?

2. Native select box with visual icon
If we convert it to a native select box, maybe we can add a font-sizing icon next to the select box like below. But after looking at this, I think the icons just muddles it up too much.

3. Native selectbox only
Just make it a native select box without any visual additions.

[afercia]

Discussed during today's accessibility bug-scrub. Agreed to recommend to change this custom control to a native select element.

As per the suggested additional fieldset + legend, sorry I didn't notice the label controls were changed too. That makes sense because the combined text of the legend plus labels would read as:

<legend>Font Size</legend>
    Choose basic size
    Custom font size

Even better:

<legend>Font Size</legend>
    Choose preset
    Custom

[mapk]

To keep this moving forward, let's change this over to a native select box.

We're using native select boxes elsewhere in the UI anyways. Take a look at the Image Size select box.

[davewhitley]

As a more long-term approach to this issue, it would be good to add the necessary a11y functions to the custom "select", assuming it is possible and a viable approach. It's a common pattern in many component libraries, and it may be something needed in the future. For example, adding search to the select component for long lists of items. Maybe at that point, it becomes a "dropdown" though, but it still needs to be accessible.

[afercia]

It's a common pattern in many component libraries

In the last 3 years, I've gone through most of those "custom selects" and none of them is fully accessible. For a simple reason: they implement non-native, non-standard, behaviors and interactions.

The only accessible UI pattern that is close to all these various custom things is the Combo Box pattern. It's different though, more an input field with a list of suggestions rather than a custom select. Gutenberg already has a combo box component (the various auto-completers) and it works pretty well.

The point of this issue is to just use a native element rather than adding features to custom components that don't provide full support for browsers APIs and assistive technologies.