On Sun, 12 Jun 2005 12:52:25 +0200, Ian Hickson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
hablo español - je parle français - jeg lærer norsk
Here's one we prepared earlier: http://www.opera.com/download
