W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: ISSUE-30: Native HTML vs ARIA/XML

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Mon, 13 Feb 2012 21:12:11 +0000
Message-ID: <CAEhSh3eRJ6_4h69hajv68iRQuTZ1mWYt8N133VQSFXBFz7cJXw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:44 GMT