W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: @title's relation to accessibility

From: Leif Halvard Silli <lhs@malform.no>
Date: Thu, 06 Sep 2007 16:06:38 +0200
Message-ID: <160a348b7a1fdeb6f30a2ec36d7e9524@10013.local>
To: Sander Tekelenburg <st@isoc.nl>
Cc: public-html@w3.org, wai-xtech@w3.org

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:

 [ … @TITLE + accessibility]

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

>>   - require @TITLE  when @LONGDESC is used [Ý]
> Why?  […]

The logic was: Since @LONGDESC works like a link for the user, and since I suggested that links should/must have @TITLE. But perhaps it would be enough with the @ALT text - OK. (Unless the @ALT is too long, of course - see below.)
>>   - 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!
>> , 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. It could be useful for them to read a short @TITLE before automatically starting to read a long @ALT. 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!)

> (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. And I don't understandy why you even suggest <ALT> if you think @ALT over hundred characters is «likely not useful». Then, in fact, we don't have the interopability problem you mentioned above (or, at least the problem quite small). 

> I see no reason to expect that even
> more author requirements will make *those* authors do any better. More likely
> will it result in authors that try to do things right will make more
> mistakes, because their job gets more complicated by such requirements.

Please note that I used the word SHOULD. It is not permitted to serve pages without <TITLE>. Long <ALT> for video transcrips without any @TITLE given somewhere SHOULD not be served without a @TITLE about what it is.

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

[ … in photo albums it is useful with @LONGDESC … ]

>> Thus each such image - in all its size versions - could have the same
> Indeed. […]

>> Thus, we have practical example, I think about where the the A-link itself
>> can point one place (to a larger version of an image), while the @LONGDESC
>> can point to a independent description.
> Right:
> <a href="large.jpg"><img src="thumb.jpg" alt="something or nothing"
> longdesc="URL"></a>

Cool that we agree on this :-)
>> If the descriptions could be collected independently from the images, then
>> it would also not be difficult to present them as a whole, on a page
>> particulary aimed at giving a textual version. (The proposal to have an ALT
>> element comes to mind ...)
> Sorry, I can't follow.

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!

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.
leif halvard silli
Received on Thursday, 6 September 2007 14:06:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:26 UTC