Re: @title's relation to accessibility

2007-09-06 18:00:41 +0200 Sander Tekelenburg <st@isoc.nl>:
> At 16:06 +0200 UTC, on 2007-09-06, Leif Halvard Silli wrote:
>> 2007-09-06 14:25:30 +0200 Sander Tekelenburg <st@isoc.nl>:
>>> At 18:36 +0200 UTC, on 2007-09-04, Leif Halvard Silli wrote:
>>> 
>>>>    - say that @TITLE «tells about», while @ALT «is the story itself»
>>> 
>>> I don't know. I understand your intention, but... [...]
>> 
>> You prefer words of latin decent  [...]
 
> Do you mean that the term "advisory information" doesn't translate well to
> other languages? Surely this is a pretty universal concept?

Advisory sounds ambigious - or «big». (But ok, it is 'computer speak')

> For <a> and <link>, "information to help the user decide" would be a good
> synonym I suppose. But not so for <abbr> or even <p> [...]

While «tells about» would work here too.


[...  - decide a @ALT text limit ... ]
>>> Yeah, [...] Currently @alt isn't interoperable  [...]
>>> 
>>> A problem is how to define the limit. (characters, words, bytes?)
>> 
>> Yes, that is a problem.  But for authors, it would have to be genereral
>> advices, which could be language spesific, even!
> 
> Well, we already have the general advise that @alt should 'short'. But

Ok - I had in mind something more spesific than just «short» - because my focus was on at which lenght a text becomes so long that you might want to read a @TITLE before actually starting to read it.

> [...] An exactly specced "guaranteed to work up to this
> threshold", would be useful. (If exactly specced, it would become
> machine-checkable [...]

And when too long, the author tool proposes to use @longdesc? This proposal is actually linked to the _visual_ problems with @ALT text. Aural UAs should not have that limit. And I don't think you link this to @TITLE at all? You just want to help users to not write too long @ALT texts.  Hence, I don't know if I support this. An @alt text should be as long as it requires. We should not author to one particular user group (people with graphical legacy UAs with limits on the @ALT text). 

>>>> , wherupon @TITLE SHOULD be added?
>>>>      (AT UAs could think: If long @ALT, then read @TITLE first)?
>>> 
>>> Sounds way too complicated to me. [...]
>> 
>> For you - OK. But the idea proposed here is purely for AT/aural UAs.
> 
> I understand. I was thinking that this might make authors go and think how to
> change their @alt and @title to affect which will be read first by such a
> UA... But perhaps it is unlikely that authors would go that far 'just' to
> affect output of aural UAs.

May be. But @title could be useful e.g. when hovering over the video  - also. 

>> It could be useful for them to read a short @TITLE before automatically
>> starting to read a long @ALT.
> 
> Hm... yes, perhaps.
> 
> It might very well be that @title isn't really understandable before you've
> consumed the actual image or its equivalent though. So I wonder if this would
> really be that useful in practice.

When do you need a tag on something? Before or after you have looked at the goods? Either - or, the tag is useful. (The aural UA should of course be able to jump directly from the @TITLE and behind/past the ALT-text, should the content not interest the user.)

> Anyway, this seems to be more about potential aural UA behaviour than about
> HTML. Aren't we getting off topic?

I just examplified how an aural UA could make use of the @TITLE.  Which was necessary to explain the actual or possible AT-relatedness of @TITLE.

>> It would then be up to that AT UA to decide what is a long and what is a
>> short @ALT - or <ALT> - based on the language the the AT technology is
>> localized for - and support. (@LANG, please help!)
> 
> I'm not sure I understand what the UAs language has to do with this.

You said: «A problem is how to define the limit. (characters, words, bytes?)». Then I replied that «lenght» should take @LANG into consideration. The UA language is only related because document language and UA language is often related - especially since @LANG is often lacking.
 
[  what is it with Jaws? ]
> Much of the story that @title has something to do with accessibility appears
> to stem from Jaws' behaviour of trying to make use of @title in such a way.

(I thought JAWS's problem was that it by default tried to read the URL - when @ALT was lacking. While I tried to mention a good behaviour when @ALT is there ...)

[ who can do any useful with long @ALT? ]
> Only Firefox (2) and lynx/links do anything useful [...]
>
> So I'm not saying that there is anything wrong with long textual equivalents

OK - I thought by 'useful' you meant in the sense «a good text to read».

>>>>    - @TITLE on A-links a MUST?
>>> 
>>> I don't see why. How would that be useful in a case like <a href="/">go to
>>> the home page</a>?
>> 
>> Because the @Title would say «Opera browser: Home page». [...]
> 
> Sorry, I cannot follow you here. There seems to be a mix-up of @title and
> <title>?

Isn't it a good advice that @TITLE in a link can contain the <TITLE> of that page it links to - if the links go directly to that page - and not a reference inside that page - and if, of course, that page has a telling <TITLE>? (I was quoting the <TITLE> of the Opera homepage - which btw, doesn't user @TITLE in its links.)

 
[ @londesc and Flickr ]
>> If the @longdesc URL linked to a spesifict descripion of a spesic image,
>> then those descriptions could be collected and presented on one page as a
>> «text album». I mean: As part of the Flickr service!
> 
> Hm... I suppose that for cases like photo albums it would more closely match
> the visual user experience. I don't know if such a view (textual equivalents
> of multiple images within one page) 

@LONGDESC="URL" => that image's description - wherever it is located.

> would actually be practical for aural or braille access though.

It would be up to Flickr.

> But authors can already use <link rel=alternate> for
> this. They'd be free to provide both that and individual textual equivalents.
> Thus allowing the user to pick whatever suits him best.

<link rel=alternate> => a good advice for Flickr.

Flickr must decide how to do it the best way for this usergroup. Given how difficult is seems to be «good guy» when it comes to @ALT, then why not use @LONGDESC in one of these ways? It would also create a focus on good descriptions from those that have user accounts on Flickr.

Btw, your thoughts on how @longdesc can be used in photoalbums, are they different from mine?

> I suppose a UA would be free to implement such a 'data gathering' feature
> though. No need to have the spec require or disallow it.

I don't follow. I have not proposed any 'data gathering'.
-- 
leif halvard silli

Received on Thursday, 6 September 2007 17:59:37 UTC