Access Keys interlude
The access keys quiz left us roughly divided between those who use them for various reasons and those who do not. I want to explore the area more and look for ways of implementing access keys in ways that are more obvious and acceptable. The challenge will be yours to define those ways. Think about it a bit. When we come back to them, we’ll start with this article by Derek Featherstone.
April 20th, 2005 at 8:50 am
“I want to explore the area more and look for ways of implementing access keys in ways that are more obvious and acceptable.”
are we talking about User Agent Accessibility Guidelines now? changes to be made to the browsers? or are you suggesting non-standard (javascript?) based workarounds to be taken in Web Content?
April 20th, 2005 at 9:01 am
More out of laziness than that accesskeys are secondary, less-important navigation, I’ve mainly only used the title attribute to show the keyboard shortcut.
My feelings are that most users don’t know what accesskeys are even when they do discover them. We can underline the accesskey letter but most web users don’t know that it means the ALT key. So at the least a tooltip that says “Alt + 5″ is important for the user to understand.
Combined with some javascript you could underline the accesskey when the alt key is pressed which would mimic Windows.
A page to describe site-wide accesskeys should be included in any accessibility statement or linked from it to a special keyboard shortcuts page.
April 20th, 2005 at 11:01 am
Well … when I’m testing my sites with screenreaders the thing I use most often is “headings reading mode” - on a site that uses headings properly, this gives you a heirarchical overview of the whole page.
And I find myself wanting that in other browsers - it’s such a useful way of navigating page sections. If access points were always headings, and identified by ID, then both this and user-defined access keys could merge to form a very comprehensive page-specific navigation system.
I’d really like to see the headings-reading paradigm into mainstream desktop, PDA and other browsers. In the short terms things like page-based DOM scripts, userscripts and browser extensions can do this, while in the long term it would be nice to see it added by default, as many are doing now with LINK navigation toolbar
April 20th, 2005 at 6:25 pm
brothercake, incidentally i’m working on a tiny firefox extension to bring headings reading mode to the masses … watch this space :)
April 20th, 2005 at 9:03 pm
brothercake, J Graham has created the Document Map Sidebar Extension which provides a heirarchical overview of the whole page.
April 21st, 2005 at 5:13 am
The access attribute in XHTML 2.0 sounds very nice. Does it also mean things like “skip link” techniques are potentially not needed, or not as important, if User Agents handle this well?
April 25th, 2005 at 8:33 pm
Skip links still have their place—though checkpoint 13.6 does indicate W3C believe user agents should provide this functionality.
The scenario that comes to my mind is a person with switch access who can only activate a single button at a time. This is usually accompanied by software that moves focus around the page, application window and onscreen panel (representing the keyboard and some operating system controls). Let’s say there was an access key of “C” for content … there’s a huge menu of links you need to get through to reach the content, and activating the shortcut may require waiting for the focus to reach the “C” in the onscreen keyboard—whereas a skip link could have been right there where you needed it.
It’s hard to describe unless you have seen it … Maybe someone knows where there is an online demonstration of this type of assistive technology. It’s worth seeing in action. If you want to try something similar, limit yourself to the TAB and ENTER keys, and you can only press TAB once per second. Put some music on. Have fun :)