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

Re: 48-Hour Consensus Call: ARIA-DescribedAT & Longdesc

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Mon, 9 Apr 2012 15:52:23 +0100
Message-ID: <CAEhSh3c-17hokvydJo9MNrnijyfzitCNUPCVCB856NH5mcAiDg@mail.gmail.com>
To: John Foliot <john@foliot.ca>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, Joshue O Connor <joshue.oconnor@cfit.ie>, James Nurthen <james.nurthen@oracle.com>, Charles McCathieNevile <chaals@opera.com>
On Thu, Apr 5, 2012 at 1:19 AM, John Foliot <john@foliot.ca> wrote:
>> On Tue, Apr 3, 2012 at 5:54 PM, Charles McCathieNevile
>> <chaals@opera.com> wrote:
>> >> Until vendors widely implement @longdesc UI, it is harmful to
>> suggest
>> >> such authors rely on the @longdesc attribute.
>> >
>> > True, up to a point.
>>
>> Mmm, what point is that (for such authors)?
>
> How about up to the point "Know your audience"?
>
> If I am an educational book publisher, and I know what I can and can't do to the actual text of a text-book

Adding in-page chrome like a link or a details element is less of a
modification to the actual text than writing copy for @alt or
@longdesc.

> , yet I need to also provide a longer textual description to images, then I will also know that at the receiving end of the equation the majority of users who will require the @longdesc value will both a) know that *my* e-textbooks have that feature, and b) the end users will be equipped to access that longer description.

[snip]

> In the academic setting I just left (after almost 6 years), I can safely report that virtually every non-sighted user I encountered on campus had and used JAWS as one of many screen readers (they often also had NVDA, and of course they used VoiceOver on the iPhones) - the point being this group of users had the software they needed to access content availed via @longdesc.  Assuming those students would want to take advantage of @longdesc congtent, they would choose the tool that gave them access to that content.

[snip]

> As for those users who might be sighted but also required "other affordances" to enable them to complete their studies, there is a dedicated office on campus (and this holds true for virtually every educational institution in the US) that helps equip those students with the software tools they require to get the job done, and so they could be steered towards any number of browser plug-ins that exist, and further counseled about @longdesc, and how to access the information provided that way.

Forcing users to switch device or software, purchase expensive
software subscriptions, seek advice from paid experts, or rely on
third-party components just to understand images are good examples of
the harm I'm talking about.

> Is this a specialty "edge-case" - why yes it is, so what? Does it make it any less valid? There are hundreds of thousands of non-sighted students in schools each year that would benefit from this, and Book Publishers don't have unfettered freedom to do as they please with content that is delivered to them; yet they also have obligations (certainly in the US) to accommodate their non-sighted users, so these content authors have to tread a very fine line, and @longdesc is a tool that allows them to do just that.

What legal constraint prevents adding <a> or <details> that wouldn't
also apply to adding @alt and @longdesc? The AAP bug report doesn't
mention legal constraints.

>> >> Reporting implementation status information for all features,
>> perhaps
>> >> with a note about alternative techniques, would be better.
>> >
>> >
>> > indeed. And I say that knowing that any such information is itself
>> likely to
>> > be only half-right soon.
>>
>> I think it's critical that if we present such information we commit to
>> updating it. This is a similar proposal to keeping a site like
>> caniuse.com updated.
>
> Funny you should mention that Ben. Since you bring it up, I can state that currently there is a Joint WCAG & PF Task Force for HTML5 and WAI-ARIA WCAG Techniques (http://lists.w3.org/Archives/Public/w3c-wai-gl/2012JanMar/0011.html) that is looking to update these kinds of techniques.

I was talking about the HTML specifications and conformance checkers
rather than WCAG Techniques, although obviously these could all make
use of the same underlying information. Authors are unlikely to
encounter any of these resources, of course, but I suspect the
conformance checkers are the most encountered and the Techniques the
least.

Is this task force going to be contributing to the HTML test suite to
help keep this information objective and updated?

   https://github.com/w3c/html-testsuite

> Since you believe it is critical to keep this type of information up-to-date

Does anyone really think it's not critical?

> I hope that you would be happy to lend a hand there, given that Joshue O'Connor and James Nurthen are in desperate need of assistance in this area.

Happy? Yes. Likely to prioritise? No.

> Both have been CC'd on this note, and I am sure you could reach out to either of them to see how to assist.

Well, even without an exhaustive test suite for backing, they could
presumably edit:

http://www.w3.org/TR/WCAG20-TECHS/H45.html#ua2.19.1

and replace:

"Some older assistive technologies do not support the longdesc attribute."

with some more accurate rubric like:

"Only some user agents or user agents combined with assistive
technologies make long descriptions linked via the longdesc attribute
accessible, for example by exposing it via a context menu. Even fewer
make it easily discoverable, for example by announcing the presence of
the long description or providing a indicator in the toolbar that long
descriptions are present. You may wish to consider using more
widely-supported techniques such as G73 or G74 instead."

(FWIW Josh, you might consider putting the Techniques into a DVCS to
provide another way to push edits your way.)

--
Benjamin Hawkes-Lewis
Received on Monday, 9 April 2012 14:53:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:58 GMT