W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2003

RE : RE : RE : link in new window debate

From: yoan SIMONIAN <yoan.simonian@snv.jussieu.fr>
Date: Thu, 20 Nov 2003 12:52:39 +0100
Message-Id: <200311201154.hAKBsNlO055141@drum.snv.jussieu.fr>
To: "'Marjolein Katsma'" <hgnje001@sneakemail.com>, <w3c-wai-ig@w3.org>

I think in point of user view for the title attribute for a link.
Many assistive technologies choose link text or title texte. 
In that two ways link or title is the same so have to be short in this point
of view. Just a question of usability ansd experience with users.

I'm OK with you about the fact that link text has to be explicit at itself
and use title is certainly not the best way to do.

But i think when it's not possible to make link itself accessible (customer
obligations ...) the title attribute is one of the best alternative to do
it.

yoan


-----Message d'origine-----
De : w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] De la part
de Marjolein Katsma
Envoyé : mercredi 19 novembre 2003 17:39
À : w3c-wai-ig@w3.org


At 13:54 2003-11-19, yoan SIMONIAN wrote:


>>*) I've seen some admirable efforts to include "help" information in 
>>title
>attributes. Unfortunately, whether this
>>actually is helpful depends on the browser. IE (win) will show the 
>>whole
>text (or at least a lot of characters) while
>>Mozilla (and its Netscape derivatives) will show only a fixed-length
>(maximized-length) string which may cut off the
>>relevant part of the help text. I've come to the conclusion that a 
>>title
>attribute may be useful for some purposes, but
>>not really for "help" information. 
>
>I think it's not realy a problem if you respect WAI recommendation that 
>say that links have to be short.
>On BrailleNet short = max 80 caracters. So no problems with mozilla or 
>Netscape ;o)

But I wasn't referring to link text - I was referring to help text
implemented in title attributes.
If WCAG has anything to say about that, I can't find it.

And I don't see why help text (as such) should be 'terse' (as WCAG specifies
for for link texts); that would often mean the help text can't really be
very helpful. The problem is with such a helpful text implemented in a title
attribute where browsers limit what they show of it. That's why I think
showing help text directly embedded (visible) in a page at the user's
request is a better solution than using a title attribute - without changing
or shortening the help text itself.

The implementation I'm faced with uses help text in title attributes. The
texts themselves are fine, they _do_ help. It's putting them in title
attributes that creates the problem, given different browser
implementations. Many developers would choose instead to display the help
text instead in JavaScript popups, with a little icon to trigger the popup
if activated. (If done consistently, that would not constitute *unexpected*
new windows; it can work quite well _provided_ you (can) use javaScript.)
Personally, I don't think that's a good solution though, even if the links
are coded so they work even when JavaScript is not active. IMO, just showing
the help text right on the page at the user's request would be a better (and
more generally accessible) solution; although that means that with static
HTML you'd have to maintain two versions of the page; server-side scripting
makes it possible to maintain only a single copy, but is not available to
all.


>All pages I develop are HTML 4 transitional Valid.
>
>I just have a question what is the difference, for an audience, to code 
>on strict more than on Transitional ?

For one thing, it prevents the use of the target attribute ;-) In general,
the advantage is more a usability one than related to accessibility: it
simply forbids all representational markup, making it easier to apply
consistent styling across all pages using a single stylesheet. IMO,
consistency enhances usability.

I see "transitional" as backawards-looking, and "strict" as forward-looking.
(Provided you have the luxury of not having to cater for old browsers and
their JavaScript implementations.) Nothing to transition "from" any more,
this is just HTML again as it was originally conceived: just structural
markup. XHTML 1.1 confirms that. XHTML 2.0 will not have any
representational elements any more.

I'll readily admit it took me a while to get used to XHTML strict where I've
long been using XHTML transitional (since more than three years, in fact);
but I like the clarity. Admittedly, that's a coder's perspective, but I
don't see how it harms accessibility in any way. If anything, the opposite.


Cheers,
--
Marjolein Katsma
HomeSite Help - http://hshelp.com/ - Extensions, Tips and Tools The
Bookstore - http://books.hshelp.com/ - Books for webmasters and webrookies
Received on Thursday, 20 November 2003 06:54:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:13 GMT