1409084 - implementation of input with datalist differs from HTML Acc API spec

Status: RESOLVED FIXED

(Core :: Disability Access APIs, enhancement, P5)

Description

[steve faulkner]

The HTML Accessibility API spec defines the role of an input with an associated datalist as combobox https://w3c.github.io/html-aam/#details-id-75 Firefox unlike chrome does not expose it as a combobox. This appears to cause problems in JAWS at least. refer to https://github.com/FreedomScientific/VFO-standards-support/issues/11

Suggest following the spec and aligning with chrome would be an improvement.

Comment 1

[alexander :surkov (:asurkov)]

HTML input is exposed with SUPPORTS_AUTOCOMPLETION and HAS_POPUP states. Thumb up to keep impls in sync, just curious if those states is not sufficient mapping.

Comment 2

[Marco Zehe (:MarcoZ)]

In addition, a combobox in Windows terms is something other than an Editcombo, as JAWS calls it. A combobox is equivalent to select size="1", and I don't think they want that for an input where you can also enter text.

Comment 3

[steve faulkner]

If you don't think the HTML accessibility API spec is correct in mapping it to a combobox suggest a bug be filed on the spec. From a non SR users perspective the current chrome implementation appears more usable than the current firefox implementation. if you read the details of the original issue https://github.com/FreedomScientific/VFO-standards-support/issues/11 you will get an idea of the difficulties with Firefox+JAWS currently.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to steve faulkner from comment #3)
> If you don't think the HTML accessibility API spec is correct in mapping it
> to a combobox suggest a bug be filed on the spec.

I didn't want to question the spec for correctness actually :) I'm just sort of surprised that combobox role is so crucial for JAWS.

I would make an educated guess that there could some eventing or relation problems preventing Firefox to work properly.

Marco, what is your thinking on this? I bet we have bunch of examples, where autocompletes work without being a comboboxes.

Comment 5

[Marco Zehe (:MarcoZ)]

Well, autocompletes in and out it self are pretty non-uniform. Like each autocomplete is a different beast, like on Slack, on Twitter, etc. So I don't have a good answer on this. We should look at what Chrome exposes and what our tree looks like, and maybe adjust. Jamie, what do you think?

Comment 6

[James Teh [:Jamie]]

If the spec guidance on ARIA autocompletes and datalist was consistent and covered all use cases, we should obviously just follow it as closely as possible. Unfortunately, this is simply not the case, and we are left with a huge mess of different autocomplete implementations, most of which suffer from one flaw or another. (I realise datalist is not an ARIA autocomplete, but the concepts are closely related.)

The HTML AAM is definitely wrong in one respect. It is not sufficient to map this to a role of combobox alone. At the very least, it should be role combobox with the editable state, and in fact, that's exactly what Chrome does. Without the editable state, this would be equivalent to a <select size="1">, which does not allow the user to cursor through or edit the value.

As to whether combobox is appropriate, I don't really care that much. However, there are two things worth noting:
1. aria-autocomplete is permitted on role="textbox". So, arguably, the editable text role is not inappropriate.
2. If JAWS runs into problems with Firefox's implementation of datalist, I suspect it will also run into problems for role="tetbox" with aria-autocomplete.

All of that said, I think Firefox has far bigger problems with datalist accessibility now. I can't even get focus to the datalist options with NVDA in current nightly. If I press down arrow, focus stays in the text box, but pressing enter changes the value, so I know I interacted with the list. The referenced GitHub issue suggests this at least sort of worked in 56, but now it doesn't work at all.

Comment 7

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #6)

All of that said, I think Firefox has far bigger problems with datalist
accessibility now. I can't even get focus to the datalist options with NVDA
in current nightly.

That was fixed in bug 1566299.

Comment 8

[James Teh [:Jamie]]

Attachment: Bug 1409084: Map inputs with a list attribute to role EDITCOMBOBOX.

Previously, we mapped these to ENTRY.
This is incorrect according to the HTML AAM spec and causes problems for JAWS.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/46aa9dd6e711
Map inputs with a list attribute to role EDITCOMBOBOX. r=eeejay

Comment 10

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/46aa9dd6e711