describedBy and longdesc Re: example spec text for longdesc

On Fri, 25 Mar 2011 22:34:27 -0400, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Mar 25, 2011 at 6:57 PM, Laura Carlson
> <laura.lee.carlson@gmail.com> wrote:
>>> First of all it has always surprised me that the list of use cases
>>> only list discusses adding accessibility information to images. Is
>>> there a reason things like tables, SVG (and portions thereof), figures
>>> and forms are left out?
>>
>> Do you mean that tables, SVG (and portions thereof), figures and forms
>> are left out as they do not have mechanisms for providing a long
>> descriptions?
>
> I mean that all the discussions revolve around adding long
> descriptions to images, rather than long descriptions on things that
> require long descriptions.

Yeah, because the longdesc attribute has only applied to images (and  
frames, but I will leave those aside for a moment).

aria-describedBy, if fixed, and generally applicable, would be better than  
longdesc. I hope that in some time this will happen, and longdesc will  
become obsolete.

Right now, however, that would be wishful thinking rather than paving  
cowpaths and learning from experience. Given that aria-describedBy is  
remarkably like longdesc but applied to more elements, it seems more  
sensible to me that we learn from implementation on both, with the goal of  
eventually making aria-describedBy seriously better, instead of just a  
poor reinvention of the longdesc wheel. The way to do that is to develop  
more implementation experience.

Given that longdesc will work (for screen-reader compatibility it is  
required to be in the DOM anyway) whether or not it is in the  
specification, I don't see any reason to actually throw it out - and if we  
have it, then I do see a motivation for working on improving  
implementation as the clearest way to determining how we really do this  
right.

>> Would it be possible to make longdesc a global attribute? What would
>> be the pros and cons?
>
> This is software, anything is possible. If it's a good idea is a
> separate question ;-)

Indeed...

>>> Also, ease of use seems to be missing from that page. This isn't
>>> really a use case but rather a requirement.
>>
>> Longdesc is a link so it is simple in that regard. Ease of use and
>> simplicity are pretty evident in the formal use case scenarios. For
>> instance:
>>
>> http://www.d.umn.edu/~lcarlson/research/ld.html#us-01
>> http://www.d.umn.edu/~lcarlson/research/ld.html#us-02
>> http://www.d.umn.edu/~lcarlson/research/ld.html#us-07
>> http://www.d.umn.edu/~lcarlson/research/ld.html#us-08
>
> And yet data shows that the vast majority of people get it wrong.
>
> http://wiki.whatwg.org/wiki/Longdesc_usage
> http://blog.whatwg.org/the-longdesc-lottery
>
> Do you have data showing otherwise?

The data that I had was that it was often wrong but nowhere near as often  
as those studies suggested. I no longer have the data, but it was based on  
a similar methodology and done as an exercise in testing whether I reached  
the same conclusions on slightly more recent data.

Broadly, longdesc is often done wrong. For such an edge case that is not  
surprising. Interestingly, the impact of getting it wrong isn't  
necessarily that bad. Most of the web is done wrong, and browsers tend to  
figure out how to handle it (this is a fundamental rationale underlying  
HTML5), and longdesc falls into this category pretty easily.

>>> Once you include these use cases and requirements it seems much less
>>> that longdesc is a proper solution.
>>>
>>> It's only available on <img>ages
>>> (this missing all other ways even for including images such as
>>> <canvas> and <object>).

Agreed.

>>> It isn't very user friendly. Lots of people
>>> seem to misunderstand it to include the actual describing text rather
>>> than a link to it.

That's an authoring problem, and it seems relatively straightforward for a  
user agent to check for the defective case and make it user friendly if  
that's desired (indeed, Mozilla's implementation that merely showed the  
longdesc attribute content actually encourages that authoring mistake).

However, I don't see a proposal that would change that. It turns out some  
things are complicated, or unintuitive. There were really good reasons for  
namespaces not being inherited by attributes, even though that surprises  
people, and there are good reasons for pi not being 3 or 22/7 or even  
rational, even though that surprises people.

>> That's where better conformance tool and authoring tool checking along
>> with more implementation would come in.
>
> A terrifyingly small percentage of the pages on the web pass a
> validator. The far vast majority of pages doesn't even nest their tags
> correctly. The sad truth is that while we can do what you suggest,
> it's not going to have a big effect because people simply doesn't
> consult validators to a large degree.

Right...

> So far I have seen no reason to believe that longdesc is going to be
> used in a much better way the next 10 years than it has the past 10
> years. If that's the case then we really aren't helping anyone. I'd
> like to actually make the web better.

