Properly associate the spacer height input label.

[afercia]

Description

Properly associates the existing <label> element to the spacer height input field.

I'd like to remind, once again, that any UI control must be properly labeled. In order fo preference:

• with a visible <label> element associated with for/id attributes
• with a visually hidden <label>
• with aria-label or aria-labelledby

A visible, properly associated label is preferable because:

• it works with any device/assistive technology
• when clicked, it focuses the associated control
• it's visible, so it's available to all users including, for example, speech recognition software users who need to know the name of a control to activate it

Currently, the <label> element is just a stray label. Not associated with anything. This way, it's just text in the page and doesn't have any purpose. Additionally, the input field has an aria-label attribute that basically repeats the visible label and doesn't add any relevant information:

• label: Height in pixels
• aria-label: Height for the spacer element in pixels.

This PR:

• uses for/id attributes to associate the visible label
• removes the aria-label
• fixes the class names used in edit removing the wp- prefix

Worth noting the aria-hidden attribute rendered in the front-end is pointless because an empty <div> is not exposed in any way to assistive technologies. Ideally, it should be removed but it doesn't harm anything.

Fixes #6918

[tofumatt]

Looks good to me 👍

Tested it and the label works as expected.

Thanks for the PR, but a bit of a comment on the PR description: it makes sense and it's handy to understand what we should be doing with labels re: accessibility, but there are two issues with the PR description here:

1. the lesson makes it hard to parse what the PR is actually doing and what we should be checking
2. the description doesn't actually prevent anyone new to the project, going forward, with making the same mistake

Looks like what should actually happen is that we should require an ID or make one if one isn't supplied and there's a single child. I've filed #6989 as a follow-up for this, but this is good to merge IMO.

[youknowriad]

I guess these should be core-blocks-spacer__* instead

[afercia]

Changed the classNames with core-blocks-spacer__*.

the lesson makes it hard to parse what the PR is actually doing and what we should be checking

Thanks for your suggestion @tofumatt. Next time, I will certainly avoid the "lesson". After all, since the start of this project, it's just the 19th time (I'm maintaining a list and counted the occurrences) I'm opening an issue or pushing a PR to fix such a simple thing like HTML labels. Since I've explained what the issue is so many times, I'd agree it's absolutely pointless to try to explain it again the next time a missing or improperly associated label is merged in the codebase.

Also, worth noting there was an issue proposing to introduce some form of automated test for the labels, see #6098. It was then closed as "not essential for 5.0" so I'm expecting all developers involved in this project will know what to do with labels without having to rely on the help of some automated test.

[tofumatt]

To be clear: I don't think it's pointless nor unimportant. But the component in question has a confusing API: that was the point of me filing #6989–a label is created using the component and it appears.

Creating an unlinked label here is an easy mistake to make, and I think it's not on developers not caring but the component having an API that is both unclear (no error when no ID is provided) and that creates the wrong expectation (the label prop doesn't actually function as I'd expect).

I don't think any developers are setting out to create inaccessible code, but it looks like in spots we've made it easy. The best way to fix that. going forward, would be to address code quality issues like #6989.

[mtias]

This seems to have broken the resize handlers (blue dots).

[aduth]

Proposed fix at #7024