Re: ISSUE-30 longdesc - Chairs Solicit Alternate Proposals or Counter-Proposals

On Tue, Jun 14, 2011 at 7:08 PM, Janina Sajka <janina@rednote.net> wrote:
> Dear jonas:
>
> Jonas Sicking writes:
>> I'd like to write a counter proposal. The proposal would request that
>> the spec specifically points out that the ARIA spec already requires
>> that aria-describedby can point to rich content, including <a>-links.
>> The proposal would further make pointing aria attributes (including
>> aria-describedby) to elements that are "hidden" using the @hidden
>> attribute legal.
>>
>> I should have time to write such a proposal before June 25th.
>>
>
> On behalf of the Text Subteam of the HTML-A11Y Task Force,
>
> We believe an ARIA approach for providing long text descriptions of
> images will necessarily fall short on several key requirements today.
> Therefore, we will be reading your CP with particular interest regarding
> how you adress the following three specific requirements which are of
> particular concern to us:
>
> 1.)     Backward Compatibility
>
>        We believe it is important to support users with older
>        technologies in this feature. The CP we backed does this, and we
>        are keenly concerned that the approach adopted for HTML 5 do
>        so as well.
>
>        http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
>        http://lists.w3.org/Archives/Public/public-html/2011May/0170.html

I'm not sure I understand what you mean by this requirement. Note that
HTML5 already has the same requirements on user agents as HTML4 with
regards to longdesc. I do not propose to change that, nor have I heard
anyone proposing to change that ever as long as HTML5 has been
discussed. So any behavior that users see today will remain once user
agents implement HTML5.

> 2.)     Display content only upon user request
>
>        A key behavioral requirement for this feature is that the
>        content of the long text description is displayed/voiced ONLY
>        when the user requests it. In other words users need to know
>        that a longer textual description is available, and they need to
>        be able to easily request that content be presented to them--or
>        not. In no instance, however, should such content be
>        automatically displayed, as alt text is automatically displayed.
>        This behavioral distinction is one key distinction between the
>        required short and long text description mechanisms as described
>        by WAI at:
>
>        http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html

This requirement seems very poorly phrased. Surely you don't want long
descriptions to always be hidden from the user unless explicitly
requested? Consider for example the page http://apod.nasa.gov/apod/ .
For people not using AT, the description is always displayed below the
image. Similarly, today, users which use AT will have this description
read to them as part of the normal page flow.

Are you saying that this page should be authored differently such that
AT users in this case should see a mostly blank page with just an
image for which they could request a description if they wanted it? If
so, how does longdesc solve this requirement? The existence of
longdesc clearly didn't prevent the above site from providing a
description in the page in a way that it's automatically read to
AT-users.

What I can understand though is wanting to be *able* to author pages
such that a description is only available if explicitly requested. My
proposal will certainly support that. Here are some examples:

Providing a description in an external page. AT-users will be notified
that the description exists. Non-AT users could be notified using for
example a context menu item:
<img src="..." aria-describedby="desc">
<a hidden href="other.html" id=desc>

Providing a description in an external page while showing the link on
the page for non-AT users:
<img src="..." aria-describedby="desc">
<a aria-hidden href="other.html" id=desc>

Providing a description in the normal page flow while allowing
AT-users to automatically jump to it:
<img src="..." aria-describedby="desc">
<p id=desc>long description here</p>

Providing a description in the same document (to make it easy to keep
it up-to-date) while still displaying it only to AT users as to
satisfy esthetic design requirements for seeing users:
<img src="..." aria-describedby="desc">
<p hidden id=desc>long description here</p>

Providing a description in the normal page flow for non-AT users,
while letting AT users only see it if explicitly requested:
<img src="..." aria-describedby="desc">
<p aria-hidden id=desc>long description here</p>


> 3.)     Provide a reliable and effective user experience
>
>        Inasmuch as ARIA is new technology not yet fully or consistently
>        implemented by browsers or AT, how will you propose that your
>        ARIA based long text description can serve users needs
>        effectively and consistently, regardless of what particular
>        browser or particular AT a user may employ? In asking this
>        question we note that the CP we have endorsed DOES provide
>        effective and consistent support for users regardless of browser
>        and AT, and we believe they deserve that kind of support.

I'm not really sure what this requirement is asking for. Of course
HTML5 or ARIA isn't fully implemented yet. If we're ever hoping to
improve the web we have to add features to it, and there will always
be a time between those features are added to specifications and they
are implemented. This surely was the situation when longdesc was added
too.

Given that HTML5 has the same user agent requirements with regards to
longdesc as HTML4 does, I don't see that my proposal should give any
problems supporting down-level browsers. And even if HTML5 removed
those user agent requirements authors could always add both longdesc
and aria-describedby attributes.


/ Jonas

Received on Monday, 20 June 2011 23:39:55 UTC