- From: Leif Halvard Silli <lhs@malform.no>
- Date: Thu, 06 Sep 2007 16:06:38 +0200
- 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 >> @LONGDESC. > > 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