[a11y] - provide an accessible name to interactive combobox element

[LukeLeber]

trafficstars

When a user accesses the country combobox directly, there is no indication that they're interacting with a phone number input. They're simply told that they can select a country. In order to provide enough context so that the country selection element makes sense on its own, we should add an aria-label to the interactive element.

Expected behaviour

A/T announces:

Telephone country code combo box <the selected country, plus [country code] >

Actual behaviour

A/T announces:

<the selected country, plus [country code] combo box>

The difference is that A/T will announce that the selected country is for a "Telephone country code". Please feel free to bikeshed the exact verbiage to be used, but we should definitely add the additional context.

Please let me know what you think, if this plan sounds good, then I'm more than happy to open a pull request. Thanks so much for your consideration!

[bradallenfisher]

yes this would be a huge enhancement!

[mgifford]

Would be nice to have this. Can you bring it over to a JSFiddle file or something based on https://intl-tel-input.com/ so we can see it in action?

We might need to hide the image and provide an aria-label.

[fuzzbomb]

I don't think aria-label is the most flexible or inclusive approach here.

The problem with aria-label is that it it's invisible, and only conveys the input purpose to (some) assistive technology users.

It's preferable to have visible labels, which can help sighted users too (whether they use assistive technology or not).

I'd recommend using aria-labelledby instead of aria-label. There's a bit of extra overhead due to having to manage (and/or generate) some ID references, but the end result is more flexible and robust. It gives designers the option of using visible or invisible labels, or something more elaborate (e.g. tooltips), and will still work for assistive tech even if the label is hidden using display: none CSS.

[LukeLeber]

https://jsfiddle.net/lleber/5ocmykjL/ should be a good enough monkey-patch to evaluate.

Currently the webform module passes {nationalMode: false} in as a configuration option. i.e.

const input = document.querySelector('#tel');
intlTelInput(input, {nationalMode: false});

I don't think that affects the scope of this particular issue though.

[fuzzbomb]

Terminology clarification: in WCAG, "label" refers to the visible name of a control. Neither aria-label nor aria-labelledby provide that. In the screenshot on this project's README, there is no visible label.

This bug report is really about the lack of a programatically-determinable accessible name for the country-code control. The aria-label, aria-labelledby, or HTML <label for="foo"> can all provide an accessible name.

The accessible name is required for WCAG success criterion 4.1.2 "Name, role, value".

In the expected behaviour provided by Luke:

• "Telephone country code" is the accessible name.
• "combobox" is the accessible role
• "<the selected country, plus country code>" is the accessible value.

Note, assistive technology may convey the name, role, and value in any order; possibly based on user preferences. WCAG SC 4.1.2 just requires that they are machine readable.

The accessible name doesn't have to be identical to a visible label (if present), but considered together they need to satisfy WCAG success criterion 2.5.3 "label in name". My preference for aria-labelledby over aria-label is informed by this. I've seen far more failures of SC 2.5.3 where aria-label differed from visible text, than when aria-labelledby was used.

ARIA attributes are not the only possible solutions here. Consider a HTML <label> element, and see the First rule of ARIA use.

[mryand]

Anyone know why this PR is still open with no response? I'd hope that an a11y fix would get fast-tracked, as many users of this library have legal accessibility requirements they need to meet.

[jackocnr]

Hi guys, I can only apologise for the delay in getting to this - I've had other life stuff getting in the way. First, I'd like to thank you all for the effort that has gone into this research, discussion, and resulting PR. But having read through it all, I actually prefer @LukeLeber's original suggestion of simply adding an aria-label. This solves the existing a11y issue as I understand it, and it does so with a single line. The alternative approach, as per the PR, adds 13 lines, and AFAICT, it's just in case one day someone decides they want to have this new (inner) label be visible, which would never make sense to me. I always imagined devs would just add their own labels in their forms as per normal, e.g. above the input or whatever. Do let me know if I've completely misunderstood, but as things stand, @LukeLeber I would welcome a PR to add the aria-label as you suggest.

EDIT: I understand this discussion/work was done a year ago, and so Luke if you've moved on and don't have time for this anymore that's also fine I can add the label myself, based on your suggestion.

[LukeLeber]

Hi @jackocnr,

I think that organizationally, we've decided to prioritize this enhancement for our forms lower than originally intended (not entirely due to this issue!).

I had questions about how autocomplete might impact some international users and advised that we undergo user testing, and run A/B experimentation before rolling something like this out to our global audience. We're moving toward implementing a back-end validation strategy for normalizing user input, and may re-evaluate this library in the future depending on a number of factors (mostly outside of my control).

I had gone so far as providing https://www.drupal.org/project/webform_intl_tel_national_mode in preparation for rolling this out, which patches in an accessible label via Javascript. Drupal based enterprises / organizations that have a more stringent set of accessibility requirements to meet can freely use this module to work around this issue, but I do still think that a fix in this library is due.

As far as providing a PR, I don't have any hours to allocate to this nowadays, but that might change if/when my employers re prioritize projects.

Cheers

[jackocnr]

Thanks for the update Luke. I've just pushed this change (new version release coming soon), so I'll close this issue/PR for now. Thanks again.