Hello,

Are there any generic and CSS standard mean of highlighting an accesskey?

I only fond a workaround by encapsulating the corresponding letter in a
<em></em> inside the label. But it is not applicable for a submit button
which label is not a content.

Here is en example:
<form method="get" action="http://example.com/cgi-bin/smokeping.cgi"
enctype="multipart/form-data" id="rangeform">
<fieldset><legend>Time range:</legend>
<label for="start"><em>F</em>rom:</label>
<input type="text" name="start" tabindex="1" value="2008-04-16
11:22" accesskey="f" id="start" />
<label for="end"><em>T</em>o:</label>
<input type="text" name="end" tabindex="2" value="now"
accesskey="t" id="end" />
<input type="hidden" name="target" value="World.Europe.France.IPv6" />
<input type="hidden" name="displaymode" value="n" />
<input type="submit" tabindex="3" name="Generate!"
value="Generate!" accesskey="g" />
</fieldset>
</form>

There would also exist another unsatisfying possibility with CSS:

input:before { content: attr(accesskey); }

But it would display the accesskey outside the label and before or after
the input field. Furthermore, there are few compatible browsers.

Regards,

--
Léa Gris

Scripsit Lea GRIS:

> Are there any generic and CSS standard mean of highlighting an
> accesskey?

That would be a CSS question, not HTML, right? The answer is "no", by
the way, but that's off-topic.

The HTML side of the matter is that accesskeys, as defined in HTML, are
mostly useless or worse than useless, partly because they may interfere
with browser or system accesskey assignments that users are familiar
with and may really need.

So just forget them. And you (your users) don't need tabindex either, if
your form fields are in a logical order, as they whould.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Sander Tekelenburg wrote:
> In article <tFtNj.327194$bc6.139693@reader1.news.saunalahti.f i>,
> "Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:
>
> [...]
>
>> The HTML side of the matter is that accesskeys, as defined in HTML,
>> are mostly useless or worse than useless, partly because they may
>> interfere with browser or system accesskey assignments that users
>> are familiar with and may really need.
>
> In my book letting a site hi-jack browser functionality would count
> as a browser bug.

It's a feature provided by the HTML standard, so whatever you may think
of it, it isn't a bug for a browser to implement it.

> IMO a more valid argument against acceskey is that it's a per site
> solution for something that ought to have a cross site solution.
> (Yep, browser vendors again )

How can you have a cross-site solution for something that is inherently
site-specific? That isn't the problem with access keys, any more than
it's a problem that the same Ctrl key combination will serve different
purposes in different OS windows.

Scripsit Sander Tekelenburg:

> In my book letting a site hi-jack browser functionality would count
> as a browser bug.

Well, maybe, and browsers _could_ actually implement accesskeys in a
manner that does not do that, but they don't. The HTML specification is
naive in its assumptions, pretending that browsers could recognize Alt+F
as a shortcut for a page-defined accesskey, as if Alt+F were not bound
to some function in most situations (and that users could use
page-defined accesskeys and would want to do that).

> In that same book browser bugs should be repaired by
> browser vendors, not by web publishers.

The fundamental flaw is in the specifications. The best browsers could
do now is to stop recognizing accesskey attributes at all.

> The more web publishers use
> accesskey, the more users afected, the more likely browser vendors
> will bother to fix the bug.

You seem to advocate a catastrophe theory. According to it, should we
start pushing vendors into implementing at least HTML 2.0? That is,
should we use all the SGML features defined in specifications HTML 2.0
through HTML 4.01, like <title/foo/ for a title element? Or should we be
modern and use native XHTML, _without_ dirty Appendix C trickery, and
naturally sending application/xhtml+xml to everyone?

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela a écrit :
> Scripsit Sander Tekelenburg:
>
>> In my book letting a site hi-jack browser functionality would count
>> as a browser bug.
>
> Well, maybe, and browsers _could_ actually implement accesskeys in a
> manner that does not do that, but they don't. The HTML specification is
> naive in its assumptions, pretending that browsers could recognize Alt+F
> as a shortcut for a page-defined accesskey, as if Alt+F were not bound
> to some function in most situations (and that users could use
> page-defined accesskeys and would want to do that).

IMHO: The most able browser in handling accesskey is Opera (Taype ESC
key then it display all shortcuts and corresponding accesskey to hit).

Firefox is quite inconsistant across versions. Prior to vrsion 2 it used
ALT+accesskey, wich could conflict with system shortcuts. Since version
2, it handle it by SHIFT+ALT+accesskey, ahthough it is user settalble, I
like much the Opra way of handling it.

To go back about highlighting the shortcuts, I managed to do it that way :

<http://meumeu/cgi-bin/smokeping.cgi?displaymode=n;start=2008-04-19%2012:05;end=now;target=World.Europe.France.Free >

Regards,

--
Léa Gris