- From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
- Date: Mon, 28 Oct 2019 22:21:22 +0000
- To: Sebastian Silbermann <silbermann.sebastian@gmail.com>, "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <BYAPR03MB48053D90822C35F165264EAEF2660@BYAPR03MB4805.namprd03.prod.outlook.com>
Hi, My apologies for the delay, it’s been hectic. It looks like step 2D is misleading, and is meant to handle elements like images that do support such labelling mechanisms, but this step is not meant to handle embedded widget controls that have value properties. Only the subsequent step is meant to refer to that. If you could please do me a favor and submit this as a bug against the current spec on GitHub, I’ll add this to my queue for 1.2 for clarification. Regarding the combobox, the guidance for this control is somewhat vague by necessity, because you can implement a combobox as a focusable span tag, which has to specify an associated value in a different manner than when it is applied as a native form field like an input with type=”text” that supports a value attribute for setting a value property. So the naming algorithm has to be flexible enough to recognize when there is an assigned value property for that control, however that is applied, and then that value is used as the returned name for current node when processing the child nodes of the root node. Unfortunately, as the ARIA spec is currently written, the aria-valuetext attribute is not supported on the combobox role, even though I proposed that this be added years ago. As a result, there is no spec approved manner for setting the value of a simulated combobox that does not consist of a native form field that supports a native value property. E.G The following syntax is impossible to set a valid value property upon: <span tabindex=”0” role=”combobox” aria-expanded=”false”>Choose Language</span> Which should be possible to explicitly assign a value to, like so: <span tabindex=”0” role=”combobox” aria-expanded=”false” aria-valuetext=”English” >Choose Language</span> But you can’t, because this isn’t allowed. It doesn’t make any sense to me either… 😊 From: Sebastian Silbermann <silbermann.sebastian@gmail.com> Sent: Tuesday, October 22, 2019 11:38 PM To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; public-aria@w3.org Subject: Re: Accessible name computation and web-platform-tests CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks for the response Bryan. Ok I understand the which step is used but in the algorithm step 2D comes before 2E. In 2D we check for a title attribute, no? Where is it specified that we don't use the title if the current node is not the root node? Or is it actually step 2D and we prioritize the value attribute over the title attribute? If so where is this order specified? And last but not least: The element is a combobox. Where is it specified that the chose option is the value attribute? The sentence explicitly links to the option role not a section that specifies how to compute the chosen option of a combobox. Thank you for your time. I appreciate it that someone assists me understanding this! Am Di., 22. Okt. 2019 um 00:43 Uhr schrieb Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>: Hi, Actually this has to do with the difference between the ‘root node’ and the ‘current node’, where, for widget controls, only the value is returned when the root node is not the same as the current node. In this case, the root node is the heading, and that is where it stays during the computation. In contrast, the current node is recursively moved into the child nodes within the heading to compute the accessible name for the root node. If this were a different test, such as testing the accessible name only on the combobox, then the title attribute would be used because both the root node and the current node are the same element, and the value property is not a valid labelling mechanism for a widget control. However, since the root node and the current node don’t match, and the current node is a widget with a value, then it returns the name based on the AccName step 2E, where it states: “■ If the embedded control has role combobox or listbox, return the text alternative of the chosen option.” https://www.w3.org/TR/accname-1.1/ Since the accessible name for the combobox is already returned using its value, the title attribute is ignored. Hopefully this makes sense. All the best, Bryan Bryan Garaventa Principal Accessibility Architect Level Access, Inc. Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com> 415.624.2709 (o) www.LevelAccess.com<http://www.LevelAccess.com> From: Sebastian Silbermann <silbermann.sebastian@gmail.com<mailto:silbermann.sebastian@gmail.com>> Sent: Friday, October 18, 2019 4:59 AM To: public-aria@w3.org<mailto:public-aria@w3.org> Subject: Accessible name computation and web-platform-tests CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, I'm currently implementing the accessible name computation for HTML elements following https://w3c.github.io/accname/ and comparing the results with https://github.com/web-platform-tests/wpt/tree/574af55b103d2e732efa72af2719121f96db38f3/accname. There's currently one test case that confuses me: <h2> Country of origin: <input role="combobox" type="text" title="Choose your country." value="United States"> </h2> from https://github.com/web-platform-tests/wpt/blob/574af55b103d2e732efa72af2719121f96db38f3/accname/name_heading-combobox-focusable-alternative-manual.html The test expects the accessible name for the h2 element to be "Country of origin: United States". However, I'm not sure which path in https://w3c.github.io/accname/#mapping_additional_nd_te is taken to arrive at this computation as I arrive at "Countr of origin: Choose your country". From my understanding we use 2F since h2 allows name from content and then we concetanate the text node and the accessible name of the input. However for the input I would use 2D which isn't defined in this document as far as I can tell. So I looked into https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element and there it says I should use the `title`. There's no mention of using the `value` attribute. What I could see is 2E being used for the input (combobox) and then the `value` being considered as the selected option. I would appreciate it if somebody could clarify this. So far the documents have been very clear to me. Kind regards, Sebastian
Received on Monday, 28 October 2019 22:21:29 UTC