This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11003 - Map input type="range" suggestion labels to accessibility APIs
Summary: Map input type="range" suggestion labels to accessibility APIs
Status: NEW
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y APIs (editor: Steve Faulkner, Cynthia Shelly) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML a11y API spec bugbot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-10 09:55 UTC by Benjamin Hawkes-Lewis
Modified: 2012-04-18 11:36 UTC (History)
5 users (show)

See Also:


Attachments

Description Benjamin Hawkes-Lewis 2010-10-10 09:55:31 UTC
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.
Comment 1 Shelley Powers 2010-10-10 16:47:58 UTC
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?
Comment 2 Benjamin Hawkes-Lewis 2010-10-10 17:42:05 UTC
(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.
Comment 3 Tab Atkins Jr. 2010-10-10 22:57:43 UTC
(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?
Comment 4 Benjamin Hawkes-Lewis 2010-10-10 23:20:18 UTC
(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?
Comment 5 Tab Atkins Jr. 2010-10-10 23:34:40 UTC
(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?
Comment 6 Benjamin Hawkes-Lewis 2010-10-11 06:04:56 UTC
(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?
Comment 7 Tab Atkins Jr. 2010-10-11 15:50:44 UTC
(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.  >_<