Re: @title's relation to accessibility

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 (advicory information etc)? Else, feel
>free to plain my English Š

Do you mean that the term "advisory information" doesn't translate well to
other languages? Surely this is a pretty universal concept?

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>, where the "advisory
information" is not necessarily intended to help the user make any decision
at all, but to provide what you could perhaps call "ignorable additional
information". ("Ignorable" in the sense that as far as the author is
concerned, that information may be useful to the user, but not an essential
part of the content.)

[...]

>>>   - 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
because so few authors ever actually rely on @alt themselves, I think they
need something much more concrete. An exactly specced "guaranteed to work up
to this threshold", would be useful. (If exactly specced, it would become
machine-checkable, which would make it possible for authoring tools to help
authors. Indicate when alt text crosses the threshold, for instance.)

>>> , 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.

> 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.

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

> 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.

>> (Besides, in current implementations, any
>> @alt text over maybe 100 characters or so is likely not useful. So it needs
>> to be 'short' anyway) And it sounds like yet another argument based on Jaws'
>> behaviour, not on user needs.   [Š]
>
> I have no clue why you link it to 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.

> And I don't understandy why you even suggest <ALT> if you think @ALT over
>hundred characters is «likely not useful».

See the test case I linked to:
<http://santek.no-ip.org/~st/tests/altlength/>. Only Firefox (2) and
lynx/links do anything useful with 'long' alt text.

So I'm not saying that there is anything wrong with long textual equivalents
as such. I'm referring to a problem with how @alt is implemented in current
UAs. Aither those UAs need to be fixed, or if that's not possible, the spec
needs to inform authors exactly what length of @alt they can rely on to be
actually consumable by users (via UAs).

[...]

> Please note that I used the word SHOULD.

Oops. My apologies! Somehow I got it into my head that you had said MUST. OK,
scrap what I said ;)

[...]

>>>   - @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». (There are one
>billion home pages in the world - and nine million bicycles in Bejing.)

Sorry, I cannot follow you here. There seems to be a mix-up of @title and
<title>?

[...]

> 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) would actually be practical for aural or
braille access though. 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.

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.

> If one used <ALT> for the the long descriptions, then the long descriptions
>would allready exist inside a spesific element - and you could just collect
>those elements on one page.

Indeed.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Thursday, 6 September 2007 16:20:22 UTC