Re: aria-describedat

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote on 03/21/2012
10:50:09 AM:

> From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cc: W3C WAI-XTECH <wai-xtech@w3.org>, w3c-wai-pf@w3.org, public-
> html-a11y@w3.org, laura.lee.carlson@gmail.com, George Kerscher
> <kerscher@montana.com>, david.bolter@gmail.com, jbrewer@w3.org,
> faulkner.steve@gmail.com, mike@w3.org
> Date: 03/21/2012 10:52 AM
> Subject: 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.
>
I agree that is dreadful but that sounds more like providing better
authoring guidance. We can put that in the authoring practices for ARIA
1.1.

> 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.
>

We could. Ultimately, examples will go into the authoring practices guide.

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

> 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.
>
I think a problem with using fallback content is that it is obscured. A
browser, that brings up the fallback fragment would show it hidden unless
we provided separate requirements which are a SHOULD at this time vs. a
MUST. I think we either do this or we require the authors to point to
content that is visible to all users.

> 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?
>
We need to discuss this with user agent manufacturers. Fallback content is
not always in a "render ready" state.

> 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
>