Re: Standard access keys?

OK, so we seem to disagree on a lot of things.

I don't think blind users are the primary reason for requiring keyboard 
navigation, either in terms of need (there are plenty of people with 
disabilities that stop them using the mouse for all practical purposes, 
and blind people occasionally *do* use mice). Accessibility that is 
*only* for people with visual impairment is a pretty limited view, and 
certainly not what W3C promotes.

Accesskey provides a flexible, adaptable mechanism that allows for 
every webmaster and their cousin to develop a new kind of page or 
service on the web and assign a quick mnemonic way of using it to help 
expert keyboard users, people who have to use the keyboard, etc. When 
combined with a visual rendering to explain what the keys are (like 
iCab does) it is an extremely powerful aid. When a list of available 
accesskeys is provided (as Opera does) the same is true, and it is more 
likely to help people with visual impairment.

It is only when browsers provide patchy access to the keys that there 
is a problem. On Windows both Opera and Explorer reserve the alt-F key 
for the file menu, following the Windows platform standards. But one 
browser is intelligent enough to recognise that there needs to be a way 
of activating an accesskey, and that alt-F isn't the only possible 
activation for something where the mnemonic is 'F'. (iCab gets around 
this by making the entire keyboard available - something that Opera 
can't do. And to be fai to IE, they recognised before most others that 
accesskey is valuable, and implemented it 3 ways in 3 versions before 
settling on their idea of optimal).

In some browsers it still has a shaky implementation. But it does work, 
does things that rel can't do, and is therefore valuable. (rel is for 
standard links, accesskey is for things that are standard to a page or 
site but not really standard or standardisable across the Web).

On the other hand I am completely in agreement about the fact that a 
"skip nav" link is a wierd hack (like d-link) that there are sensible 
ways to render obsolete using existing technology and new practice.

cheers

chaals

On Saturday, Aug 30, 2003, at 05:09 Australia/Sydney, John Foliot - 
bytown internet wrote:

> Hang on a second... I specifically said "...the *primary* (not 
> exclusive)
> reason for providing keyboard based navigation..."
>
> I concede the fact that others will also benefit from the concept of
> Accesskeys - in fact I always argue that universal accessibility is 
> MORE
> than just serving the blind/visually impaired.  The issue is more to 
> do with
> the fact that every webmaster and his cousin has a different idea of 
> what
> "intuitive" Accesskeys should be.  Some use numbers, others letters, 
> another
> a combination of the two.  Couple this with the fact that the majority 
> of
> viable keystroke combinations have already been usurped by other
> technologies and it's just too late.  With millions of web sites out 
> there
> (the majority without any Accesskeys at all) I think the train has 
> already
> left the station.
>
> So my real point was - abandon Accesskeys.  Look to another mechanism 
> to
> provide the same basic functionality that Accesskeys delivers without 
> the
> attendant mess and potential problems.
>
> The relative link scheme is already standardized, in that the 
> following:
> Start, Next, Prev, Contents, Index, Glossary, Copyright, Chapter, 
> Section,
> Subsection, Appendix, Help, Bookmark
> - have all been previously established.  If developers (and perhaps 
> WCAG
> v2?) adhered to these *existing* standards (nay - pushed for their 
> better
> implementation/adoption - Jeffery Zeldman, do you read this list?), 
> then
> various technologies (adaptive or otherwise) would be able to "map"
> themselves to those elements.  It allows the user/software to 
> standardize
> keystroke combinations rather than you, me and my great uncle Fred, all
> building web sites using different concepts of "intuitive" keystrokes,
> and/or alternative keyboards or operating systems.
>
> Consider the following:  Currently, the US Section 508 requires a 
> "skip nav"
> be place at the literal top of each web document.  This is because, 
> from a
> linear perspective, most web pages have their principle and often 
> secondary
> navigation ahead of the actual content of the page.  Thus, providing a
> mechanism to "skip over" these links makes sense from a
> usability/accessibility standpoint.  However, with proper use of CSS, 
> there
> really is no real reason to not place your navigation at the "end" of 
> your
> linear document, but style the <div> to "appear" at the top or left 
> side (as
> taste and design dictates).  From the usability/accessibility 
> perspective,
> once a user has "explored" the navigation scheme they really don't 
> need it
> again until they want to move on; therefore serving up the "content" 
> first
> makes better sense.
>
> The Link Rel scheme allows us to use:
> "<link rel="Contents" title="Site Navigation" href="#nav" />" (Contents
> "Refers to a document serving as a table of contents. Some user agents 
> also
> support the synonym ToC (from "Table of Contents")" -
> http://www.w3.org/TR/REC-html40/types.html#type-links).
>
> Now if everybody used this element consistently (<link 
> rel="contents"...>)
> how difficult would it be to start to map user agents to that unique
> element? Mapping a standardized stroke to this then would instantly 
> put the
> navigational block (<div>?) into the "hands" of the end user.  If his
> software is set up so that Ctrl+G *always* delivered him to the 
> navigation,
> don't you think that this would be more useful.  No need for "skip 
> nav", no
> need for "skip to nav", just a mapped keystroke in <useragent of 
> choice>.
>
> Sometimes things are just too broken to fix.  I continue to maintain 
> that
> Accesskeys are too broken.
>
--
Charles McCathieNevile                          Fundación Sidar
charles@sidar.org                                http://www.sidar.org

Received on Friday, 29 August 2003 21:09:27 UTC