This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The aria-autocomplete attribute applies only to elements whose role is textbox. So, it provides additional information to the assistive technology as to how the autocomplete would work that HTML 5 does not. If we were to follow the non-normative table of input elements that support autocomplete it would appear that it would apply to HTML 5 elements that are capable of supplying a text input value. This would include the following input types: (text, search, telephone, URL, e-mail, password, datetime, date, month, week, time, datetime-local, number, color, range). The list attribute on an input element is a suggestion to the user agent to use the list provided. It can in fact be ignored by the user agent. Since the browser has the ability to ignore the HTML 5 autocomplete and list content attributes, per the spec., we cannot force the browser to enforce its autocomplete mechanism based on aria-autocomplete. Following the same convention, we suggest that the browser treat aria-autocomplete as an author request to what the browser uses to fill in the listed input elements in HTML 5. For custom controls not created from HTML 5 input elements which convey the appropriately defined semantics without ARIA, and for which the browser is not designed to perform the autocomplete, we recommend that the author MUST provide the aria-autocomplete properties where the custom control's functionality matches the autocomplete functionality defined by the WAI-ARIA specification. The HTML 5 specification indicates that autocomplete only takes an on/off value. It also indicates that autocomplete applies to the form element and the input element, yet a non-normative table is included that indicates autocomplete applies to only certain input controls. Clarification of this is needed in the HTML 5 spec.
The stated purpose of ARIA is to only affect how browsers expose stuff to accessibility APIs. Making browsers do other things based on ARIA would be contrary to the purpose of ARIA. As I read http://www.w3.org/TR/wai-aria/states_and_properties#aria-autocomplete the purpose of aria-autocomplete is to tell AT that there is a non-native autocompletion mechanism implemented in JavaScript in place. The purpose isn't to invoke browser-native autocompletion.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The request seems to be based on a misunderstanding of the purpose of ARIA, as described in comment 1. I would recommend rephrasing this request as a problem statement, explaining it is that needs fixing, rather than saying what the fix should be. In general it's very hard to evaluate proposals without knowing what the problem is. In this particular instance, for example, it's very much unclear what the problem is: what is it that is inaccessible? What kind of Web pages would exhibit this problem? Sample markup showing the problem would be useful; even better would be examples of real Web pages demonstrating the problem. HTH.
(In reply to comment #2) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: The request seems to be based on a misunderstanding of the purpose > of ARIA, as described in comment 1. > > I would recommend rephrasing this request as a problem statement, explaining it > is that needs fixing, rather than saying what the fix should be. In general > it's very hard to evaluate proposals without knowing what the problem is. In > this particular instance, for example, it's very much unclear what the problem > is: what is it that is inaccessible? What kind of Web pages would exhibit this > problem? Sample markup showing the problem would be useful; even better would > be examples of real Web pages demonstrating the problem. > > HTH. to put this in context: This bug was raised in response to your enquiry: "How should I integrate "aria-autocomplete" with the various autocompletion mechanisms in HTML5, specifically list="" on <input>, autocomplete="" on <form> and various controls, and UA-specific behaviour on all editable controls?" http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html your response at the time was: "Please file a bug on any HTML5 issues so that I can track them separately. Thanks." http://www.w3.org/WAI/PF/Group/comments/update?comment_id=289 HTH
(In reply to comment #3)> "How should I integrate "aria-autocomplete" with the various autocompletion > mechanisms in HTML5, specifically list="" on <input>, autocomplete="" on > <form> and various controls, and UA-specific behaviour on all editable > controls?"AFAICT, aria-autocomplete shouldn't be integrated with them. However, it might make sense to expose the autocompleting nature of autocomplete="" and list="" to AT independently of aria-autocomplete. (Though this raises the question: What should be exposed if the native autocompletion features are used but there's also aria-autocomplete=none.)
(In reply to comment #4) > (In reply to comment #3)> "How should I integrate "aria-autocomplete" with the > various autocompletion > mechanisms in HTML5, specifically list="" on <input>, > autocomplete="" on > <form> and various controls, and UA-specific behaviour on > all editable > controls?"AFAICT, aria-autocomplete shouldn't be integrated with > them. However, it might make sense to expose the autocompleting nature of > autocomplete="" and list="" to AT independently of aria-autocomplete. (Though > this raises the question: What should be exposed if the native autocompletion > features are used but there's also aria-autocomplete=none.) henri wrote > them. However, it might make sense to expose the autocompleting nature of > autocomplete="" and list="" to AT I agree, wherever native HTML5 features have accessibility API mappings they should be exposed. For IA2 expose Object attribute autocomplete A2_STATE_SUPPORTS_AUTOCOMPLETION http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_states_8idl.html#afecbfb195aaf7050dc8f75a7833bd5faad7825464a6f27e9f42f11104ce2ae7 For ATK expose Object attribute autocomplete ATK_STATE_SUPPORTS_AUTOCOMPLETION http://library.gnome.org/devel/atk/unstable/atk-AtkState.html
The bug-triage sub-team thinks this is important, but does not require the attention of the whole task force as the ARIA mapping sub-team is able to deal with it and take the appropriate steps.