Re: aria-describedat

On 12-03-21 10:32 AM, Richard Schwerdtfeger wrote:
> 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.
> Cheers,
> Rich
> Rich Schwerdtfeger


A nit at the end of this sentence:

 > If the element containing the aria-describedat attribute is visible 
the user
 > agent SHOULD render an indication to the user, in context of the element
 > containing the aria-describedat attribute, that additional 
information may be
 > referenced.

Replace the "may be referenced" with "is referenced".  I don't 
understand the hedge -- if there is a well-formed aria-describedat, then 
it references other content.  There is no "may" about it, since the 
draft says that the "... attribute value MUST be a valid non-empty URL ...".

And, an overall comment:  there is nothing explicit about how the 
description is rendered, although it implies something where it says 
that user agents "... SHOULD provide a device independent mechanism to 
close the rendered content and return the user's point of regard ...".  
That the content can be closed implies that it can be opened.  How?  
Some possibilities are:

1. Another window is opened to show the description, even when it is an 
in-document fragment.  Here, "closing" means closing that window.

2. The description is rendered inline near the "expand" indicator.  
"Closing" here means collapsing.

3. In the case of a in-document content anchor, the contents are 
scrolled to the description.  Here, "closing" means scrolling back.

Or, are all three user experiences possible?  That is, is the 
specification neutral with respect to how the user agent reacts to an 
invocation of the description?



'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -

Received on Wednesday, 21 March 2012 21:11:29 UTC