Re: ISSUE-30 (Longdesc) Change Proposal

Jonas Sicking On 09-10-27 20.15:

> On Tue, Oct 27, 2009 at 7:09 AM, Leif Halvard Silli:


>>> I agree that @longdesc and @aria-describedby aren't exactly the same.
>>> However they are very similar.
>> Everything with a link is "similar". But normally, if one element can take
>> IDREFS only and another can take a single, complete URI, only, then we don't
>> consider them similar.
> 
> If two features are designed to solve the same problem, then I think
> they are similar enough that having both is a loss for all involved
> parties.

I think you should try to put in words what the "same problem" is. 
It sounds to me as if the only sameness you have in mind is 
"accessibility". That is a MUCH too wide sameness.

Fact is: @alt and @aria-labelledby are somewhat related [*]. Why 
don't you propose to remove the one or the other?

[*] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

> I would strongly argue that having more accessibility attributes does
> not mean that we'll have a more accessible web.


That's a general statement that I can make little of.

> In fact, I would say
> it's more likely to have the opposite result. It's much more valuable
> to have a simple clear message for how to make a page accessible by
> saying:
> 
> "To include a description use the @described-by attribute, see here
> for a couple of examples"
> 
> Than to say
> 
> "To include a description use the @described-by attribute or the
> @longdesc attribute, and on tables you can use the @summary attribute.
> @described-by is what you should use in situation X, @longdesc is for
> situation Y. In situation Z you can use either. If you use both then A
> will happen. Here are some examples"


And, again, you fail to realize that aria is not meant to 
"include" anything [*]. It is just a meant to draw links between 
related information.

Inclusion - or fallback as it is usually known as, works like 
this: As soon as you link to the "non-fallback", you 
simultaneously link to the fallback. That is: when you link to the 
IMG, you simultaneously link to the @ALT. Or to the @longdesc. Or 
- if the image is inserted as an OBJECT - to the HTML fallback.

The problem here is HTML itself: The "fine element IMG" (as Boris 
once told me) doesn't have a way to offer long fallback.

[*] ARIA does offer one or two attributes for inclusion of 
fallback text. But since HTML has such features itself, we don't 
implement them.

 
> I'm worried if our message is the latter people are more likely to not
> add anything and instead leave it for later when they have time to
> figure out what the right thing to do is. Especially since "have time"
> is something that's rare.

Reinvent the wheel, change of opinion, mixing different concepts 
etc  also cause confusion. And undermines credibility.

We do not add ARIA to reinvent the wheel, but to add features that 
HTML doesn't have and to make up for certain AJAX (mis)uses.

ARIA does not try to solve the fallback problem. But ARIA allows 
us to draw links between related info in the same page. That it 
also has been suggested [*] that authors *may* use aria-labelledby 
instead of @alt, does not change that.

[*] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

>>> Also, syntactically @aria-describedby has a larger syntax if the
>>> description is in an external document.
>> In addition to require a much more verbose *markup*, there are also
>> "expected effect" differences. See John's message [1] (and my reply).
>>
>> [1] http://www.w3.org/mid/009901ca566c$a296a9c0$e7c3fd40$@edu
> 
> I don't agree there's an expected difference.

Comparision table:

 >>>>>>>>>>>> describedby= | longdesc=
Is fallback:           no | yes
     Is link:           no | yes
Moves you
away from
img itself:           yes | no

By the longdesc=no in the latter row I mean that since the 
longdesc URL has target="_blank" in all supporting UAs, the reader 
get to read the fallback in a new window. As soon as the user 
closes the Window, he/she is back at the location where he/she was.

The describedby=yes, in the same row relates to the fact the user 
agent must first jump from the IMG, to the link and then to the 
long description page. And, on the way, the link may not have a 
target="_blank" either.

> Comparing the markups:
> 
> <img aria-describedby="desc">
> <a href="description.html" id="desc">...</a>
> 
> and
> 
> <img longdesc="description.html">
> 
> In both cases I would expect AT to indicate to the user that a
> description is available for the image. And if the user chooses to
> access that description, there is no reason the UA couldn't perform
> exactly the same action in both examples.


Yes, there is: An anchor usually has some text, that the user is 
expected to read before taking action:

<a href="description.html" id="desc">this is a long description of 
the image you (hopefully) came to this link from.</a>

This simply isn't fallback. In order to /behave/ like fallback, it 
requires a whole host of new behavior, as you outline here:

> Be that navigating to
> "description.html" using the current tab, opening a new tab, reusing a
> dedicated "description" tab. Or not navigating at all and simply
> reading the contents of description.html to the user.

Again: How can this happen unless the UA is instructed to ignore 
the text of the anchor? Or should we recommend anchors without 
text? And how would you discern between use of aria-describedby to 
link to related places (there may be several, and you may put them 
all inside the same attribute) on the external fallback text? You 
would have to add many more rules than you have suggested here for 
this to work.

> In neither case there is a specification that mandates how that
> description is presented to the user.

Specifications are in low regard in this group. The facts on the 
Web is what counts. And, fact is, that there is a defined way that 
@longdesc works.

> There *is* specified behavior for if the user activates the <a> link
> in the first example. However that behavior doesn't need to be
> followed if the user accesses the description for the image.

Now you are really ad-hocing here ... Unlike for @longdesc, there 
is a whole host of ways that an anchor link could open.

I think that if we want to "ARIA-fy" longdesc, then we should add 
ARIA-longdesc="". But then, we should also ARIA-alt ... This would 
  allow for the "simple" one line explanation of how to make your 
page accessible that you suggested above.
-- 
leif halvard silli

Received on Wednesday, 28 October 2009 15:00:45 UTC