Add detailed status information to the badge for screen readers.

[pasitiis]

Currently, the screen reader only reads the status as a number, not what the number relates to.

[demiankatz]

@pasitiis, is it possible that using an aria-label attribute in parallel with the title attributes on these elements might be more appropriate than embedding hidden text inside the elements? Semantically, it seems to me potentially more clear to treat the text as a label than to effectively concatenate it with the element contents, which may lead to strange results depending on word order in different languages.

What do you think? I'm certainly open to this approach if you feel differently, but my first reaction is that labels might be cleaner.

[pasitiis]

@demiankatz It's possible to use, and it's better to use aria-label in this context. I switched to aria-label.

[demiankatz]

Thanks, @pasitiis, I think this is a step in the right direction... but I still am concerned about including the actual values in the aria-label attributes. Is this necessary? If the aria-label is a label for the content of the element, is it necessary to repeat the contents of the element as part of the label? I would think this would cause redundant text to be read out. For example, if I have 5 items due, isn't it going to say "5 Items due later: 5" when the result that would make more sense would be "Items due later: 5"?

[pasitiis]

@demiankatz At least VoiceOver prioritizes aria-label over the visible content when both are present. So, VoiceOver only announces the content in the aria-label (e.g. 5 items due) . However, I also noticed that aria-label cannot be applied to a span element (for example, the JAWS screen reader does not read the aria-label at all with that structure). I will explore other methods.

[demiankatz]

Thanks, @pasitiis -- it's never as simple as one wishes!

In any case, whatever approach you find, my main concern is that we try to treat this as a label-value pair rather than a sentence so we can avoid the need to construct new translation strings to handle order differences between languages. The existing translations are designed as labels, not sentence fragments.

[pasitiis]

I couldn't find another solution than creating a separate field for screen readers. Using aria-labels and similar methods isn't possible in this structure (aria-label only works with interactive element elements). Changing the status fields to be focusable (interactive ) would make navigating the menu slightly difficult for screen reader users.

Screen readers now read the content as follows: "Holds and Recalls Available for Pickup: 4, In Transit: 1,". Previously, it was read like this: "Holds and Recalls 4 3." I used commas at the end to improve the rhythm of the text for the screen reader.

If someone comes up with an alternative method, I’d be interested to hear it. I tested this with VoiceOver, NVDA, and JAWS.

Additionally, I had to adjust the flex because Firefox, for some reason, read the status information in reverse order in VoiceOver.

[demiankatz]

Thanks, @pasitiis! This looks like an improvement to me, but I'm going to wait and see if we can collect a few more opinions before I merge it, just in case there are any further ideas out there.

[ThoWagen]

Would it make sense to create a ViewHelper for this? Maybe this can be reused in other cases and it would be easier to change this if we find a better solution in the future.

[demiankatz]

Would it make sense to create a ViewHelper for this? Maybe this can be reused in other cases and it would be easier to change this if we find a better solution in the future.

This code is taking place in Javascript, not PHP, so I don't think a ViewHelper is feasible... but creating a support function to build each element might be a good idea to reduce repetition and simplify future adjustments, as you say!

[ThoWagen]

Ah, I have missed that. But yes, a support function would be nice instead.

[demiankatz]

Thanks, @crhallberg. I'll wait and see if @pasitiis wants to create a support method as @ThoWagen suggested before I merge this.

[pasitiis]

@demiankatz I can try to create a support function for this. It will probably be the end of the week or next before I can continue this.

[demiankatz]

Thanks, @pasitiis, there is no rush! :-)