RE: Standard access keys?

Carl,

As Chaals points out, there *is* a standard already in place for providing a
basic "uber-navigation" to any site, the relative link
(http://www.w3.org/TR/REC-html40/types.html#type-links); "User agents,
search engines, etc. may interpret these link types in a variety of ways.
For example, user agents may provide access to linked documents through a
navigation bar." The fact that not all browsers properly support the
standard is too bad, but currently Opera 7 has some implementation, as does
the latest builds from Mozilla (curiously it seems absent from Netscape 7),
and the oft maligned but rock-steady Lynx browser, (to name 3 that I am
aware of).  We are currently employing this at our web site (www.wats.ca)

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.

Thing is, for how many years now, most if not all web developers have
essentially ignored the Accesskey attribute... heck there are still those
out there ignoring CSS.  And so, the developers of the screen reading
software took it upon themselves to implement functionality above and beyond
what the web page developers were implementing.  Thus tools like JAWS,
HomePageReader and WindowEyes have pre-assigned keyboard shortcuts which
allow the user to achieve much if not all of the functionality that you are
now seeking to implement with Accesskeys.  But, (and this is the big but),
because it is software based, the end user has a greater assurance that it
will work consistently across all sites, not just those "crafted" with the
developers idea of what the navigational scheme should be.

For example, in JAWS (which most will concede is the "Coca-Cola" of screen
readers), users can bring up lists of Headers in a page (INSERT + F6, *and*
it implements a system where-by the Headers act essentially as named
anchors, allowing inter-page navigation), a list of links in a page (INSERT
+ F7, ordered either alphabetically or chronologically), and so on. (A list
of keyboard shortcuts associated to JAWS may be found at
http://wats.ca/resources/jawskeystrokes/9, IBM HomePageReader shortcuts at:
http://wats.ca/resources/accesskeys/19; we're currently working on
WindowEyes and Lynx keystrokes charts).  Because of this, structurally valid
(i.e. Semantically valid) code allows the users of these tools to seek out
and access the information they are coming to your page for, with no extra
effort or "magic" on your end.

Don't get me wrong, the *idea* of Accesskeys, when added to the HTML spec,
is/was a good one.  However, due to it's lack of universal implementation,
and the fact that there are differing keyboards out there (as Chaals points
out), conflicting keystroke combinations which may or may not be over-ridden
by other technologies/software, alternative means of achieving the desired
result, etc., etc.,.... well, it reaches a point that attempting to add
Accesskeys may in fact be detrimental to the end result.  As you have
pointed out:

> > Until we get to the stage where access keys for websites are this
> > consistent, surely the access keys themselves are not going to help
> > much.

Unfortunately, methinks we have come and gone beyond this point.  The jury
is already out, and Accesskeys seems to be left by the wayside.  I would
argue that the Accessibility community should push instead for wider and
more standard implementation of the other existing standard, the relative
link, at both the development end (our jobs) and at the implementation end
(the web browser's job).  If the usage of the established <link rel>
elements became more accepted and used, those adaptive technologies which
take advantage of keystroke combinations could internally "standardize"
their usage - remember, "User agents, search engines, etc. may interpret
these link types in a variety of ways.".  IMHO, it's still not too late to
resurrect the <link rel> attribute, and lists and groups such as this should
push for it instead of trying to put the Accesskey genie back into the
bottle.

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: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Charles McCathieNevile
> Sent: Friday, August 29, 2003 12:56 AM
> To: carl.myhill@ps.ge.com
> Cc: w3c-wai-ig@w3.org
> Subject: Re: Standard access keys?
>
>
>
> There is a standard here, which is the rel attribute, as applied to the
> link or a element - it means that a user can expect their browser to
> provide a consistent way of navigating important links that is part of
> the browser.
>
> Accesskey provides a mechanism for extending that in a particular way -
> identifying the controls used on a particular page that are frequent
> navigation stops (login, current status, top of the page, find the
> nearest physical contact, cheapest option are all candidates in work I
> am currently doing, which is quite different to the ones I wanted to
> have a year ago).
>
> In situations where people are using different keyboards, and making
> millions of websites, it seems hard to pick the 40 or so most common
> keys and functions. When I use the arabic keyboard I don't have the
> unicode characters "0123456789" readily available, nor any of the
> letters "abcdefghijklmnopqrstuvwxyz", so anything that relies on those
> to make life easier doesn't work. (But I have control characters
> available, which means I can use system-standard shortcuts).
>
> If there is a convention compatible with what you need then using it is
> better than creating something different. But there are limits to what
> can be achieved...
>
> cheers
>
> Chaals
>
> On Thursday, Aug 28, 2003, at 21:00 Australia/Sydney,
> carl.myhill@ps.ge.com wrote:
>
> >
> > Thanks for the input on this.
> >
> > I'm afraid I find it a bit outrageous that there is not a standard
> > quickly
> > emerging here.  On most Windows Apps, and on the Mac too, there are
> > well
> > defined standards for the basic shortcuts that are pretty much always
> > dependable (unless you use EMACS) ...
> > F1
> > Ctrl+S
> > Ctrl+N
> > Ctrl+C
> > Ctrl+V
> > Ctrl+X
> >
> > Until we get to the stage where access keys for websites are this
> > consistent, surely the access keys themselves are not going to help
> > much.
> > If a disabled user knows that 'Alt+S' will always be the key to skip
> > navigation on a site that has access keys, this is effective. If they
> > need
> > to learn what the access keys are for each website - it would seem to
> > be
> > more in the way of accessibility than aiding it.
> >
> > I've adopted the UK government guidelines because they seem to be
> > bedding in
> > as a kind of standard (although the analysis here
> > http://www.clagnut.com/blog/193/ shows the limitations and conflicts
> > with
> > other standards).  The UK government publishing folks are generally
> > pretty
> > sensitive to multi-cultural needs of our society so I am not worried
> > about
> > country specificness here.
> >
> > I don't personally think much of using numbers for access keys because
> > they
> > are not as meaningful as letters. It seems easier to me to remember
> > Alt+S is
> > for 'skip'. However, this is an English only view of the world, so
> > numbers
> > would seem to be more univeral.
> >
> > www.aquariusclub.net
> >
> > I'm not building a website for anyone with any particular needs. I
> > want my
> > design, and others, to be universal. So, I'm making my access keys
> > visible
> > on screen and accepting that it makes the design look slightly strange.
> > Perhaps this is good strange - like buildings that once had grand
> > steps to
> > the door and now have a ramp. It might not look pretty but why exclude
> > people when you don't really need to.
> >
> > I feel quite strongly about this - is there a formal way to elevate
> > such
> > issues to the WAI formerly? This would seem to need sorting out
> > internationally.
> >
> > Carl
> >
> >
> --
> Charles McCathieNevile                          Fundación Sidar
> charles@sidar.org                                http://www.sidar.org
>
>
>
>

Received on Friday, 29 August 2003 09:44:50 UTC