Aria-label gives a DAP violation for <option> tag in dropdown

0
votes

I am doing Accessibility testing for an Angular project at work. We use JAWS screen reader. We also use a plugin that identifies issues in the UI and reports them as violations. I am getting one for dropdowns that I'm not able to resolve. It is Accessible name does not match or contain the visible label text.

The code I have for the dropdown is:

<select *ngIf="!viewMode" formControlName="group" placeholder="select" id="group" data-placement="right">
    <option value="" [selected]>Select</option>
    <option attr.aria-label="{{group.title}}" *ngFor="let group of records" 
     [ngValue]="group" data-placement="right" data-toggle="tooltip" title="{{group.title}}">
         {{group.title | slice:0:30}}
         <span *ngIf="group.title.length > 30">...</span>
    </option>
</select>

We truncate the text of group.title and add ellipses ... if the entire title doesn't fit the fixed width of dropdown. The aria-label however always has the full title assigned.

Eg. if we have title as Psychology, maximum characters that we display are 6. Then dropdown will show Psycho... but the aria-label will stil be `Psychology.

My issue is that whenever the displayed title gets truncated I get a violation as title doesn't match the aria-label. If I remove the aria-label the screen reader only reads what is displayed, so it ends up reading the ellipses as dot dot dot which we don't want. I tried to use a hidden label instead on aria-label inside the option tag but that didn't work. Can anyone help me with a workaround??

1
htmlangulartypescriptaccessibilityjaws-screen-reader
short of building a custom select comprising entirely of divs and aria (BAD idea) there is very little you can do here, <selects> are basic components that convert anything within <option> into plain text. Also <option> does not work with aria-label as far as I am aware, very surprised that title appears to work, but is not really appropriate. Best advice, just leave the ... - it is understood by screen reader users to be a truncated sentence the same as everyone else and if "sighted" users dont need the whole info neither do users who rely on a screen reader. – Graham Ritchie
After rereading your question and noticing at what point you truncate (mid word), best accessibility advice would be redesign your form so you do not have to truncate. It isn't just screen readers it is also people with cognitive impairments who may not be able to make the association between "psycho...." and "psychology". Use a simple <select>, don't truncate at all, redesign the form to allow all text to be visible. – Graham Ritchie
@GrahamRitchie Whether or not the title is truncated, the full title is shown in a tooltip, on hover. Every UI format, even the way dropdown data is displayed is also UX approved so probably won't change. At least not immediately :( I guess I'll remove the labels for now and see if it is fine – Amruta
<select>d are hard to do much with I am afraid. If you are able to persuade them it is important for usability that the form itself is redesigned to reduce the need for truncating that is your best route as I said, plus it is waaaay easier to get something like that approved than trying to get a stylistic change approved i would have thought! Sorry to be the bringer of bad news but I have had similar conversations about <select> and visually hidden text / labels in the past, form redesign was always the way we went due to the limitations. – Graham Ritchie
WCAG SC 2.5.3 (presumably the relevant criterion here) is intended to allow speech-based input devices to refer to controls by their name, as in the utterance "click cancel". While it is recommended that the accessible name and the visible label match where possible, the w3 docs say "In many (but not all) cases, the label and the name are the same." (emphasis mine) ...and... "best practice is to have the text of the label at the start of the name.". So they can differ without violating this SC, if you are careful, but Graham's suggestion is better. – brennanyoung

1 Answers

0
votes

Ideal answer

You shouldn't have to manually truncate labels, because that's a pure visual artifact to cop with insufficient space.

CSS should ideally be able to handle this case for you automatically, so that you would just write the full label and don't care at all.

The CSS to do that exists. The property is called text-overflow with the value èllipsis`. Example here

However, very often, and even in recent browsers, CSS support for <option> is very limited and incomplete. IN some browsers, you are even not allowed to change text color. So, applying text-overflow: ellipsis certainly won't work, sadly. IN a ideal world this would be by far the best solution.

Second best answer

You shouldn't have to manually truncate labels. If it can't be done automatically for you in CSS in case you lack space, the next best would probably be to reorganize your layout to make sure you have enough space to see entirely the longest label.

You may have a different aria-label than visible text, but generally it isn't recommanded. Hance the warning of your accessibility checker to remind it to you.

It isn't recommanded because several groups of people can have difficulties. For example, partially sighted people or those having dyslexia, who rely both on visible text and speech synthesis, will read the abbreviation but hear the full tex. It can be very confusing.

Third answer

If you really can't rearrange your layout to make all labels visible in full text, ignore the warning, leave the full text in aria-label and the shortened text visible as it is currently. There are problems for several groups of people, well, but it isn't so bad afterall. It would probably be much worse for accessibility if you decided to switch your <select< for a custom component.

So I would still strongly advice you to keep your <select> whatever the situation. Blind people and keyboard only users will thank you.

However, always remember that warnings are never present for nothing. They point you to a potential problem you'd better to solve. This is definitly not a false positive!