[Bug 10988] add slider element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10988

--- Comment #18 from Shelley Powers <shelleyp@burningbird.net> 2010-10-10 15:06:21 UTC ---
(In reply to comment #17)
> (In reply to comment #9)
> > However, the datalist options don't print out, as a rendered label.
> > 
> > And there's nothing in the rendering that suggests this should happen.
> 
> "The user agent may use the suggestion's label to identify the suggestion if
> appropriate."
> 
> http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute
> 
> > And how would the tick marks/labels map from an accessibility perspective?
> > Right now, all that's mapped is role, value, min, and max.
> 
> I don't see any concept of tick marks in ARIA.

Hopefully an accessibility expert will correct me if I'm wrong, by tick marks
themselves are a visual aid. The actual value should be read out for screen
readers. 

Labels, though, are a different story. I'm assuming if a specific value in the
range is given a label, it is the label that should be spoken, not the value. 

Currently, though, I don't see that there is a true mapping between the values
given in the list/datalist and the actual range value.

> 
> The proposed Note mapping HTML5 semantics to native accessibility APIs should
> cover the mapping of native sliders, including option labels.
> 
> http://dev.w3.org/html5/html-api-map/overview.html
> 

Well, yes and no. It maps out the input type of range without the associated
list/datalist. And the reference to the datalist in the mapping document is
specific to something selectable, and that strikes me is not the equivalent
behavior in this specific use case.


> Submitted to the editors of that draft as Bug 11003.
> 
> (In reply to comment #13)
> > currently the display of ticmarks is left up to the option of the
> > browser.
> > I would like to make tic marks the option of the author.
> 
> HTML5 defines conformance requirements for what semantics a user agent can
> extract from what bytes, not what user interface it chooses to place on top of
> those semantics.
> 
> I believe that's the correct approach, personally, but feel free to challenge
> it. I recommend doing so on a mailing list or a dedicated bug rather than in a
> narrow bug like this, since it would be a significant and deeply controversial
> shift of approach.
> 
> I'd hope it would be uncontroversial for the spec to include an example of a
> suggestion list with labels being used with input type="range", however.
> 
> I've opened a request for such an example as Bug 11004.
> 

Yes, noticed that. Thank you.

> (In reply to comment #16)
> > whether that [orientation] is done through
> > an existing css3 property (which I previously saw, don't know if it still
> > exists), or whether it is specified through attributes, I think this
> > needs to be done also.
> 
> Orientation should be specified with CSS. Please submit such feedback to CSS
> WG, rather than in a bug on the HTML spec.
>

I do agree that orientation should be CSS. Actual rendering of tick marks could
also be CSS. 

> Note that WebKit have already added CSS for making native-look sliders
> horizontal or vertical:
> 
> http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/css/property/-webkit-appearance

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Sunday, 10 October 2010 15:06:23 UTC