Re: Clarification of rational for deprecation of @longdesc and @summary

Philip Taylor (Webmaster) 08-02-18 15.46:   ­
> Joshue O Connor wrote:
>> Joshue O Connor wrote:
>>> often the @longdesc text is hidden from sighted users and may not be a
>>> part of the main page content.
>>
>> They contents are obviously not even on the same page.
>
> Why do you assume this, Joshue : could the URL of the
> LONGDESC not refer to a document fragment on the same page ?

Perhaps he has realworld experience?

iCab 4, the first WebKit browser with Longdesc support, opens the 
longdesc URIs in a new window - even if it leads to the same page. It is 
as if @longdesc has a hidden target='_blank' attribute. (Does other 
browsers do it differently?) Because of the new window, one expects a 
separate document.  The target='_blank' behaviour has a accessibility 
feature: it ensures that the @longdesc is availbale even when JavaScript 
and CSS are turned off. And it also makes it very simple for the user to 
come back to where he was before opening the longdesc: Just close the 
window. If the @longdesc doesn't open that window, the long description 
really needs to have a backlink instead, in order to be functional.

Of course, @longdesc could be made to work more elegantly than that. 
However, for that to happen, we need to move from fighting about whether 
to keep @longdesc or not, to a discussion about how it can work better.

When Karl published his nice illustration of 'HTML 5, one vocabulary, 
two serialisations' [1], then Gregory bugged him about where the 
@longdesc for that telling illustration was. That blog post is a nice 
example. Currently the page looks full. It doesn't need more content. 
Thus it would have made sense to provide a long description that was 
"out of sight" for sighted users, but still easy available for unsighted 
users.

The simple solution to that problem is TARGET='_blank' + separate 
document = @longdesc.  :-)

The downside is that it might be impractical for the author to keep a 
sepearate document just for that. But, if the author decides to keep it 
in the same document, what then? Allthough it is possible to use 
selector.longdesc{display:none}, this would not work well for sighted 
authors and others users that are obligued/interested/needs to have a 
look at the long description. (Another issue is whether display:none 
should actually be acessible to users at all? For instance, we don't 
want that it is possible to copy the content of an element with 
display:none.)

The Acid 2 test [2] provides one model for how one could keep the long 
description out of sight, but still in the same page. When you open the 
Acid 2 test page, you meet a unscrollable page with a link. When you 
click that link, you are lead to part that you, at first sight, did not 
understand was there (since  the lacking scrollbar is a signal that the 
page lacks more content). Imagine that the link really was a @longdesc 
link. The long description would then be out of sight, until you 
activated  the longdisc URI.  For this to work simply and effectively, 
we would have to have some kind of LONGDESC element, which would 
automatically be placed below the bottom part of the page and which only 
became available when you followed a longdesc URI. That  element would 
then even be visible for sighted users, provided they follow the 
longdesc URI. (This might remid you about the ALT element, that has been 
discused - and yes, we would be able to do this with a ALT element.)

Even sighted users could benefit if browsers were able to display more 
than the content of the page: The upper border of the browser window 
play an accessibility role for all sighted users. When you click a link, 
the browser typically scrolls the page so that the link target is 
situated just below the window border. But if the page is too short, 
this doesn't work. What then? (Certain browsers have tried to make up 
for that problem by highlighting the link  targets.) Those of you who 
have tried the VIM editor knows that it can scroll, even if the page is 
empty. This is practical, and could have been practical in browsers as 
well, if it was limited to the cases where you follow a link and the 
page doesn't have enough room below the link target to move the link  to 
the top of the window.

Another model - the simple one: today we have all these nice AJAX based 
image slides viewers, which loads the image slides in front of the rest 
of the page - without disturbing the user with opening and closing 
multiple windows. What if this model could be used to display a long 
description?

But for this to work, the @longdesc URI must be possible control.

Some days ago, it was discussed whether we should have a new IMG element 
which could provide alternative content and so on. But it was said that 
we should try to keep the IMG element as a simple element where users 
can expect «safe» images - images that do not hide dangerous scripts and 
so on. If we buy that that argument, then the @longdesc attribute should 
follow hand in hand, as @longdesc would then be the only way to serve 
longer alternative content to such images.

Perhaps we should make a decision: Either we go for a new variant of IMG 
with proper support for alternative content. Or we keep IMG as it is, 
and therefore also work to improve @LONGDESC, @ALT, and <ALT>.

[1] Karl's blog post: 
http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html
[2] Acid 2 test: http://www.webstandards.org/files/acid2/test.html
-- 
leif halvard silli

Received on Tuesday, 19 February 2008 08:19:22 UTC