[whatwg] Context help in Web Forms

On Sat, 11 Jun 2005, Charles McCathieNevile wrote:
> >
> > Sorry, I should have been clearer. We got feedback from implementors 
> > saying they couldn't think of a way to make it discoverable, and we 
> > got feedback from Web descigners saying it wouldn't be useful if it 
> > wasn't discoverable.
> 
> OK. This is in fact a generic problem in HTML - consider most of the 
> things that the userJS 
> http://userjs.org/scripts/browser/enhancements/frameset-links does - 
> links like longdesc, the cite attribute from quotes, etc. Longdesc in 
> particular is important to get right, for accessibility (I am thinking 
> about this because I am blogging photos from a phone and want to share 
> the results with friends who are blind).

In fact "longdesc" is a perfect example of a feature that, due to lack of 
discoverability, became one of HTML's most thorough failures. To the point 
where the accessibility community encouraged authors to use explicit 
D-links rather than longdesc="". Indeed, longdesc="" has been dropped from 
XHTML2 and (as soon as I get around to defining <img>, baring anyone 
giving good reasons not to do this) will be dropped in HTML5 as well.


> They are discoverable in the sense that they are in the DOM, which 
> allows user agents to work out something sensible - context menu (like 
> iCab does for most of these things) or a transformation on demand that 
> shows the links like Tarquin's script or an XSLT as an alternate 
> stylesheet, or exposing them in a particular user interface like JAWS 
> does with its propretary contexthelp attribute.

IMHO, "longdesc" is useless. About 3 people on the planet use it. Sure, 
theoretically it could be useful, but in practice since it is not shown by 
user agents (and since there is no good way really to show it in user 
agents that would be discovered by a majority of users) most authors just 
ignore it. And if authors ignore it, it won't be consistently available, 
and if it isn't consistently available, users won't use it when it _is_ 
available, since they won't expect it to work.


> One of the difficulties is that many content providers don't want to 
> "clutter their page with help links" - something that I think is in fact 
> a bad design decision on their part, but nevertheless is a reality. 
> (This is related to the problems of design limitations that lead to 
> things like image replacement techniques...)

Actually, given the way many sites actually do have help links, or "?" 
icons, or the like, I don't see content providers being reluctant to do 
this, as you say. Giving them a way to use their already-present and 
discoverable help links and mark them up so that UAs can do with them 
something useful is the way most likely to increase the availablility of 
UA-detectable help.


> Anyway, having the ability to add a help link in the body, with 
> particular context-sensitivity (as discussed for including a link with 
> rel="help" in a form control label) is probably sufficient. I'll take 
> that discussion back to W3C's Protocols and Formats group (the part of 
> WAI that deals with review of specifications to ensure they enable 
> accessibility) and see what they think...

Great! Thanks. I think your idea of making rel="help" be relative to the 
nearest parent <label> is a good one. We could also say it is relative to 
the nearest parent <label>, <body>, <section>, <form>, <fieldset>, or 
other such grouping element. I'll look at this in more detail when 
defining the rel="" values.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 12 June 2005 03:52:25 UTC