navigate link with accesskey

[mre]

Hi,

Hope this is the right place to post this. I mainly do HTML for IE -
so I don't know if anything I've asked here is IE specific, sorry if it
is.

If I give a link an accesskey, using that key only sets the focus of
the link - how can I get it to navigate the link instead? I've tried
creating an 'invisible' [width/height:0;position:absolute;] input
button with onclick event that uses the accesskey instead, but then
tabbing has these moments of unknown focus. Can anyone suggest a
fix/workaround for either of these dealies?

Also, just while I'm here, I can use <u></u> to 'show' a link's
access key, but is there any way to underline an input button's text,
as I have access keys for them too (this is unrelated to the question
above; these buttons won't be invisible)?

Thank you for your time/help
Regards,
MRe

 

[Steve Pugh]

Hope this is the right place to post this. I mainly do HTML for IE -
so I don't know if anything I've asked here is IE specific, sorry if it
is.

Are your pages on the web or not?

If I give a link an accesskey, using that key only sets the focus of
the link - how can I get it to navigate the link instead?

Use almost any browser except Windows IE. Most other implementations
of accesskey follow the link straightaway rather than merely move
focus to it.

I suppose you could use some JavaScript to do a
document.location="" when the link recieves focus, but that would
trigger the link when it's tabbed to as well. Not a good idea.

I've tried
creating an 'invisible' [width/height:0;position:absolute;] input
button with onclick event that uses the accesskey instead, but then
tabbing has these moments of unknown focus. Can anyone suggest a
fix/workaround for either of these dealies?

You can move the link to the start or end of the tab order with the
tabindex attribute.

Or you could tell us why you want invisible (to sighted users with CSS
switched on) links that are activated only via a keyboard shortcut
(unless CSS is disabled in which case anyone can use them). Maybe we
can suggest a better solution to the underlying issue.

Also, just while I'm here, I can use <u></u> to 'show' a link's
access key, but is there any way to underline an input button's text,
as I have access keys for them too (this is unrelated to the question
above; these buttons won't be invisible)?

You can make the button an image.
You can use a <button> element instead (watch out for browser
support).
You can use an ordinary link and use JavaScript to submit the form
(bad idea).
You can add a text label alongside the button.

On the other hand you might want to consider dropping accesskeys
altogether, they don't work very well and can actually harm rather
then help accessibility.

Steve

 

[mre]

Thank you for the response Steve, and in less than 10 minutes too, neat

Are your pages on the web or not?

Yes (on the web), but only accessible to our customers and hackers

Use almost any browser except Windows IE. Most other implementations
of accesskey follow the link straightaway rather than merely move
focus to it.

All our customers are required to have IE5.5 or greater, and they do -
so this cannot be changed unfortunately

I suppose you could use some JavaScript to do a
document.location="" when the link recieves focus, but...net/>[/QUOTE] Thank you again, Regards, MRe

 

[Dan]

All our customers are required to have IE5.5 or greater, and they do -
so this cannot be changed unfortunately

Sure it can... just author to Web standards and stop telling your
customers to downgrade to an inferior browser.

As I'm only supporting IE, this looks ideal. Thank you

So-called "Web developers" who only support IE should be executed by
firing squad.

 

[Philip Ronan]

If I give a link an accesskey, using that key only sets the focus of
the link - how can I get it to navigate the link instead?

Hold on, not even IE is *that* daft, surely? My version certainly has no
issues with access keys that I'm aware of.

Try validating your code at <http://validator.w3.org/>

 

[David Dorward]

Hold on, not even IE is *that* daft, surely? My version certainly has no
issues with access keys that I'm aware of.

That's normal behaviour for IE. Accesskeys send the focus to the link, you
can then hit enter to activate it. It allows for accesskeys to be reused so
you can cycle through them. Still screws around with keyboard access to the
browser menus though.

 

[Steve Pugh]

Hold on, not even IE is *that* daft, surely? My version certainly has no
issues with access keys that I'm aware of.

Do you use a Mac? On a Mac IE follows the link when CTRL+accesskey is
pressed but on Windows its ALT+accesskey (to focus on the link)
followed by ENTER (to follow the link).

Steve

 

[Steve Pugh]

Could I ask you to elaborate on this please?

All your users are required to use IE, let's further assume that
they're all on Windows and all using an English language version.
The following ALT+[key] shortcuts are used by IE itself:
F, E, V, A, T, H, D and likely some others. So you have to avoid those
in order to avoid conflicts. And when you add other languages and
other browsers into the mix the list gets much longer.

Even if they must all use IE, they may be using a screen reader on top
of IE, in which case the screen reader may use yet more keys.

In addition there are the issues you've already identified - how to
communicate the existance of the accesskeys to users and Win IE's
useless way of actually implementing them.

Steve

 

[mre]

Thank you again Steve for this...

Could I ask you to elaborate on this please?

All your users are required to use IE, let's further assume that
they're all on Windows and all using an English language version.
The following ALT+[key] shortcuts are used by IE itself:
F, E, V, A, T, H, D and likely some others. So you have to avoid those
in order to avoid conflicts. And when you add other languages and
other browsers into the mix the list gets much longer.

Even if they must all use IE, they may be using a screen reader on top
of IE, in which case the screen reader may use yet more keys.

In addition there are the issues you've already identified - how to
communicate the existance of the accesskeys to users and Win IE's
useless way of actually implementing them.

That kinda sucks, I may reconsider using them. The thing is, is the
project is a data entry shindig, and personally, I like having quick
access to the fields - I'll see how much hassle it gives me

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <[email protected]> <http://steve.pugh.net/>

Great help,
Kind regards,
MRe

 

[mre]

Do you use a Mac? On a Mac IE follows the link when CTRL+accesskey is
pressed but on Windows its ALT+accesskey (to focus on the link)
followed by ENTER (to follow the link).

It's on Windows so requires those two steps to success - I don't have
all day!

 

[mre]

Thanks for the response Dan...

do

Sure it can... just author to Web standards and stop telling your
customers to downgrade to an inferior browser.

It's not a web page - it's an application that needs IE to run; so it
has no need to follow web standards. Also, most, if not all, our
customers already had IE to begin with, so for them, it wasn't so much
a matter of telling them to downgrade as telling them to do nothing.

So-called "Web developers" who only support IE should be executed by
firing squad.

Surly that depends on the type of web being developed for. For the
private/specialised/application type (like I'm working on), I would say
it's tomatoes, potatoes - For a WWW type one, then the terms seem to me
as mutually exclusive; you can only be developing for IE, or for WWW,
and if someone wandering around the WWW happens to land on the IE web
page, then tough, get outta here! What If I was to wander around a
ladies lavatory, I would become confused and disorientated and would
have to leave, just like a browser in the page not supporting it; but I
see no reason to hate - the ladies need somewhere to hang-out too! No?

Regards,
MRe