Add label to Tableselect select all checkbox

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

Personally I think this will need test coverage for the label rendering.

This will need an issue summary for proposed solution, screenshots, etc. Recommend following default template.

There is a way to add this in a theme if needed.

In the library with the CSS that customizes the checkboxes, add a dependency on core/tableselect, the library that adds the tableselect checkbox.
Add a js file to the library and in a behavior, add something like:
$('th.select-all.views-field-node-bulk-form input[type="checkbox"]').after($('<label></label>'))
(obviously doesn't need jQuery, but since tableselect is jQuery based)

The missing label on an input is getting flagged by accessibility scanning tools like Wave.

Alerts
Unlabeled form control with title

What It Means
A form control does not have a label, but has a title.

Why It Matters
The title attribute value for unlabeled form controls will be presented to screen reader users. However, a properly associated text label provides better usability and accessibility and should be used unless the purpose of the form control is intuitive without the label.

How to Fix It
If a visible text label is available for the form control, associate the text label to the form control using the label element. This provides additional functionality for end users because if the label is clicked it will set focus to the form control. If the form control is intuitive without a , the title attribute value may be used. Note that the title attribute value will not generally be read by a screen reader if the control has a label and may not be available to sighted users, particularly keyboard-only users.

The Algorithm... in English
An (except types of image, submit, reset, button, or hidden), , or
element has a non-empty title attribute value and is missing a label or valid aria-labelledby reference.

Code
<input type="checkbox" class="form-checkbox" title="Select all rows in this table">

Standards and Guidelines
1.1.1 Non-text Content (Level A)
1.3.1 Info and Relationships (Level A)
2.4.6 Headings and Labels (Level AA)
3.3.2 Labels or Instructions (Level A) Icon index

The Wave output in #48 states, among other things that labels should be used unless the purpose of the form control is intuitive without the label. In this case I believe the purpose of that checkbox is intuitive. If others feel differently, it would be necessary to alter the scope of this issue and propose a visible label for the "select all" checkbox

I think it would resolve the WAVE error without a visible change if an aria-label is added. If the title is left, that serves as a tooltip.

I don't think a visible label is needed.

patch in #42 does need some updates.

1. If adding label should the title attribute be removed. VoiceOver at least reads both
2. "updateSelectAll" function would need to be updated to update the label instead of the title
3. label /input should be placed in same order as other for consistency
4. label should probably have 'visually-hidden' class to match other checkbox labels

Other checkboxes are using a label with `visually-hidden` should we match that or should they be updated to use `aria-label` instead?

An aria-label attribute is preferable to a hidden label element. aria-label was created to avoid the need for tricks like making a visible label and then hiding it.

I ran the Wave check on the page, what was reported in #48 was not an error, but an alert. There is nothing that needs to be resolved. Per Wave's documentation:

RED icons indicate accessibility errors that need to be fixed. GREEN icons indicate accessibility features - things that probably improve accessibility (though these should be verified). The other icons and indicators, particularly the yellow alert icons, highlight other elements that you should look at

The alerts acknowledge this is characteristic of an accessibility error, but the overall context determines if there is actually an accessibility problem. There's nothing here to indicate that such a problem exists.

Patch in #42 no longer applied for me in 10.2, so I rerolled it. Uploading in case someone else needs it for now.