highlighting an accesskey

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/

In article <tFtNj.327194$bc6.139693 (AT) reader1 (DOT) news.saunalahti.fi>,
"Jukka K. Korpela" <jkorpela (AT) cs (DOT) 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. In that same book browser bugs should be repaired by
browser vendors, not by web publishers. The more web publishers use
accesskey, the more users afected, the more likely browser vendors will
bother to fix the bug. Thus this could be considered an argument for
using accesskey...

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 )

--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>

Sander Tekelenburg wrote:

In article <tFtNj.327194$bc6.139693 (AT) reader1 (DOT) news.saunalahti.fi>,
"Jukka K. Korpela" <jkorpela (AT) cs (DOT) 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

In article <XYZNj.327824$yc7.91790 (AT) reader1 (DOT) news.saunalahti.fi>,
"Jukka K. Korpela" <jkorpela (AT) cs (DOT) tut.fi> wrote:

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.

iCab provided non-hijackable accesskey support about 10 years ago
already. I thought Opera does too, since about 5.0 or 6.0, by providing
a mode change. Modes aren't exactly for everyone, but at least this
shows that an impementation that keeps the user in control is possible.

The HTML specification is naive in its assumptions

Agreed. It doesn't say UAs are required to implement that naively though.

[...]

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

Depends on the implementation. Why should ones that don't generate
problems disappear?

Mind you, in my opinion providing keyboard accessibility isn't something
web publishers should be burdened with in the first place. The spec's
"Authors should consider the input method of the expected reader when
specifying an accesskey" is probably the worst bit it has to say on
accesskey -- authors should not target a specific browsing environment.

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.

{shrug} I'm just being realistic. Web publishers cannot predict in which
browsing environment their documents will be consumed and therefore
*cannot* solve these sorts of problems.

I believe that the only way the Web will ever become a realiable tool is
when [1] users demand better UAs and [2] authors demand better authoring
tools. (I'm trying to help improve the situation regarding the latter:
<http://webrepair.org/>.) Users will only demand better UAs when they
are confronted with obvious problems. Therefore, authors hiding those
problems from users does nothing to improve the situation.

According to it, should we
start pushing vendors into implementing at least HTML 2.0?

I wouldn't mind seeing usable cross browser support for @rel. (See
<http://www.euronet.nl/~tekelenb/WWW/LINK/>.)

--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>