Accessibility: Multi edit widget (select and checkboxes) need labels

[phiw13]

Both the multi-edit select widget and the associated checkboxes are currently completely un-labeled and are next to impossible to handle through AT.

The select widget should have either a label (possibly hidden through the relevant CSS class) or aria-label. The checkboxes should have either an aria-label or a aria-labelledby attribute to identify (name) them.

With Firefox: Right-click / control-click on element, choose “Inspect Accessibility Properties” from the context menu. The accessibility inspector displays an angry red warning about the need for the element to be labeled.

Attached: screenshot from the Article pane with Firefox 107b Accessibility inspector

[philwareham]

Looking at this, I have put a label onto the first multi-select <select> tag as a start.

Proposals:

1. Obviously that we put labels onto the subsequent fields that are generated within the multi edit step.
2. For checkboxes, we need to add some new Textpack strings probably like so...

bulk_select="Bulk select all/none"
bulk_select_row="Bulk select row"
bulk_select_status="Currently xxx item(s) selected"  (xxx= the number of items currently selected)

Possibly also some ARIA to show the linkage between the checkbox column and the multi-edit widget.

I'd need help from @Bloke and/or @bloatware to implement some of the above, as parts of it are beyond me.

[Bloke]

I'll take a look at this. Would someone please whip up some best-practice markup for the checkboxes with aria labels etc, so I can deconstruct that and fold it into the code. Thanks.

Also, are we talking just the multi-edit checkboxes in the left column? Or do any of the secondary select options need labels too? e.g Developer preview options, reassign assets options, assign page/style options, etc. Scratch that. Just seen #1840

[philwareham]

OK @Bloke, I have had a think about this, and here is what I think would work:

<table class="txp-list">
    <thead>
        <tr>
            <th class="txp-list-col-multi-edit" scope="col">
                <label for="select_all" class="txp-accessibility">Bulk select all/none</label>
                <input type="checkbox" value="0" name="select_all" id="select_all" aria-description="Currently 2 item(s) selected" aria-live="assertive"></th>
            <th class="txp-list-col-id" scope="col">ID#</th>
            <th class="txp-list-col-title" scope="col">Title</th>
        </tr>
    </thead>
    <tbody>
        <tr class="selected" aria-selected="true">
            <td class="txp-list-col-multi-edit">
                <label for="bulk_select-3" class="txp-accessibility">Bulk select row</label>
                <input id="bulk_select-3" type="checkbox" class="checkbox" value="3" checked="checked">
            </td>
            <th class="txp-list-col-id" scope="row"><a href="#">3 [Edit]</a></th>
            <td class="txp-list-col-title"><a href="#">Test article 3 title [Edit]</a></td>
        </tr>
        <tr class="selected" aria-selected="true">
            <td class="txp-list-col-multi-edit">
                <label for="bulk_select-2" class="txp-accessibility">Bulk select row</label>
                <input id="bulk_select-2" type="checkbox" class="checkbox" value="2" checked="checked">
            </td>
            <th class="txp-list-col-id" scope="row"><a href="#">2 [Edit]</a></th>
            <td class="txp-list-col-title"><a href="#">Test article 2 title [Edit]</a></td>
        </tr>
        <tr>
            <td class="txp-list-col-multi-edit">
                <label for="bulk_select-1" class="txp-accessibility">Bulk select row</label>
                <input id="bulk_select-1" type="checkbox" class="checkbox" value="1">
            </td>
            <th class="txp-list-col-id" scope="row"><a href="#">1 [Edit]</a></th>
            <td class="txp-list-col-title"><a href="#">Test article 1 title [Edit]</a></td>
        </tr>
    </tbody>
</table>

So, breaking it down:

1. Remove the title attribute from <th class="txp-list-col-multi-edit" scope="col">.
2. Add a <label> tag to the checkbox within the above <th> (but only visible to screen readers).
3. Add aria-description="Currently xxx item(s) selected" aria-live="assertive"> to the checkbox in that <th>. I am hoping that the aria-description is announced by screen readers in addition to the label and checked state. I am also hoping that by using aria-live="assertive" then changes to the amount of items selected are announced on the fly (as user selects/deselects items either in this checkbox or individually in the table body).
4. With regard to 3 above, some JS would be required to inject changes to the aria-description when user does actions.
5. Also, in my web console (Safari), I'm not seeing live changes to the checked state of checkboxes either in the head or body of the table (only the visual appearance seems to change) - so that might need some JS to help (or it could just be my browser playing up?).
6. Each of the checkboxes in the body columns of the table need a <label> tag (but only visible to screen readers).
7. The <tr> rows that are selected need aria-selected="true" added to them (currently only a class attribute is added, which is only a visual change, not something a screen reader can interpret).

There's a couple of ARIA assumptions in the above, but without having it live I can't test the theory.

[Bloke]

Sweet, that looks grand. Thanks, Phil. Lots of this functionality will have to come from JavaScript so I might call on @bloatware for assistance there. But I'll give the markup a go first and then fold the JS in.

Been reading up on aria-live. It says the element that announces things is set on an empty element. Our input control that checks all items isn't empty, so it may be that we need to move the live attribute and description to an adjacent element. Depends how strict the browsers are at interpreting things.

I'm also not sure how easy it is to inject the value into a string on the fly. Presumably we do that already to populate the visible "with N selected" so it'll just be an extension of that. Can't remember if that's done client side with search n replace or it does a round trip to the server to get the string and then do the replacement from the string with its curly brace placeholders.

Either way I expect we want to make that string as short as possible if it's going to be read aloud every time you check a box. There's also the consideration of singular/plural which have different rules for different languages and we can't rely on selected==1 to trigger a singular string. I'd be tempted to err on "{num} selected" which, although not as nice, means we only need one string and is quick to read if someome is tabbing through and selecting a bunch of things.

Also need to think about whether using assertive is the right flavour to use if you're tabbing quickly. It has to read out the item you're on so you know if you want it or not, and assertive would interrupt that when you check it. Is that better than having to wait for the whole item to be read out before telling people it's selected using polite? Maybe.

Lots to think about so let's put a stake in the ground and iterate from there.

[philwareham]

Thanks Stef - my thinking behind using assertive is that if someone actively selects an item then the screen reader announces it immediately, as they would presumably know what they were selecting beforehand. As I said, this is an assumption as I have not used this attribute in my day to day work and would only know how it behaves upon seeing a live example of the code.

I guess having aria-live on an initially empty element makes sense, as otherwise I presume the reader would announce it immediately upon page load, which would be confusing.

[Bloke]

Yeah. Who knows what will happen. Let's try it out and find out!