VUFIND-1673 Set unique labels for checkboxes

[maccabeelevine]

Per the accessibility report from Moravian, the checkboxes in various lists need to have unique labels. Moravian suggests using aria-labelledby and linking to the ID of the title's anchor element, but that link often does not have an ID, so it would have to be added. Seems easier to just spit out the title directly into the label.

See https://openlibraryfoundation.atlassian.net/browse/VUFIND-1673

[maccabeelevine]

There are various other checkbox lists that perhaps should follow the same approach, but I think feedback is helpful first.

select_item = "Select item for further action"
select_item_checked_out_renew = "Select item for renewing"
select_item_hold_cancel = "Select item for canceling holds or recalls"
select_item_ill_request_cancel = "Select item for canceling interlibrary loan requests"
select_item_purge = "Select item for purging"
select_item_storage_retrieval_request_cancel = "Select item for canceling storage retrieval requests"

[demiankatz]

See below for one technical question.

Beyond that, the bigger question is whether it's okay to replace an action-oriented label with just a title. Do we need to combine the two, e.g. "Select %%title%% for renewal"? I realize that making that change would require a significant amount of retranslation work, so it's not ideal... but losing the action label entirely also seems less than ideal.

Let me also draw your attention to #2999, which I believe is work in progress on code that's meant to be a foundation for solving this problem... but I think it's currently a bit stalled and needs more work.

[demiankatz]

Is it okay for aria-label to include HTML? I think by definition, it's possible that $this->titleHtml will contain markup (e.g. highlighting-related <span>s). While I think it's unlikely that would happen in this particular context, maybe it's worth running a strip_tags on the output just to be on the safe side.

[maccabeelevine]

Done

[demiankatz]

@maccabeelevine, I'm concerned that we may be losing as much as we gain here -- the old aria-label attributes explained what the checkboxes do, whereas the new attributes explain what record they are associated with. With either approach, we only seem to get half of the story, and maybe we need the whole thing. Not sure if that can be achieved without adding new translation strings, though. Also, as noted above, I think the work here may relate in some ways to #2999, which is going through some conversation to find the best solution for providing unique IDs to all checkboxes. Maybe we should put this on hold until that work is done in case we can leverage the results. What do you think?

[maccabeelevine]

the bigger question is whether it's okay to replace an action-oriented label with just a title. Do we need to combine the two, e.g. "Select %%title%% for renewal"? I realize that making that change would require a significant amount of retranslation work, so it's not ideal... but losing the action label entirely also seems less than ideal.

Personally I do not think the checkbox aria-label should say what the checkbox is for, like "Select %%title for renewal", since for many screens there are several actions you can do with the selected record(s). It would also be repetitive over each record. I do see there is a general translation string

select_item = "Select item for further action"

but IMHO the idea of "further action" is inherent in any checkbox of this kind (i.e. pertaining to a record). With just the title text in the aria-label, NVDA pronounces it as "%%title%% checkbox not checked" which seems the best solution.

That said I am probably wrong and @metageeky would know better.

Let me also draw your attention to #2999, which I believe is work in progress on code that's meant to be a foundation for solving this problem... but I think it's currently a bit stalled and needs more work.

It looks like #2999 has unstalled so I can wait for it to finish.

[demiankatz]

Good point regarding the possibility of multiple actions, @maccabeelevine. As you say, let's see what wisdom @metageeky can impart regarding best practices for this situation. :-)

[demiankatz]

@maccabeelevine, I'm taking the 10.0 milestone off this once since it doesn't seem to be moving quickly, and I'm not sure if we'll get it done in time for that release. Obviously, still happy to merge it if it's done in time -- I just don't want to make the slate of scheduled work for the release larger than necessary.

[demiankatz]

@maccabeelevine, now that #2999 is merged, do you have time to bring this up to date? Let me know if you need help and/or if you think it's best to move this to the 11.0 milestone, given that we only have a couple of weeks to make progress before 10.1 is due to be released.

[maccabeelevine]

@maccabeelevine, now that #2999 is merged, do you have time to bring this up to date? Let me know if you need help and/or if you think it's best to move this to the 11.0 milestone, given that we only have a couple of weeks to make progress before 10.1 is due to be released.

Ok, I've updated the code to use #2999. No real effect to behavior from what I had done earlier; when you tab to an unchecked checkbox, NVDA still says "%%title%% checkbox unchecked". Certainly cleaner code though.

So this is in line with my original approach -- that the item's title was more useful aria text than the purpose of the checkbox. You disagreed

I'm concerned that we may be losing as much as we gain here -- the old aria-label attributes explained what the checkboxes do, whereas the new attributes explain what record they are associated with. With either approach, we only seem to get half of the story, and maybe we need the whole thing. Not sure if that can be achieved without adding new translation strings, though.

