ISSUE-627: Naming confusion between aria-autocomplete and HTML5 autocomplete.
ARIA and native semantics conflict.
Naming confusion between aria-autocomplete and HTML5 autocomplete.
- State:
- CLOSED
- Product:
- ARIA 1.1 Authoring Practices
- Raised by:
- Joseph Scheuhammer
- Opened on:
- 2013-10-25
- Description:
- This came up with regard to test case 17:
https://www.w3.org/WAI/PF/testharness/testcases/edit?testsuite_id=3&testcase_id=17
The situation involves a DHTML combobox with aria-autocomplete="none", meaning the combobox does not support autocompletion.
The test file uses the follwing markup:
<input type='text' role='combobox' aria-autocomplete='none' ...>.
FF exposes IA2_STATE_SUPPORTS_AUTOCOMPLETION on Windows, and
SUPPORTS_AUTOCOMPLETION on ATK/AT-SPI, contrary to what would be expected based on the aria-autocomplete value of "none".
Under HTML5, <input> elements have an implied autocomplete attribute [1]. When not specified, FF sets the value of autocomplete to "true", and exposes that in the AAPI as "supports autocompletion" [2].
A similar situation would arise for role spinbutton where the author has used a text input element (usually to get keyboard access for free). Role spinbutton does not support aria-autocomplete, and yet the spinbutton would be marked in IA2 and AT-SPI as supporting autocompletion. It may also pop-up a list of completions when viewed in the browser, which is a somwewhat odd user experience for spinbuttons.
This amounts to a conflict between an ARIA property and a native property, and raises the question as to which property wins when an ARIA role is used that supports, or does not support, autocompletion.
Note: as of this writing, the HTML5 autocomplete attribute is marked "at risk" [3].
Additional comment from Matt King:
Since there is implied autocomplete on html 5 text input, if building a combobox with JS and ARIA, in order to suppress the browser's automatic suggestions for the input, you need to write something like:
<input role="combobox" type="text" autocomplete="off" aria-autocomplete="list">
In this case, we need the browser to respect the html 5 autocomplete setting of off but let the ARIA property win in the a11y tree.
[1] http://www.w3.org/html/wg/drafts/html/master/forms.html#autofilling-form-controls:-the-autocomplete-attribute
[2] http://lists.w3.org/Archives/Public/public-pfwg/2013Oct/0041.html
[3] http://www.w3.org/html/wg/tests-cr-exit.html - Related Actions Items:
- No related actions
- Related emails:
- No related emails
Related notes:
Example of a spinbutton where FF exposes "supports autocompletion":
https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/accessible-name-input/checkbox-label-embedded-spinbutton.html
Example of a spinbutton where FF exposes "supports autocompletion":
https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/accessible-name-input/checkbox-label-embedded-spinbutton.html
No longer considered a Core-AAM issue. Changing the product to the APG.
https://github.com/w3c/aria-practices/issues/639
James Nurthen, 10 Apr 2018, 22:23:54Display change log