GeezerVison is showing github.com — Accessibility: Multi edit widget (select and checkboxes) need labels · Issue #1842 · textpattern/textpattern
Accessibility: Multi edit widget (select and checkboxes) need labels #1842DescriptionBoth 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
Activityphilwareham commented on Dec 12, 2023 Looking at this, I have put a label onto the first multi-select <select> tag as a start.
Proposals:
- Obviously that we put labels onto the subsequent fields that are generated within the multi edit step.
- 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 commented on Dec 12, 2023 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 commented on Dec 12, 2023 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:
- Remove the
title attribute from <th class="txp-list-col-multi-edit" scope="col">.
- Add a
<label> tag to the checkbox within the above <th> (but only visible to screen readers).
- 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).
- With regard to 3 above, some JS would be required to inject changes to the
aria-description when user does actions.
- 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?).
- Each of the checkboxes in the body columns of the table need a
<label> tag (but only visible to screen readers).
- 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 commented on Dec 12, 2023 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 commented on Dec 12, 2023 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 commented on Dec 12, 2023 Yeah. Who knows what will happen. Let's try it out and find out! phiw13 commented on Aug 26, 2025 petecooper commented on Nov 18, 2025 petecooper commented on Dec 3, 2025 @phiw13 Does 311151c resolve the issue as it stands? Asking for clarity on potential 4.9.0 blockers. Thank you! phiw13 commented on Dec 3, 2025 Well… this improves the situation a lot for the article list panel. All other list panels need the same treatment, and then the multi-edit widget on the Forms panel and the Categories panel need the same attention.
The latter two probably need some slightly distinct treatment as those are not nested inside a table markup. For the Forms panel, I think using aria-label instead of label might be a better option. I vaguelly seem to remember that Theme Hive use position:absolute for the checkbox wrapper. petecooper commented on Dec 3, 2025 Thanks @phiw13 - from my understanding of #1842 (comment), it feels appropriate to open a new issue re: list panels and an additional issue to track the Forms and Categories panels multi-edit component…we can assess that for a 4.9 patch release.
I'll provisionally close this issue as complete (within the scope of the opening post), and we can undertake the other changes with their respective issues – more so if those changes need structural changes in the theme scaffold in other repos. Bloke commented on Dec 3, 2025 I (or someone) needs to roll out the changes I made to the Articles (list) panel to the other table-ish panels, which is covered by the scope of this issue. petecooper commented on Dec 3, 2025 Re-opened. Thanks @Bloke for the course correction. Bloke commented on Dec 19, 2025 @phiw13 What do you think about the usefulness of this in the Comments panel? Currently, if I mimic what we do on other panels, the Voice Over reads out "Bulk select row ID zero zero zero zero zero three" which is seriously annoying.
Other anomalies are the Themes, Sections, Users and Plugins panels because we don't have an id on the rows, so when it announces "Bulk select row ID five" there's no obvious link to indicate which row it is.
Any thoughts? phiw13 commented on Dec 20, 2025 For the comments table, that is still OK.
For the other panels (and categories and forms panel will have a similar issue), the only identifier would the name column. Or if that is hard to do just before 4.9.0 drop, as a first step in the better that nothing world, just drop the ID part, and revisit for a .x release. Or wait with those panels for now.
For the most important ones, the “all-users” facing ones it is already a huge improvement. petecooper commented on Dec 20, 2025 The bulk of this is complete for now, I'm retargeting to 4.9.1 (edit: with proviso that it might move to 4.9.other) so we can reassess with fresh eyes after 4.9.0 has settled.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
