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)

6 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla9

People

(Reporter: kloots, Assigned: davidb)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.
Component: General → Disability Access APIs
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → accessibility-apis
Hardware: x86 → All
Looks like we have ApplyARIAState in nsXULFormControlAccessible but not in nsHTMLFormControlAccessible? Trev, Alex are you guys currently refactoring nsHTML* or nsHypertext*?
Attached patch patch 1Splinter Review
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)
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 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+
(In reply to Trevor Saunders (:tbsaunde) from comment #4) > Also, duplicating this logic sort of sucks Agreed.
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
But you can go ahead and land it since the patch doesn't make things more worth than they were.
Blocks: aria
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+
(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?
(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
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.

Attachment

General

Created:
Updated:
Size: