[whatwg] Context help in Web Forms

Tue Oct 30 18:01:42 PDT 2007

On Sun, 12 Jun 2005, Derek Featherstone wrote:
> >>
> >> 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.

The spec makes it relative to the parent of the <a> element.

> I've actually been thinking about that for a while - rather than leaving 
> it to a "guess" why not bind it specifically with something like an 
> about attribute that identifies the specific element/node it references?
> 
>  rel="help" about="#phone-number"
> 
> That would allow for much more flexibility and robustness wouldn't it?

On Mon, 13 Jun 2005, Matthew Thomas wrote:
> 
> Or perhaps <a ... rel="help" for="phone-number">, to be consistent with 
> the for= attribute in <label>.

This is a possibility, but is it really needed? In general it seems we'd 
want to encourage authors to put the links near the text and controls to 
which it applies.

> Many applications provide inline help which is not a label, and the same 
> attributes would be appropriate here: <div rel="help" 
> for="phone-number"><p>The full number, including country code.</p> 
> <p>Example: <samp>+61 3 1234 5678</samp></p></div>

How would UAs use this?

> The cite= attribute was also mentioned in this thread as one that is 
> practically useless because there is no good way of presenting it. 
> (Sometimes authors use JavaScript to pull it out of a <blockquote> and 
> present it as a link underneath. But that still has accessibility 
> problems, because it doesn't work without JavaScript, and the resulting 
> link text is either a raw URL or the same text for every quote. These 
> problems make the technique even more unworkable for <q>.) As a result, 
> authors usually use an <a> link to the resource they're quoting (look at 
> most self-hosted Weblogs for examples), and there ends up being no 
> machine-readable connection between the link and the quote. This could 
> similarly be achieved in the <a> element with a for= attribute giving 
> the ID of the <blockquote> or <q> element.

Interesting idea.

> The majority of authors still wouldn't use these attributes, because it 
> would give them no presentational benefit. But at least authors would be 
> slightly more likely to use them than to use attributes that they have 
> to re-present using extra elements or JavaScript.

We should probably aim higher than that though...

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