RE : RE : link in new window debate

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 Wednesday, 19 November 2003 11:39:31 UTC