- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 14 Feb 2012 00:11:50 +0100
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: HTMLWG WG <public-html@w3.org>
Benjamin Hawkes-Lewis, Mon, 13 Feb 2012 21:12:11 +0000: > On Mon, Feb 13, 2012 at 1:32 PM, Leif Halvard Silli 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. Yes, they say that 'known' is important. In that regard: @longdesc is known. ARIA is new. W.r.t. 'richer semantics in XML': That's something they say between the lines. My point: That point applies to ARIA. >> why are we then trying to ARIA-fy everything related to HTML accessibility? > > We are not. Yes we are. We have a tendency to push for general, XML-based accessibility - ARIA - as opposed to native features. Jonas - and I am not quoting - has made the point that ARIA can be used for SVG too, for instance. And yes it can. > 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.) Which problems? >> 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. What I meant to ask or say was that we should not be so fast to think that native features can be replaced by general features. >> 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. ;) Exactly. -- leif h silli
Received on Monday, 13 February 2012 23:19:39 UTC