- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Mon, 13 Feb 2012 21:12:11 +0000
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: HTMLWG WG <public-html@w3.org>
On Mon, Feb 13, 2012 at 1:32 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > Norman Walsh & Robin Berjon (think this were the words of Robin) on > native HTML accessibility versus ARIA + CSS + XML, at XMLPrague last > week: [1] > > ]] 2.3. The Accessibility of XML > Theoretically, accessibility of XML should be at least as good, > perhaps better than HTML because the opportunity exists for expressing > richer semantics in the document. In practice, this is utterly wrong. > Had XML become widespread on the web, languages for mapping > accessibility onto XML documents could have been developed. Since it > didn't, they weren't and the result is that HTML documents have much > greater accessibility because so much is known in advance about the > semantics of the elements. > Perhaps ARIA and CSS would provide a framework for building some > accessibility into XML on the web, but it's not likely to be sufficient > for the more complex cases. > [[ > > If these words are true They seem fairly confused to me. They conflate whether a vocabulary is known to the user agent (critical) with whether it is expressed in HTML or XML (at a deep level, irrelevant). Their idea that you can express richer semantics in XML ignores efforts like microformats, microdata, and RDFa. > why are we then trying to ARIA-fy everything related to HTML accessibility? We are not. It's worth trying to specify how ARIA features work in text/html with implementation and deployment work for web compatibility reasons - that is, there is deployed content that depends on these features and there are user agents/AT that make use of them. I guess making HTML an ARIA host language looked like the easiest way to do that. (In practice this perhaps creates more problems than it solves.) > In particular, why remove native features? I think the motivating idea is to favour features that encourage authors to make content visible rather than hidden and the links/references between related bits of content are broken. It happens that @aria-describedby does that (other problems aside) and @longdesc and @summary do not. HTML5 also includes native features like <figcaption>, <caption>, and <details> that similar encourage the presentation of visible information with a semantic association to other content. > How can Jonas be right when he claims that it will be simpler > to be able to say "just use ARIA" as opposed to "use @longdesc for > <img> and @summary for table and …" ? If Jonas did claim that (you didn't give a citation), I guess it's an example of arguing that more generic techniques make for a more simple language. Not sure I buy it in this case. ;) -- Benjamin Hawkes-Lewis
Received on Monday, 13 February 2012 21:12:39 UTC