FW: Standard access keys?

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.

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)




> -----Original Message-----
> From: WebSavvy [mailto:web.savvy@utoronto.ca]
> Sent: Friday, August 29, 2003 1:50 PM
> To: Charles McCathieNevile
> Cc: John Foliot - WATS.ca; carl.myhill@ps.ge.com; w3c-wai-ig@w3.org
> Subject: Re: Standard access keys?
>
>
>
> Chaals said:
>
> >
> > In which case I think people are doing the right thing for the wrong
> > reason. I believe the number of people who have difficulties using a
> > mouse is predominantly people other than those who are visually
> impaired.
>
> Indeed accesskeys are more suited for people with physical limitations
> who might have trouble positioning a mouse pointer, but a small set can
> also be helpful for blind users (e.g. 1=home, c=top of content, s=submit).
>
> We use a set of 15 accesskeys in ATutor (atutor.ca) which make it
> possible to use the system effectively without ever having to use a
> mouse. Adhering to suggested standards for accesskeys wasn't really an
> option for us, so our strategy has been to assign numbers and a small
> set of letters to key tools and navigation elements in a way that would
> be memorable (and discoverable) and would enhance the usability of each
> application for keyboard users.
>
> >
> > Accesskey is  an important functionality for people who have
> > difficulties with providing input. Lots of them aren't people with
> > visual disability.
>
>  From a curbcut perspective, a well thought out set of accesskeys can
> make navigation through complex information more efficient than it would
> be if a mouse were used alone, appealing to expert keyboard users and a
> broader population without disabilities.
>
> >
> >
> > On Friday, Aug 29, 2003, at 23:44 Australia/Sydney, John Foliot -
> > WATS.ca wrote:
> >
> >> But consider for a moment the *primary* (not exclusive) reason for
> >> providing
> >> keyboard based navigation through a web site.  When queried, most
> >> developers
> >> will say that it assists visually impaired users, which is certainly
> >> true.
> >> Oh ya, others may benefit from it (mobile devices, mobility impaired
> >> users,
> >> etc.), but this seems to be the major reason for implementation.
> >>
> greg
>
>
>
>

Received on Friday, 29 August 2003 15:16:12 UTC