Categories block misses a label when set to "Display as Dropdown"

[afercia]

Describe the bug

Both the Archives and Categories blocks can be set to "Display as Dropdown" so they are rendered as a <select> element:

While the Archives select does have a properly associated <label> element, the Categories select doesn't.

This is important not only in the admin interface, but also in the front-end where the Categories select is unlabelled and produces non WCAG compliant code:

Notice there are some styling issues (screenshot from Twenty Seventeen), I'd expect to see some spacing between the two labels.

Regardless, the Archives select has a visually hidden label (with a screen-reader-text CSS class). The Categories select is unlabelled thus there's the need to add a properly associated <label>.

Worth noting in core the Categories widget outputs a visually hidden label so there's no parity with what core does.

Additional note:
I'd tend to think the labels shouldn't be visually hidden. It's not up to Gutenberg to determine if the labels should be visible or not in the front-end. I'd propose to consider to remove the screen-reader-text CSS class in the admin and in the front-end, as their visibility should be up to the theme.

Noting it's a different case from what core does with the related current widgets, as these widgets have an option to display a title. In Gutenberg instead, there's no title. Making the labels visible would address this issue and allow themes to style them in the way they want.

[Luciaisacomputer]

If I have some capacity today I can take a look at this. I can find the root cause for the label not appearing and then once fixed create another PR with a variant of the selects that contains visible labels. I totally agree that labels should always be visible unless there is a very solid reason to not display them.

[desrosj]

@LukePettway @afercia is anything else required for this?

[afercia]

@desrosj seems to me the related PR is in good hands 🙂and @tofumatt filed two new issues to propose to make the labels visible see #10912 (comment)

@LukePettway thanks!

[youknowriad]

It looks like the PR only added the label in the editor and not the frontend.

[Luciaisacomputer]

@youknowriad That is correct. I have another PR that adds the label on the frontend. It also removes the screen-reader-text class as discussed here as well.

#11219

[youknowriad]

It felt to me like the frontend label was agreed upon but the removal of screen-reader-text not yet. So it could get merged quicker if was just the label for now but happy to include the whole thing when it gets reviewed

[Luciaisacomputer]

@youknowriad That's fair enough, I can always cherrypick the commits and push a seperate PR if needed.

[oandregal]

Consolidating this in #11002 and #11003 which have a corresponding PR at #11219