[whatwg] Context help in Web Forms
ian at hixie.ch
Sun Jun 12 03:52:25 PDT 2005
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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg