- From: <bugzilla@jessica.w3.org>
- Date: Wed, 15 Dec 2010 19:22:57 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11557 --- Comment #7 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2010-12-15 19:22:56 UTC --- (In reply to comment #3) > This isn't arbitrary XML, though. It's one of the most widely-used document > formats in the world. If an AT doesn't understand HTML well enough to > automatically know that an <option> in a <select> is a role=option, then it's > useless for almost the entirety of the web, as very few sites use any ARIA at > all, and those that do usually only use a smattering for actual accessibility > "fix up", not accessibility redundancy. It's not at all that simple since: 1. Some HTML5 features are new. 2. The interaction of ARIA annotations and native semantics is new. An author might well be working around a failure of the UA to treat the default role as if it were present for the purpose of such interactions with annotations on other elements in the same document. 3. HTML could be served mixed in with arbitrary XML. What happens (in practice I mean, rather than theory) to ARIA and HTML semantics respectively in that scenario? If you can provide documentary proof for a given annotation and native expression that the annotation has no effect in any UA other than to add an attribute to the DOM - i.e. that it's genuinely rather than theoretically redundant - then I don't have a strong objection to making the combination of the two non-conforming. I feel proving this would require an unrealistic amount of testing since the set of UAs making use of ARIA is already large (multiple versions, multiple browsers/browser addons, multiple AT). I would object in the strongest possible terms to some sort of untested, blanket ban that would affect annotations applied to enable new HTML features like "details" and "required" to be used without compromising accessibility in today's UAs. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 15 December 2010 19:22:59 UTC