Given the fact that describing stuff for accessibility purposes is  
believed by many to be an edge case anyway (and in practice is often not  
done even when it clearly makes sense) I think the impact is different to  
what you describe.

To take a parallel, a bit over a decade ago when I was working on WCAG 1  
and friends, there were huge arguments about whether it was reasonable to  
even ask for the alt attribute. At that time, it really wasn't used much  
at all (although text-only browsing was probably more common at the time).  
Those arguments were repeated a few years ago in the context of whether  
alt should be mandatory. But while there is a braod acceptance that alt is  
generally not used, or used badly, nobody argued that alt actually harms  
accessibility - the discussion simply turned on ways to improve the way it  
was used to reduce the *instances* of alt being used badly enough to cause  
problems.

I think longdesc is in a similar boat. We *are* helping people when we get  
it right, even though there are also cases of getting it badly wrong As  
noted above, I think the mozilla implementation guided authors more or  
less exactly the wrong way, but I think that even so in the long term it  
enhanced rather than damaged accessibility since it raised the issue for  
more people who hadn't considered it at all. Improving a few  
implementations will, I *believe* (that is, I can't prove it but don't see  
any credible refutation with more substance than my belief), lead to  
improvements in usage, in just the way that the usage of alt has improved  
over the last decade and a half, to the benefit of people who rely on it  
 from time to time.

>>> Not only that, but since it is url based, rather
>>> than id based, it encourages people to put the description in an
>>> external resource, which more often than not is not what you want to
>>> do.
...
> Indeed. I'm not saying that the use case doesn't exist. I'm saying
> that it's not the majority case. We should optimize for the majority
> case while making the minority case possible.

I'm not sure about the majority/minority split here. I believe that in  
many cases the external reference *is* in fact what you want to do -  
enough that it *may* be a majority and certainly isn't a small enough  
minority that this is the major problem you seem to suggest.

>>> It turns out that ARIA already have a attribute that almost fits the
>>> bill, and this is aria-describedby. As is pointed out on the wiki
>>> page, the problem is that the ARIA specification only allows exposing
>>> text content to the user, rather than arbitrary content, such as
>>> links.

Yes, that is a problem.

>>> This problem can be fixed though by changing the ARIA specification.
>>> By changing ARIA to say that aria-describedby can point to arbitrary
>>> content, rather than just refer to the textual contents of it, we
>>> solve multiple problems in one go.

Indeed.

>>> This would first of all allow aria-describedby to solve all the use
>>> cases in the wiki, as well as the ones pointed out in this message. It
>>> also seems to fulfill the ease of use requirement better as people so
>>> far seems to put an id in aria-describedby rather than the actual
>>> text.

Two things to fix: Allow it to take a URI and meet the "external  
description" case, and allow it to collect real element content not just  
strings.

> First off I'm not proposing aria-describedat. I'm suggesting fixing a
> problem in aria-describedby.

Which I think is the right approach.

> Anyhow, I still haven't heard any arguments against fixing
> aria-describedby. Nor if fixing it is indeed needed.

Yes, it is needed, and I agree that this is a good idea.

> Can you, or anyone else, point to where in the ARIA spec it actually
> says that aria-describedby actually only exposes the textual contents
> of the items it links to? Rather than exposing their full semantic
> structure.

In the section on properties where these things are specified,  
aria-describedBy is explained as being functionally the same as  
aria-labelledBy which in turn is described as being the same as  
aria-label, whose value is explicitly restricted to a string[3]. That's  
not very beautiful in terms of spec writing, but I think it means (as you  
say, somewhat unintuitively) that aria-describedBy really does collapse to  
the textcontent of whatever it refers to.

This interpretation is explicitly defined in the ARIA User Agent  
Implementation guide [4].

>> Sean Hayes just wrote up  "Configuring Internet Explorer to Handle
>> Longdesc"...
>>
>> Jonas, is something like that doable natively in FireFox?
>
> This is software, anything is possible. If it's a good idea is a
> separate question ;-)
>
> Anyhow: https://addons.mozilla.org/en-us/firefox/addon/longdesc/

(Opera making Firefox more accessible :P ;) Thanks Patrick)

cheers

Chaals

[1] http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby
[2] http://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby
[3] http://www.w3.org/TR/wai-aria/states_and_properties#aria-label
[4] http://www.w3.org/TR/wai-aria-implementation/#mapping_state-property

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Saturday, 26 March 2011 15:23:44 UTC