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

Re: why are we pursuing this idea? (was: Implementation Details request on Issue 204 Decision)

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 21 Aug 2012 17:59:06 +0200
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, John Foliot <john@foliot.ca>, Maciej Stachowiak <mjs@apple.com>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20120821175906198360.9d760f3e@xn--mlform-iua.no>
Benjamin Hawkes-Lewis, Tue, 21 Aug 2012 15:40:33 +0100:

If I get your point, then you again want to discuss what authors are 
likely to think. On one side you say:
 
> A key rationale for exposing @hidden content via @aria-describedby is
> that naive authors will expect such content to be exposed whatever the
> specs and linters say.

And on another side:
 
> @aria-describedby can be used to reference rich content.
> 
> Nobody has given any reason to believe that naive authors won't expect
> rich content to be exposed whatever the specs and linters say. Do you
> have any reason to believe this?
> 
> (Note: I've provided some evidence that naive authors will expect even
> simple content *not* to be exposed if hidden.)

Comment: It seems safe to assume that that authors will become 
surprised: 

1. Some will be surprised that <p hidden id=description> gets
   presented to users despite the hidden attribute.
2. Others will be surprised (if they learn it at all) that
   VoiceOver currently flattens *any* aria-describedby
   referred content. 

With regard to the last point, then the issue that ATs flattens all 
content referred to via @aria-foo, is one of the issues we have 
struggled with within the working group when we have discussed 
@longdesc versus @aria-describedby. E.g. it was for instance at one 
point surprising for me to learn that when one points to a link with an 
@aria-* attribute, then only to gets its textual content back, and 
nothing more. Thus: The link feature is lost. And this when the element 
is visible! 

I must honestly say, however, that it, on the surface, seems illogical 
to assume that there ought - or can - be a difference with regard to 
"flattening" depending on whether the content is hidden or visible. 
Thus, I don't believe that authors will find it very surprising that 
hidden content can be rendered as "rich" content to AT users. On the 
contrary, I think that authors would expect to be able to use ARIA to 
draw those kind of links.

Thus: Regardless of whether a link is visible or hidden, the simplest 
thing would be if one could assume that pointing to it with 
aria-describedby, would mean that the AT users got to take part in the 
link feature - and not only of the text feature. So this is the 
evidence I have: Myself. And our debates of these issues in the HTML WG.

However, one thing: The way Firefox now reveals a aria-describedby 
referenced link as a long description link, cannot really be described 
as "rich" rendering of the link. Rather, it is special rendering of a 
kind of microformat. Because, after all, Firefox adds its own, generic 
longdesc announcement text to the link. (The 'built-in' text is instead 
treated as belonging to the image.) Whether that exact behavior is one 
that authors would expect, could perhaps be debated. It makes sense. 
But it makes even more sense if you know the @longdesc background ... 
To which degree e.g. Firefox "unflattens"*other* content than hidden 
links, is not clear to me.
-- 
leif halvard silli
Received on Tuesday, 21 August 2012 15:59:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 August 2012 15:59:40 GMT