add accessibility support for @list on HTML input and for HTML datalist

RESOLVED FIXED in mozilla10

Status

()

Core
Disability Access APIs
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

(Blocks: 3 bugs, {access})

unspecified
mozilla10
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

7 years ago
@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.
(Assignee)

Updated

7 years ago
Blocks: 559767
(Assignee)

Updated

7 years ago
Blocks: 559745
(Assignee)

Updated

7 years ago
Blocks: 559746
(Assignee)

Updated

7 years ago
Blocks: 559747
(Assignee)

Updated

7 years ago
Blocks: 559759
(Assignee)

Updated

7 years ago
Blocks: 559762

Comment 1

7 years ago
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-/
Any progress on this? list/datalist is available in Firefox since a few months now.

Comment 3

6 years ago
Do you have a sample page I could look at to see what we currently do with this?
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).
(Assignee)

Comment 5

6 years ago
(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

6 years ago
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).
(Assignee)

Comment 7

6 years ago
(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?
(Assignee)

Comment 8

6 years ago
Marco, it works for me on nightly too with NVDA 2011.1.1.

Comment 9

6 years ago
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.
(Assignee)

Comment 10

6 years ago
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
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #565152 - Flags: review?(marco.zehe)
(Assignee)

Comment 11

6 years ago
try build http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/surkov.alexander@gmail.com-c8c5061dc516
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?
Attachment #565152 - Flags: review?(marco.zehe) → review+
(Assignee)

Comment 13

6 years ago
(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.
(Assignee)

Comment 14

6 years ago
inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/f1f69b249f45
https://hg.mozilla.org/mozilla-central/rev/f1f69b249f45
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
(Assignee)

Updated

6 years ago
Flags: in-testsuite+

Comment 16

6 years ago
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.
(Assignee)

Comment 17

6 years ago
(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

6 years ago
(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.
(Assignee)

Comment 19

6 years ago
(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

6 years ago
(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.
(Assignee)

Comment 21

6 years ago
(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.
(Assignee)

Comment 22

6 years ago
I filed bug 693509 for the popup issue.
You need to log in before you can comment on or make changes to this bug.