472,958 Members | 1,752 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,958 software developers and data experts.

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></eminside 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
Jun 27 '08 #1
5 2950
In article <tF*********************@reader1.news.saunalahti.f i>,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

[...]
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/>
Jun 27 '08 #2
Sander Tekelenburg wrote:
In article <tF*********************@reader1.news.saunalahti.f i>,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

[...]
>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.
Jun 27 '08 #3
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/

Jun 27 '08 #4
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,

--
La Gris
Jun 27 '08 #5
In article <XY********************@reader1.news.saunalahti.fi >,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
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/>
Jun 27 '08 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Alex Billerey | last post by:
Hi folks, Not sure that syntax is the right term but anyway... I'm currently working a a new section of a website and I want to make it as accessible as possible - hence the accesskey. On each...
3
by: Jim | last post by:
Hi, How can one put an accesskey on a Select (Drop down box) in a form using XHTML 1.0? It wont validate as follows: <select accesskey="r" tabindex="3" name="state" size="1"> I can put an...
1
by: Manan | last post by:
hi All, I'm using a web application. On my .aspx pages I want to add shortcut keying option to textbox, dropdown, and button. I know i can use AccessKey to add shortcuts but I'm having problem...
0
by: david cheng | last post by:
I am trying to load the pdf document through AccessKey. Here is the code <HTML> <body bottomMargin="0" bgColor="gray" leftMargin="0" topMargin="0" rightMargin="0"> <form id="Form1"...
1
by: WJ | last post by:
How do I set the AccessKey property of a Web Label control on my Asp.Net ? Ex: Lebel Text Name is "Name", I like to see letter "N" underlined so that I can use ALT+N to force the system focus on...
1
by: Andre | last post by:
I've set up the accessKey for my Submit button to 'S'. The usual Windows method for letting the user know would be to underline the 'S' in Submit on the button text. How do I do this in the Text...
9
by: Udo Marx | last post by:
Greets to ciwah! I'm doing a little webproject for a local session event. Tryin' to meet latest standards i failed to do this: --snip-- <select name="fromcountry" accesskey="l" title="+">...
1
by: Csaba Gabor | last post by:
Short version: if the user types an alt+ctrl+char combination which leads to a defined character, but s/he's not in a input(text)/textarea, then I'd like that keystroke combination to do the same...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
0
by: Aliciasmith | last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
2
by: giovanniandrean | last post by:
The energy model is structured as follows and uses excel sheets to give input data: 1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
4
NeoPa
by: NeoPa | last post by:
Hello everyone. I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report). I know it can be done by selecting :...
3
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
1
by: Teri B | last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course. 0ne-to-many. One course many roles. Then I created a report based on the Course form and...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM) Please note that the UK and Europe revert to winter time on...
3
by: nia12 | last post by:
Hi there, I am very new to Access so apologies if any of this is obvious/not clear. I am creating a data collection tool for health care employees to complete. It consists of a number of...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.