and I pointed out that some checkboxes support multiple actions, but I don't know if that was a convincing argument. We could also take your suggestion of "the the whole thing" i.e. combining the action and the title, although we can't do that with aria-labelledby AFAIK so would have to return to the prior implementation of outputting the title, and edit the translation strings to include the title as a variable, which seems like we can't do at this stage for 10.1. Or we can wait for @metageeky's consult, but I believe her availability for that starts next fall after their FOLIO / VF migration is complete.

So really up to you whether you think this is an incremental improvement or not -- resolving the accessibility issue but perhaps with loss of functionality.

[maccabeelevine]

I don't see a clean way here to get the record driver, to pass to the Record view helper for getUniqueHtmlElementId. I could use $ilsDetails['item_id'] which in my testing is the same value, but I believe there are cases where that might not be. Alternately maybe I can use $safeId and generate the same value in account-entry.phtml, but I don't know if that adds any value.

If there is not a way to get getUniqueHtmlElementId here, then I should revert the changes to account-entry since they don't have any purpose.

[maccabeelevine]

And once we figure out this screen, I can apply the logic to the other account pages with checkboxes.
#3552 (comment)

[demiankatz]

In this template, I believe that $resource is the record driver. Does that help?

[maccabeelevine]

Yes, thanks! Got this page working with aria-labelledby as well now. Not to presuppose the final decision, but at least the approach is consistent now in this PR for the pages that the Moravian report originally cited.

[demiankatz]

Thanks, @maccabeelevine! I think there's a good chance we'll have to delay this to 11.0 because we need to build some consensus, and I'm not sure we'll get enough input in time. A few thoughts, though:

I know that @pasitiis is willing to offer accessibility advice, so maybe he can offer some input on best practices for labeling (e.g. action vs. title vs. hybrid).

It might be good to hear from @RLangeUni to see if this aligns (or conflicts) with his own planned usage of #2999 in follow-up code. He also added many of the action-oriented labels in #2982 and likely has an opinion on their removal.

And of course I'd love to hear from @metageeky if she has time to comment, but I understand if she doesn't. :-)

[pasitiis]

I quickly tested the PR with VoiceOver on results list. I would probably go with a hybrid (action label with a title). However, I still need to test more thoroughly before I can give my final opinion. In the hybrid option, I’d put the action label in the aria-label field and the title in the aria-describedby field.

I noticed during testing that the current sr-only field inside the label element causes issues with VoiceOver on both Chrome and Safari (the focus doesn't stay in the field correctly when navigating with VoiceOver keys). I would modify the structure by removing the sr-only field and placing its content in the input field's aria-label (probably requires some renaming of the action labels).

[metageeky]

I recommend this gets tabled for further discussion. While it is true that I would flag having repetitive labels on the checkboxes as a violation of WCAG 2.4.6 Headings and Labels, there are larger issues at play here worth considering.

With a screen reader, there are at least three ways a user could come across these checkboxes: tabbing to interactive items, reading line by line, and navigating by lists/list items. None of these is more privileged than the other, and I have seen plenty of individual preferences for what to use among screen reader users or search result pages.

I want to highlight how the experience is if you navigate by list items. This is from this results page using NVDA in Firefox for the result Patch testing and prick testing a practical guide official publication of the ICDRG

clickable Select item for further action check box not checked Select result number 5 5 Patch testing and prick testing a practical guide official publication of the ICDRG / graphic link Patch highlighted testing out of highlighted and prick highlighted testing out of highlighted a practical guide official publication of the ICDRG / link by Lachapelle, Jean-Marie, 1937- link heading level 2 Published 2012 Subjects: Find It graphic Online version link Online Book Preview graphic link Preview from Google Books Save to List link

I know this is a little complex to read, but the big thing I want to highlight is how the book title Patch testing and prick testing... is repeated twice. With the recommended fix, the full book title will now be repeated for a THIRD time. This level of repetition is not a violation of WCAG per se, but I do try to encourage usable accessibility instead of just accessibility conformance. There's also the annoyance of two links with almost the same link text (the first is the book cover, then the title) that go to the same place being right after each other.

The source of this problem is the DOM ordering that necessitates all this repetition. Even if you fix the label right now, a massive accessibility and usability improvement is possible on the search item structure itself.

[metageeky]

Also, it's worth noting that the title attribute is of mixed utility in accessibility. Screen readers are fairly divisive on if they will report the title if other accessible name sources are present. Moreover, the title attribute only appears to mouse users as hover text. Keyboard focus does not trigger the hover text.

[demiankatz]

Thanks for the input, @pasitiis and @metageeky! I'll push this forward to the 11.0 milestone so we have more time to work through this thoughtfully! :-)