- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Fri, 5 Feb 2016 19:09:37 +0000
- To: Rich Schwerdtfeger <richschwer@gmail.com>, Matt King <a11ythinker@gmail.com>
- CC: ARIA Working Group <public-aria@w3.org>
- Message-ID: <SN1PR0301MB19818F8CD02D8AD1ED018EFA98D20@SN1PR0301MB1981.namprd03.prod.outlook.>
As requested during the meeting as well, I wish to elaborate on the need for adding an attribute for setting a Value property in the accessibility tree. Below are two examples that show why this discrepancy is important. Here is an example of a Combobox control on a standard input element, which if you examine the Name in the accessibility tree, you will see that the Name reflects the aria-label attribute value according to the naming calculation, and the Value property reflects the value of the input field. <input aria-label="Search for author" name="author-input-value" role="combobox" aria-expanded="false" aria-autocomplete="list" type="text" value="Bill Bryson" /> Now, do the same using the following example of a simulated readonly Combobox as pasted below, and you will see that the Name is set correctly in the accessibility tree, but there is no evidence of a Value in the accessibility tree, nor is there any way to assign one. <span tabindex="0" aria-label="Choose language" class="button" role="combobox" aria-expanded="false" aria-activedescendant="" aria-autocomplete="list" aria-readonly="true"> <span id="langChild">English</span> <sup id="arrowSymbolId" aria-hidden="true">?</sup> </span> Both are valid, however the second is not possible to fully map correctly in the accessibility tree. This is why I propose adding aria-valuetext as a supported attribute for role="combobox". From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] Sent: Friday, February 05, 2016 10:53 AM To: Matt King <a11ythinker@gmail.com> Cc: ARIA Working Group <public-aria@w3.org> Subject: Re: ACTION-1490 Updated combobox branch based on Feb 4 ARIA caucus discussion Thank you Matt. This is better. I am running these by Freedom Scientific. One observation is that you have added a reference to the ARIA authoring practices guide in a number of places. This is a non-normative spec. for which we have linked to and it can change. Would it not be better to put a more global reference to it in the ARIA specification? I am sure there are other places where we could reference the ARIA authoring practices and do not. Rich Rich Schwerdtfeger On Feb 4, 2016, at 6:11 PM, Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote: Based on today's lively discussion, I have revised my proposal for action 1490[1], which is in branch mck-action1490[2]. The revisions include: 1. Remove implicit value of aria-orientation for combobox. 2. Remove combobox note about XForms. 3. Change combobox aria-autocomplete authoring requirements to state that aria-autocomplete be set to either "both" if autocomplete is provided in the textbox or "list" if it is not. 4. Restored token values for aria-autocomplete and clarified their definitions. As previously described, the objectives of action 1490 are: 1. Allow combobox to popup grid, tree, and dialog in addition to listbox. 2. Allow aria-controls instead of aria-owns so the pop-up is not a child of the single line text input. This enables screen readers to include a rendering of the pop-up outside of the text input in their reading view or buffer. 3. Remove ambiguities from the spec to improve understanding and simplify authoring. 4. Do it all without breaking any existing implementations. Note: the changes included in action 1490 have little or no effect on browser implementations and require only minor adjustments in the logic of some screen readers to support the aria-controls relationship when processing the escape key. The changes in the mck-action1490 branch (as compared to master) are: 1. Reworded the combobox definition. 2. Added normative statement saying the popup must be one of listbox, tree, grid, or dialog. 3. Added normative MUST statement requiring authors to associate the input with the pop-up. 4. Specified that authors SHOULD use aria-controls but MAY use aria-owns to specify the relationship between the input and the popup. 5. Added normative author MUST statement requiring correct use of aria-expanded. 6. Reworded and simplify the focus management language. 7. Eliminated confusing language about aria-autocomplete and specified that authors SHOULD use either "both" if the text input provides suggestions or "list" if it does not. 8. Updated the example code to match the new authoring requirements. 9. Added a reference to the APG. 10. Changed the superclass to input. 11. Remove the required owned elements. 12. Clarified the value definitions for aria-autocomplete. [1] Action 1490: https://www.w3.org/WAI/aria/track/actions/1490 [2] mck-action1490 branch: http://rawgit.com/w3c/aria/mck-action1490/aria/aria.html
Received on Friday, 5 February 2016 19:10:15 UTC