Navigation Block placeholder dropdown - use a11y friendly label.

[getdave]

Jerry asked about labeling in the Slack accessibility channel. https://wordpress.slack.com/archives/C02RP4X03/p1591390740446600

Here is a reply from Joe Dolson.
"Using an option for a label introduces a few problems: it’s disabled, so the color contrast is a problem. Disabled controls are an exception to color contrast guidelines, but labels aren’t. 2nd, (which may not be relevant in this use case), the label would be non-obvious if a value is selected in the select, since it would no longer be the first perceived value, and 3rd, screen readers will skip the disabled option when focusing on the control, and go directly to the first enabled option. The faux label would not be read. If the option is also given the “selected” value, then it will be focused by a screen reader, but will also be described as an invalid entry, which could be confusing."

Originally posted by @paaljoachim in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDI0MjE0OTA5/pull_request_reviews/more_threads

---

This Issue tracks the need to consider using a visible label for the dropdown used in the Navigation Block which will be in place once #18869 is merged.

Currently, the first option element acts like a kind of pseudo label. This could be updated to use a real menu and the first option could be amended to Please select... or something generic like that.

[jeryj]

From the #accessibility feedback, here's the concise version of the constraints we need to operate in:

1. We must have a label for the <select> element. This could be the "Create a Navigation..." or other text.
2. If we choose to leave the "Create a Navigation..." text and add another label, then the "Create a Navigation..." can be semantically linked to the <select> via aria-describedby.
3. We should not have any "placeholder" text in the <select> (i.e. "Select where to start from..."). Only valid values should be in this <select>.

If we are sectioning options off (like with the divider line), we could maybe add headings to each section if this is a custom <select> implementation that allows for that. However, that may be outside the scope of this component depending on implementation.

[jeryj]

@karmatosed - Pinging you here, as @getdave says you're leading the design on this component 🙌

[karmatosed]

Thanks for the ping. I am going to loop in @enriquesanchez here for a perspective on this as hopefully, we can work out an option.

[getdave]

Can I also flag this Issue which tracks the problem of using the first option in the <select> as a pseudo label.

[enriquesanchez]

Could the "Create a Navigation..." text act as a label with aria-labelledby?

From https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA7:

With the aria-labelledby attribute, authors can use a visible text element on the page as a label for a focusable element (a form control or a link)

Would that get too repetitive?

[tellthemachines]

Hey peeps, my comment here should be relevant for this discussion. Pasting below:

What I propose:

• Let's improve the text inside the <label>. Currently, the <label> is visually hidden and reads "select to create from pages, existing menu or empty". That's not awfully clear.
• Let's make the label visible, and remove the visible <div> that reads "Create a navigation from all existing pages, or choose a menu.": we should only need one set of clear, visible and screen reader accessible instructions.
• Let's remove the "placeholder" option altogether and set a sensible default as the first value.

Suggestions very welcome for copy improvement 🙂

[talldan]

@tellthemachines I thought I'd mention there an issue related to copy here as well - #22987, given you mentioned changing the copy above. They could possibly be combined.