Summary: | AX: Let ARIA override the value of an input type=range | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||
Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | bdakin, cfleizach, dmazzoni, jcraig, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | BlinkMergeCandidate, InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Ryosuke Niwa
2013-09-09 17:10:23 PDT
James, does this idea look accurate to you No, it's a bad patch. Only aria-valuetext should be used on range. The other attrs are identical semantically to the aria attrs (e.g. @max vs @aria-valuemax, and @value vs @aria-valuenow) so the host language attrs should win. From the ARIA spec: http://www.w3.org/WAI/PF/aria/complete#host_general_conflict "When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic." Thanks for correcting me. I misinterpreted the spec. I think the aria-valuetext part of the patch is still good - it wasn't working on an input type=range previously. I'll revert the rest. (In reply to comment #4) > I think the aria-valuetext part of the patch is still good - it wasn't working on an input type=range previously. Are you sure? I demoed this working in a WWDC 2011 presentation. Are you saying it regressed or that it didn't look like it was working at all? Created attachment 223479 [details]
test case
Attaching working test case and closing. If you have a test case that does not work, please reopen. |