Last Comment Bug 559766 - add accessibility support for @list on HTML input and for HTML datalist
: add accessibility support for @list on HTML input and for HTML datalist
Status: RESOLVED FIXED
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: unspecified
: All All
: -- normal with 2 votes (vote)
: mozilla10
Assigned To: alexander :surkov
:
Mentors:
Depends on: 555840 556007
Blocks: html5a11y 559762 559767 559745 559746 559747 559759
  Show dependency treegraph
 
Reported: 2010-04-15 23:45 PDT by alexander :surkov
Modified: 2011-10-10 18:24 PDT (History)
9 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Example (395 bytes, text/html)
2011-10-05 06:28 PDT, Mounir Lamouri (:mounir)
no flags Details
patch (9.22 KB, patch)
2011-10-06 01:01 PDT, alexander :surkov
mzehe: review+
Details | Diff | Splinter Review

Description alexander :surkov 2010-04-15 23:45:03 PDT
@list attribute defines a list of options associated with HTML input element (the list of input types supporting @list attribute is http://dev.w3.org/html5/spec/forms.html#attr-input-type). Note it's used by Search (bug 559747),  URL (bug 559745),  Telephone (bug 559746), E-mail (bug 559759) as well so that their autocomplete stuffs should be covered by this bug.
Comment 1 Holger Jeromin 2011-01-31 04:29:48 PST
The user needs an hint, that there is an datalist.
Now (ff4 beta 10) he does not even gets an visual hint if he clickes into the form to focus the input. A second click is needed... 8-/
Comment 2 Mounir Lamouri (:mounir) 2011-10-05 05:04:13 PDT
Any progress on this? list/datalist is available in Firefox since a few months now.
Comment 3 Marco Zehe (:MarcoZ) 2011-10-05 05:35:42 PDT
Do you have a sample page I could look at to see what we currently do with this?
Comment 4 Mounir Lamouri (:mounir) 2011-10-05 06:28:52 PDT
Created attachment 564815 [details]
Example

The textbox in this file should have some suggested values (Paris, San Francisco, Toronto, Vancouver, Berlin, London and Mountain View). They should be proposed to you a way or another. I guess the same way the autocomplete values are proposed (I'm assuming a11y is managing this).
Comment 5 alexander :surkov 2011-10-05 08:05:21 PDT
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #2)
> Any progress on this? list/datalist is available in Firefox since a few
> months now.

I missed the content part was implemented. Example looks ok. Probably all we want is to add mochitest for it.
Comment 6 Holger Jeromin 2011-10-05 08:46:55 PDT
The datalist still (as of FF7.0.1/Win7) has the problem, that there is no visual clue and two clicks are needed for the dropdown box (see comment #2).
Comment 7 alexander :surkov 2011-10-05 20:32:05 PDT
(In reply to Holger Jeromin from comment #6)
> The datalist still (as of FF7.0.1/Win7) has the problem, that there is no
> visual clue and two clicks are needed for the dropdown box (see comment #2).

it's not about screen reader support so not part of this bug.

Mounir, is it known issues?
Comment 8 alexander :surkov 2011-10-05 21:43:28 PDT
Marco, it works for me on nightly too with NVDA 2011.1.1.
Comment 9 Marco Zehe (:MarcoZ) 2011-10-05 22:05:51 PDT
It definitely does not work for me with NVDA 2011.2 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111005 Firefox/10.0a1. I open the test case, press Tab once to focus the edit field. NVDA goes into focus mode automatically. I either then arrow up and down, and speech only says "blank", or I type Pa for Paris, and hit down arrow once or twice, but NVDA will only say "Pa", nothing else, and it also won't autocomplete anything. Win7 x64, Firefox 32 bit.
Comment 10 alexander :surkov 2011-10-06 01:01:10 PDT
Created attachment 565152 [details] [diff] [review]
patch

make sure autocomplete state exposed on input having @list attribute, add tests for this kind of autocomplete tests.

btw, nightly works for me with NVDA2011.2 too
Comment 12 Marco Zehe (:MarcoZ) 2011-10-06 07:09:37 PDT
Comment on attachment 565152 [details] [diff] [review]
patch

r=me for the patch, which is in principle correct. However even with the try build and the example from this bug, I do not get the autocomplete to work at all with NVDA 2011.2 still.

One question: Do we want to add some kind of tree test for this kind of autocomplete, too? To make sure we expose these items somehow?
Comment 13 alexander :surkov 2011-10-06 19:37:55 PDT
(In reply to Marco Zehe (:MarcoZ) from comment #12)
> Comment on attachment 565152 [details] [diff] [review] [diff] [details] [review]
> patch
> 
> r=me for the patch, which is in principle correct. However even with the try
> build and the example from this bug, I do not get the autocomplete to work
> at all with NVDA 2011.2 still.

Marco, could you file follow up for this issue?

> One question: Do we want to add some kind of tree test for this kind of
> autocomplete, too? To make sure we expose these items somehow?

That'd be great. Let's add them as we go.
Comment 14 alexander :surkov 2011-10-06 23:06:22 PDT
inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/f1f69b249f45
Comment 15 Matt Brubeck (:mbrubeck) 2011-10-07 12:49:01 PDT
https://hg.mozilla.org/mozilla-central/rev/f1f69b249f45
Comment 16 James Teh [:Jamie] 2011-10-07 23:12:55 PDT
Out of curiosity, what does this patch do? The autocomplete state is exposed for me in the attached test case even without this patch. Also, I can get the autocomplete menu to come up using down arrow twice. I'm not sure why I have to press it twice, but that's true for other Firefox autocompletes as well.
Comment 17 alexander :surkov 2011-10-07 23:24:01 PDT
(In reply to James Teh [:Jamie] from comment #16)
> Out of curiosity, what does this patch do? The autocomplete state is exposed
> for me in the attached test case even without this patch.

This patch makes sure we handle cases like
<input autocomplete="off" list="datalist">

> Also, I can get
> the autocomplete menu to come up using down arrow twice. I'm not sure why I
> have to press it twice, but that's true for other Firefox autocompletes as
> well.

If you're in the end of text and no selection then single down arrow works. If it doesn't then it should consequence how screen reader affects on Firefox. At least I don't have another guess.
Comment 18 James Teh [:Jamie] 2011-10-07 23:28:07 PDT
(In reply to alexander surkov from comment #17)
> This patch makes sure we handle cases like
> <input autocomplete="off" list="datalist">
Ah. Understood. Thanks.

> If you're in the end of text and no selection then single down arrow works.
> If it doesn't then it should consequence how screen reader affects on
> Firefox.
NVDA doesn't bind the arrow keys at all while in focus mode. I double checked this using pass key through. The first press of down arrow after focusing in the field still has no effect for me.
Comment 19 alexander :surkov 2011-10-07 23:35:17 PDT
(In reply to James Teh [:Jamie] from comment #18)
> (In reply to alexander surkov from comment #17)
> > This patch makes sure we handle cases like
> > <input autocomplete="off" list="datalist">
> Ah. Understood. Thanks.

yeah, some crazy examples :) to process them correct.

> > If you're in the end of text and no selection then single down arrow works.
> > If it doesn't then it should consequence how screen reader affects on
> > Firefox.
> NVDA doesn't bind the arrow keys at all while in focus mode. I double
> checked this using pass key through. The first press of down arrow after
> focusing in the field still has no effect for me.

You don't mean twice down arrow before NVDA says something, right? i.e. first down arrow open popup, second down arrow selects first item?
Comment 20 James Teh [:Jamie] 2011-10-09 20:48:52 PDT
(In reply to alexander surkov from comment #19)
> You don't mean twice down arrow before NVDA says something, right? i.e.
> first down arrow open popup, second down arrow selects first item?
Ah. So that's what's happening. If this is the case, the autocomplete list should probably gain focus on the first press of down/up arrow to make it clear that keyboard focus has moved there. This would make the experience similar to context menus.
Comment 21 alexander :surkov 2011-10-10 17:32:53 PDT
(In reply to James Teh [:Jamie] from comment #20)
> (In reply to alexander surkov from comment #19)
> > You don't mean twice down arrow before NVDA says something, right? i.e.
> > first down arrow open popup, second down arrow selects first item?
> Ah. So that's what's happening. If this is the case, the autocomplete list
> should probably gain focus on the first press of down/up arrow to make it
> clear that keyboard focus has moved there. This would make the experience
> similar to context menus.

context menus don't take a focus but they are subject of menupopup_start/end events which are supposedly processed by you. That's the difference I can see between autocomplete list and context menu. On the another hand autocompletes are closer to comboboxes which aren't subject of menupopup_start/end events. Maybe they should be.
Comment 22 alexander :surkov 2011-10-10 18:24:00 PDT
I filed bug 693509 for the popup issue.

Note You need to log in before you can comment on or make changes to this bug.