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

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