- From: James Craig <jcraig@apple.com>
- Date: Fri, 23 Nov 2012 16:46:32 -0800
- To: Adam Solomon <adam.solomon2@gmail.com>
- Cc: wai-xtech@w3.org, James Nurthen <james.nurthen@oracle.com>
- Message-id: <885037B4-9961-45C1-ACD5-8D7D254B68FE@apple.com>
On Nov 19, 2012, at 11:33 AM, Adam Solomon <adam.solomon2@gmail.com> wrote: > Regarding the aria textbox role - is there an attribute which would reveal the value of the textbox to assistive technology as required by SC 4.1.2? That is to say, when an HTML input is used then the value of that input is determinable by AT. However, if a custom control is made using non-interactive elements, and using the aria textbox role, how would the value be determined? The same question would apply for the combobox widget. The value of the widget might very well be implicitly determined by the value of the html input associated with that widget. There is some direction on this regarding the combobox role, as the determinable value depends on the autocomplete setting. If an author sets a combobox's value of aria-autocomplete to 'none' (default), authors MUST manage and set focus on the associated listbox, so assistive technologies can follow the currently selected value. If an author sets a combobox's value of aria-autocomplete to 'inline' or 'both', authors MUST update the value of the focused textfield, so assistive technologies can announce the currently selected value. If an author sets a combobox's value of aria-autocomplete to 'list', user agents MUST expose changes to the aria-activedescendant attribute on the combobox while the combobox remains focused. If a change to the aria-activedescendant attribute occurs while the combobox is focused, assistive technologies SHOULD alert the user of that change, for example, by speaking the text alternative of the new active descendant element. Authors SHOULD associate the combobox textfield with its listbox using aria-owns. http://www.w3.org/WAI/PF/aria/complete#combobox As for the textbox role, the spec could probably be a bit more clear regarding label versus value. nameFrom is limited to "author" which leaves the value to be determined from contents, since as you noticed, the "aria-valuenow" attributes is not allowed on an element with this role. There is this note that implies to always use the native one textfield when possible: The intended use is for languages that do not have a text input element, or cases in which an element with different semantics is repurposed as a text field. http://www.w3.org/WAI/PF/aria/complete#textbox > But, is there an aria-based attribute for this determination, especially in a case where an html input is not used in the widget? No. That said, we could probably extend aria-valuenow (in 1.1 or 2.0) to all form element roles as an explicit override if you think it's necessary. In either case, we can probably add an informative note (in 1.0) that since the label is declared by author and not contents, the value of non-native textboxes is determined by the node contents. This does not take into account other aspects of rich text editing (like determining and controlling selection) which have all been deferred to ARIA 2.0. James
Received on Saturday, 24 November 2012 00:47:05 UTC