This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
You can label marks on a "input type='range'" by using the list attribute to point to a list of suggestions which may have labels ("label" attribute). These labels should be exposed to underlying accessibility APIs. http://dev.w3.org/html5/spec/number-state.html#range-state http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute This note might help for the Apple API: http://lists.apple.com/archives/Accessibility-dev/2006/Apr/msg00004.html See also discussion in Bug 10988.
The question I have is when will the text of these labels be made available? When the control is range control first gets focus? Or as the range indicator moves to the value that has an associated label?
(In reply to comment #1) > The question I have is when will the text of these labels be made available? > > When the control is range control first gets focus? Or as the range indicator > moves to the value that has an associated label? I think this is up to individual consumers of the accessibility APIs. A bit like HTML5 itself, they expose semantics and functionality; they do not dictate the user interface client software presents on top of said semantics and functionality. For instance, in UI Automation I guess the list should be exposed as a series of ListItem instances inside the range API with the labels mapped to the names of those items. Each list item is a IValueProvider but so is the Slider control as a whole: Slider control: http://msdn.microsoft.com/en-us/library/ee671644(VS.85).aspx ListItem control: http://msdn.microsoft.com/en-us/library/ee671635(v=VS.85).aspx IValueProvider interface: http://msdn.microsoft.com/en-us/library/ee671565(v=VS.85).aspx UI Automation does not appear to constrain the order in which this information is presented to the user.
(In reply to comment #0) > You can label marks on a "input type='range'" by using the list attribute to > point to a list of suggestions which may have labels ("label" attribute). These > labels should be exposed to underlying accessibility APIs. > > http://dev.w3.org/html5/spec/number-state.html#range-state > http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute > > This note might help for the Apple API: > > http://lists.apple.com/archives/Accessibility-dev/2006/Apr/msg00004.html > > See also discussion in Bug 10988. This seems to be exposed simply by default. That is, a consumer reading the page can follow the @list attribute and read the labels. Was there some additional specific structure that should be exposed? Is there a precedent for talking about Accessiblity API-specific data structures?
(In reply to comment #3) > (In reply to comment #0) > > You can label marks on a "input type='range'" by using the list attribute to > > point to a list of suggestions which may have labels ("label" attribute). These > > labels should be exposed to underlying accessibility APIs. [snip] > This seems to be exposed simply by default. That is, a consumer reading the > page can follow the @list attribute and read the labels. I'm not sure I follow. The semantics are indeed defined by HTML. However, the purpose of mapping HTML semantics to platform accessibility APIs is to avoid platform accessibility API clients having to become direct DOM consumers to provide user interfaces on top of those semantics. So the fact that the semantics are extractable with direct DOM access does not reduce the utility of documenting how to map the extracted semantics to accessibility APIs. > Was there some additional specific structure that should be exposed? Is there a precedent for > talking about Accessiblity API-specific data structures? I don't understand what you're talking about. Do the Apple Accessibility API and UI Automation examples above constitute the sort of precedents you're looking for?
(In reply to comment #4) > However, the purpose of mapping HTML semantics to platform accessibility APIs > is to avoid platform accessibility API clients having to become direct DOM > consumers to provide user interfaces on top of those semantics. > > So the fact that the semantics are extractable with direct DOM access does not > reduce the utility of documenting how to map the extracted semantics to > accessibility APIs. Ah, okay. Different definitions of "extractable". ^_^ > > Was there some additional specific structure that should be exposed? Is there a precedent for > > talking about Accessiblity API-specific data structures? > > I don't understand what you're talking about. Do the Apple Accessibility API > and UI Automation examples above constitute the sort of precedents you're > looking for? Not quite. What I meant was, are there precedents for HTML5 to define exactly how features map into some accessibility APIs, beyond straightforward cases like ARIA?
(In reply to comment #5) > Not quite. What I meant was, are there precedents for HTML5 to define exactly > how features map into some accessibility APIs, beyond straightforward cases > like ARIA? Sorry, I still don't understand. The document against which this bug is filed seems full of such precedents? http://dev.w3.org/html5/html-api-map/overview.html Can you explain how what I'm asking for is different to other items in that document?
(In reply to comment #6) > (In reply to comment #5) > > Not quite. What I meant was, are there precedents for HTML5 to define exactly > > how features map into some accessibility APIs, beyond straightforward cases > > like ARIA? > > Sorry, I still don't understand. The document against which this bug is filed > seems full of such precedents? > > http://dev.w3.org/html5/html-api-map/overview.html > > Can you explain how what I'm asking for is different to other items in that > document? ...Argh, I'm sorry. I completely didn't register that this bug was filed against a different document than the HTML5 spec. Disregard my noise. >_<