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

Re: @title's relation to accessibility

From: Sander Tekelenburg <st@isoc.nl>
Date: Thu, 6 Sep 2007 14:25:30 +0200
Message-Id: <p06240694c305977fc12f@[192.168.0.101]>
To: public-html@w3.org, wai-xtech@w3.org

At 18:36 +0200 UTC, on 2007-09-04, Leif Halvard Silli wrote:

[...]

> To decrease confusion about how accessibility is linked to @TITLE, perhaps
>these rules could be worth considering:
>
>  - say that @TITLE «tells about», while @ALT «is the story itself»

I don't know. I understand your intention, but... In one way that's exactly
what HTML 4 and 5 say. In another this seems too vague. What does "tell
about" mean? I don't think this would make things more clear for authors.

[...]

>  - require @TITLE  when @LONGDESC is used [Ż]

Why? I can understand that, like all context, @title can help a user decide
whether it's worth to go fetch the longdesc resource. But why should authors
be *required* to provide it? (I suspect that the few who do bother to provide
@longdesc don't need any such force anyway.)

>  - decide a @ALT text limit

Yeah, I proposed that a while ago ;) But for different reasons:
<http://santek.no-ip.org/~st/tests/altlength/>. Currently @alt isn't
interoperable and authors have no way of knowing what length of @alt text is
useful in a given situation :(

A problem is how to define the limit. (characters, words, bytes?)

> , wherupon @TITLE SHOULD be added?
>    (AT UAs could think: If long @ALT, then read @TITLE first)?

Sounds way too complicated to me. (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 see Jaws' behaviour as error recovery -- desparately trying to scrape
together something useful for the user when the page hasn't been authored
properly in the first place. Not that different from what every other UA's
ESP engine does. I understand that it tries that (although I think it's bad
that it doesn't allow the user to access *both* @alt and @title, and
apparently doesn't indicate which it is presenting). But it applies
specifically to badly authored content. 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.

>  - @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>?

That aside, authors who don't uderstand or care will either simply not comply
(and still get rendered by UAs) or insert @title="", to satisfy the
validator. (I'm beginning to feel like Hixie's alter ego :))

[...]

> For instance, in photo album - like Flicker, which have 2-3-4 levels
>(different sizes) of «thumbnail» images - until the largest version: For AT
>users, there might not be any point in looking at all these different sizes.
>Thus each such image - in all its size versions - could have the same
>@LONGDESC.

Indeed. And either the surrounding text, or @title, should indicate that the
image is a link to a bigger/smaller version of itself.

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

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


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Thursday, 6 September 2007 12:26:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:07 GMT