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

RESOLVED FIXED in mozilla10

Status

()

defect
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

(Blocks 3 bugs, {access})

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

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Assignee

Description

9 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

9 years ago
Blocks: 559767
Assignee

Updated

9 years ago
Blocks: 559745
Assignee

Updated

9 years ago
Blocks: 559746
Assignee

Updated

9 years ago
Blocks: 559747
Assignee

Updated

9 years ago
Blocks: 559759
Assignee

Updated

9 years ago
Blocks: 559762

Comment 1

9 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.
Do you have a sample page I could look at to see what we currently do with this?
Posted file 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

8 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

8 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

8 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

8 years ago
Marco, it works for me on nightly too with NVDA 2011.1.1.
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

8 years ago
Posted patch patchSplinter Review
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)
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

8 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.
https://hg.mozilla.org/mozilla-central/rev/f1f69b249f45
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Assignee

Updated

8 years ago
Flags: in-testsuite+
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

8 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.
(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

8 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?
(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

8 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

8 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.