[whatwg] Context help in Web Forms

On Sun, 12 Jun 2005 12:52:25 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 11 Jun 2005, Charles McCathieNevile wrote:

> 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="".

No, this is a misreading of what we were saying. In the late 1990s there  
was no support for longdesc, so authors were encouraged to *also* use a  
redundant D-link.

> 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.

This will be reviewed. The "object" model is generally considered more  
useful. But it depends to some extent on the tools available - being able  
to recognise an image from a description is an important use case for a  
small group of people dealing with a small number of situations - many  
more than 3, but many fewer than everyone - since most people recognise  
the image by seeing it.

> IMHO, "longdesc" is useless. About 3 people on the planet use it. Sure,
> theoretically it could be useful,

It is, in practice, useful. Unfortunately like many of the harder things  
in producing standards-compliant accessible content, there is indeed a  
poor track record of usage.

> 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.

The expectation of it working is based on whether the browser implements  
it. And so far, the failure has been on the browser side - there are  
extensions available for Firefox and Opera, and iCab implements it  
properly (but is a useless browser for the primary group who benefits due  
to assorted other issues). So it is more surprising that there are users  
for it even in the current state of browser development.

Discoverability in this case doesn't seem to me a primary issue. It is a  
relatively small target audience, and the more generic aspects of its use  
are to do with machine-processing the web, where presence in reliably  
treatable code is sufficient discoverability. It isn't going to become  
massively prevalent any time soon, but this isn't the sole measure of  
effectiveness.

As it happens the current Opera solution is to make the link clearly  
discoverable *for those who want it*. Firefox (via an extension) and iCab  
make it available in a context menu. There will be different solutions  
which are more appropriate for different users, and many users will never  
care about this at all.

>> One of the difficulties is that many content providers don't want to
>> "clutter their page with help links"
>
> 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.

You are right that many sites *do* have help links present in the page.  
Some even try to have them on a per question basis. There is in fact an  
accessibility cost in this for some users (the huge difficulty with  
getting accessibility right is that it is a very heterogenous, and at  
times *apparently* conflicting set of user requirements). There are others  
who don't. The implementation of the contexthelp attribute was driven by  
the US Treasury, whose audience must measure in millions or tens of  
millions (I don't know how many US taxpayers read information online  
around April each year, when they have to file their returns, but I would  
guess it is a very large number indeed). They were unwilling to add all  
the visible links. There are many others who believe that all those extra  
links are clutter.

I think you and I agree that in fact having them explicit and clearly  
discoverable is valuable. That doesn't change the fact that there are many  
designers who do look for a way to hide the help, while making it  
accessible to screen reader users, or similar. They tend to use CSS tricks  
at the moment, some of which defeat their goals quite neatly, others of  
which complicate sites endlessly, and some of which seem to work.

> 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.

Cool. The idea is that the thing is really reliably discoverable -  
otherwise authors will come up with something that makes sense but breaks  
the implicit model that the spec is built on. I am actually not sure that  
we mean the same thing when we say "nearest" but I will talk to you off  
the list about that to clarify that in my mind :-)

cheers

Chaals

-- 
Charles McCathieNevile                              chaals at opera.com
          hablo espa?ol - je parle fran?ais - jeg l?rer norsk
   Here's one we prepared earlier:   http://www.opera.com/download

Received on Sunday, 12 June 2005 05:05:02 UTC