Closed
Bug 681674
Opened 13 years ago
Closed 13 years ago
aria-autocomplete not supported on standard form text input controls
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
mozilla9
People
(Reporter: kloots, Assigned: davidb)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
4.16 KB,
patch
|
tbsaunde
:
review+
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603
Steps to reproduce:
I added the aria-autocomplete attribute to a standard HTML form text input control (tried both <input type="text"> and <textarea>).
Actual results:
When I focused the control, the NVDA screen reader did not announce the text box as having autocomplete.
Here's a link to an example to reproduce the bug:
http://public.yahoo.com/kloots/aria/autocomplete-2.html
Expected results:
The NVDA screen reader should have announced the text box has having autocomplete.
One additional note: I discovered adding the ARIA role of "textbox" to the input fixes the issue. But that ARIA role seems redundant in this case.
Assignee | ||
Updated•13 years ago
|
Component: General → Disability Access APIs
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → accessibility-apis
Hardware: x86 → All
Assignee | ||
Comment 1•13 years ago
|
||
Looks like we have ApplyARIAState in nsXULFormControlAccessible but not in nsHTMLFormControlAccessible?
Trev, Alex are you guys currently refactoring nsHTML* or nsHypertext*?
Assignee | ||
Comment 2•13 years ago
|
||
Trivial really - we just need to do what we do for xul text fields. This would all have worked automagically if aria-autocomplete was a universal property, but it isn't so we special case for native html and xul text fields.
Assignee: nobody → bolterbugz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #555494 -
Flags: review?(trev.saunders)
Assignee | ||
Comment 3•13 years ago
|
||
Comment on attachment 555494 [details] [diff] [review]
patch 1
Adding r? Marco since Trevor is supposed to be relaxing :)
Attachment #555494 -
Flags: review?(marco.zehe)
Comment 4•13 years ago
|
||
Comment on attachment 555494 [details] [diff] [review]
patch 1
>+nsHTMLTextFieldAccessible::ApplyARIAState(PRUint64* aState)
>+{
>+ nsHyperTextAccessibleWrap::ApplyARIAState(aState);
>+
>+ nsStateMapEntry::MapToStates(mContent, aState, eARIAAutoComplete);
>+
>+}
I'd probably kill that last blank line.
Also, duplicating this logic sort of sucks, but the only reasonable approach I can think of here is a helper text field class for both the xul and html ones to dirive from.
>+ testStates("htmltext_autocomplete_list", STATE_HASPOPUP, EXT_STATE_SUPPORTS_AUTOCOMPLETION);
>+ testStates("htmltextarea_autocomplete_list", STATE_HASPOPUP, EXT_STATE_SUPPORTS_AUTOCOMPLETION);
I'd like to be sure we cover the other possible cases here, but I'll leave the decision if we need more tests up to Marco
also, add bug link?
Attachment #555494 -
Flags: review?(trev.saunders) → review+
Assignee | ||
Comment 5•13 years ago
|
||
(In reply to Trevor Saunders (:tbsaunde) from comment #4)
> Also, duplicating this logic sort of sucks
Agreed.
Comment 6•13 years ago
|
||
regression from bug 499653. Note, comboboxes are affected too (though I'm not sure it makes sense for non ARIA comboboxes, needs to dig through history deeply).
I don't like the virtual ApplyARIAState approach (though it's better than it was prior bug 499653). ARIA map should be extended to catch ARIA roles for native roles and that will be correct fix.
Blocks: 499653
Comment 7•13 years ago
|
||
But you can go ahead and land it since the patch doesn't make things more worth than they were.
Blocks: aria
Comment 8•13 years ago
|
||
Comment on attachment 555494 [details] [diff] [review]
patch 1
Please add a link to this bug in the proper section of /accessible/tests/mochitest/states/test_aria.html. r=me with that fixed. Thanks!
Attachment #555494 -
Flags: review?(marco.zehe) → review+
Assignee | ||
Comment 9•13 years ago
|
||
(In reply to alexander surkov from comment #7)
> But you can go ahead and land it since the patch doesn't make things more
> worth than they were.
Alright. Do we have a bug for the right fix?
Comment 10•13 years ago
|
||
(In reply to David Bolter [:davidb] from comment #9)
> (In reply to alexander surkov from comment #7)
> > But you can go ahead and land it since the patch doesn't make things more
> > worth than they were.
>
> Alright. Do we have a bug for the right fix?
yep, bug 499892
Assignee | ||
Comment 11•13 years ago
|
||
Comment 12•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in
before you can comment on or make changes to this bug.
Description
•