Re: aria-describedat

Very glad to see this. Thanks for sharing with us. Feedback: 

FIRSTLY: In the example code, please change the following URLs,
   aria-describedat="http://example.com"
   aria-describedat="http://example.com#description"

into for example the following ones:

   aria-describedat="http://example.com/page"
   aria-describedat="http://example.com/page#description"

Justification: There are enough of dumb and useless instances of 
@longdesc where the URL points to a top level domain that obviously 
does not contain any description. 

SECONDLY: Why not use the same element - <img> or <canvas> - in all 
examples? Then you can demonstrate different ways to present the long 
description: 1. An entire separate page. 2. A specific element on 
another page. 3. A specific element on the same page. Justification: It 
is often simpler to discover patterns and differences, if the same 
element is used - and seen - from different angles.

THIRDLY: It would be good to clarify that when the URL points to a 
specific fragment, then that fragment - alone - is the long description.

FOURTH: Fallback questions: The URL in the canvas example points to an 
element in the canvas element' fallback. Could the same method be used 
for pointing to the fallback of an <object> element also? And why not 
let the URL point to the canvas element itself rather than to a child 
element in the fallback? And does the element her serve as something 
that explicitly tells the AT/UA to reveal the fallback? Would it not 
use the fallback without the URL? If it would use it anyhow even 
without the URL, why include the URL? I know that screenreaders have 
problems with reading the fallback of <object> - they often don't read 
it, and to work around this, one can e.g. use aria-describedBY to point 
to the fallback. So is this the reason why you have this URL - to 
workaround screen reader issues? Or, perhaps screen readers should 
behave this way: You should still explain why it is necessary to do 
this in order to make the screenreader read the fallback.

FIFT: What when the URL points to fallback? I understand that AT the - 
probably - can access it. But what about other users? It seems useless 
if the URL points to fallback that one cannot access. And that is also 
a problem that impacts on what this spec's SHOULD language with regard 
to revealing the URL to users UAs that does not reveal the ARIA 
annotations to the user. Or perhaps it is the fallback's 
'revealability' we need to change?

Leif H Silli


Richard Schwerdtfeger, Wed, 21 Mar 2012 09:32:13 -0500:
> This is an unofficial draft of aria-describedat that Steve and I are 
> working on for ARIA 1.1. Mike, thanks for putting setting us up with 
> a work page.
> 
> http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/describedat.html
> 
> Cheers,
> Rich
> 
> Rich Schwerdtfeger

Received on Wednesday, 21 March 2012 15:50:55 UTC