navigation control issues to be addressed by UA (was Re; ACCESSKEY in HTML on w3c-wai-pf)

aloha, y'all!

the following arose out of a thread on the member-confidential Protocols &
Formats emailing list, and, at the request of the chair of the UAWG, Jon
Gunderson, i am reposting my comments to the public UA list in order to start a
UA thread on the topic...  note that this message conflates the 3 messages
which i posted to w3c-wai-pf on this topic into one (hopefully unified and
coherent) message
        gregory.

--- FORWARDED MESSAGE ---
Date: Fri, 01 Oct 1999 12:51:03 -0400
To: Jon Gunderson <jongund@staff.uiuc.edu>
From: "Gregory J. Rosmaita" <unagi69@concentric.net>
Cc: WAI Protocols & Formats WG <w3c-wai-pf@w3.org>
Subject: Re: Accesskey in HTML

aloha, jon!

i think you formulated a pretty accurate list of dependencies with UA on this
issue...

here are some thoughts -- your comments are preceded by JG and mine by GJR

JG
>1. Author keyboard bindings and user agent default/custom keyboard bindings
>may conflict

GJR
UA needs a "pass-through" command that allows conflicting keystrokes to be
handled gracefully -- support for ACCESSKEY, as defined in the HTML4 rec, is
definitely not correctly implemented by any UA with which i am personally
familiar, and while i'm not sure that it is entirely the fault of the rec, i do
think it warrants some looking into by the PF WG...

implementation case in point IE5 -- it supports ACCESSKEY for (most) form
controls, but not consistently for the other elements, A and AREA,  for which
accesskey is a permissible attribute...

one strange thing about the IE5 implementation, however, is that IE5 seems to
give precedence to accesskeys, even when they conflict with application control
keys...  a case in point is the reformatted RFB&D catalog search form located
at:
        http://www.hicom.net/~oedipus/books/rfbd_form.html
where "v" is used as an accesskey in the hyperlink that defines the HTML
auto-validation button...  note: that IE5 simply moves focus to the element in
which the ACCESSKEY is defined isn't quite a violation of the HTML4 rec -- at
least
as it is currently formulated -- due to the proviso contained in the definition
of ACCESSKEY located at:
        http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accesskey
which states that quote when a user activates a link defined by the A element,
the user agent generally follows the link. unquote

so, the rec doesn't explicitly forbid the UA from only moving the focus or
system caret to the element in which the ACCESSKEY is defined when the
ACCESSKEY is invoked -- although, from the definition cited above, there is a
reasonable expectation that the UA should activate the element when it's
ACCESSKEY is invoked...

in any event, in the reformatted form whose URI is cited above, the accesskey v
is defined for the HTML auto-validation link which is physically located at the
bottom of the page...  ALT+V is also a standard windows keyboard convention 
for the keystroke which opens the "View" menu...  nevertheless, when the
reformatted RFB&D form is loaded, typing ALT+V moves the focus to the
auto-validation link, and does not open the "View" menu (you need to press the
ALT key and then press the V key sequentially, in order to open the "View" menu
while the page is loaded, which is, i suppose why Alan Cantor [amongst others]
advises using only the characters 0 through 9 as ACCESSKEYs)

on the reformatted RFB&D form, there is also an ACCESSKEY defined for the
character f, which is intended to provide the user with a quick mechanism with
which to jump directly to the form...  however, i can't get the ACCESSKEY f to
work with IE5 (the only browser i have access to which supports ACCESSKEY)

this may be a symptom of UA reluctance to part with a default keybinding  for
the ACCESSKEY for it simply does not work, no matter where i place it...  not
when i put it in a name anchor, as in:

        <A NAME="form" ACCESSKEY="f"></A>

nor when i inserted it in the hyperlink physically located near the top of the
page that jumps to the form, nor when i (thinking i was being clever) stuck it
in one of the INPUT TYPE="hidden" elements defined for the form...  (note: all
3 of these strategies validated as HTML4 against the W3C Validator)

in any event, the ACCESSKEY f does not function in IE5, and i don't know
whether that is just an IE bug, or if MSIE or Windows95 is preventing the
ACCESSKEY from being invoked because it is synonymous with a standard windows
application control keystroke... (note: in order to invoked the ACCESSKEY f
using IE5, it is necessary to hold down the ALT key and type f -- the same key
combination that is a standard windows keybinding for the "File" menu) 

all of which is a rather long-winded way of saying that, yes, ACCESSKEY should
be on the PF radar scope and needs to be re-addressed by PF -- and, in a
dependent manner, UA -- and, given the benefits of navigational controls such
as ACCESSKEY,  the sooner, the better

speaking of UA dependency, would it not also be appropriate to ask the UAWG to
either strengthen the priority level for
checkpoint 2.5 of the UAGL, or consider a sliding priority?

currently checkpoint 2.5 rates only a P2, but the ability to manipulate the
navigational structures / mechanisms -- such as ACCESSKEY, TABINDEX, and the
like -- which are built into HTML4, is clearly, at least in my opinion, a P1,
regardless of the modality or medium which is used to activate them...

here is the checkpoint in question, taken from the current (27 august 1999) UA
draft:

quote
2.5 Allow the user to turn on and off author-specified keyboard configurations.
[Priority 2] 
For example, in HTML, the author may specify tabbing order with the "tabindex"
attribute and keyboard bindings with the "accesskey" attribute.
unquote

at the very least, i'd say it would be a P1 for triple and double A compliance,
and P2 for single A, as these mechanisms endow the type of base functionality
towards which the UAGLs seem to be re-focusing...

and as long as we're re-opening the PF wish list, what about a means of
differentiating between a TABINDEX for FORM navigation and a TABINDEX for
hyperlinks?  on a page with many hyperlinks AND a form, such a distinction
would greatly enhance the navigational options available both to the author and
the end user of web content...

to return to Jon's original point -- that author defined keybindings may
conflict with UA or OS default slash custom keybindings -- aside from a
pass-through command, another possible solution is for the UA to generate an
active list of all navigational controls in the document, such as that advanced
by Al Gilman [a power-toy-like mechanism to expose a list of navigational
controls in the document] or that which i advanced as the second proposed
checkpoint in my post to the UA list archived at:
        http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html
and which Ian Jacobs refined in the post archived at:
        http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0395.html
the point being that in order to activate an accesskey or use a TABINDEXed form
or document successfully, the user must first know what the accesskey bindings
are for the currently loaded page, as well as the TABINDEX order defined for
the currently rendered page...

JG
>2. Author keyboard bindings behavior in the user agent. What should user
>agents do?

GJR
personally, i'd like to be able to choose between having the focus move to the
link and activating it -- something which the public beta of JFW 3.31 enables
the user to do with the JFW-generated list of links -- consult:
       http://www.hj.com/JFW/JFW331NEW.html#anchor99738
for more information...

i'm not sure whether or not that would also necessitate a means of
differentiating, at the markup level, between form control accesskeys
(move-to-and-activate keys) and strictly navigational accesskeys (move to a
discrete section or pre-defined point in the document), similar to the
differentiation i have advocated between a TABINDEX defined for moving between
form controls and the tabbing order of links...  why?  because if i use an
accesskey defined for a form control, i (9 times out of 10) want to activate
the form control (i.e. toggle the radio button, activate or deactivate the
checkbox, place the cursor in a INPUT TYPE="text" or TEXTAREA, etc.), while i
may only want to jump-to a link or anchor or AREA, and then decide whether or
not to follow the link based upon the contextual information surrounding the
link or anchor or area....

JG
>3. Visibility of author supplied keyboard bindings, how does a user know
>they are there?

GJR:
this is related to one of Harvey Bingham's pet peeves -- the inability of most
UAs to provide their users with a list of current and default keybindings... 
the UA should also allow the user to view a navigational tree, something which
could be addressed in UAGL checkpoints 8.4 and in GL9

-- begin inserted text not included in original PF post
when Jon emailed me to ask that i repost my comments to the UA list, he
included the following list of checkpoints which he had determined overlap my
concerns:

2.3 Provide information to the user about the current keyboard configuration.
[Priority 1] 
2.5 Allow the user to turn on and off author-specified keyboard configurations.
[Priority 2] 
7.1 Implement the accessibility features defined for supported specifications.
[Priority 1] 
-- end inserted text not included in original PF post / resume PF post

as an interim kludge, authors could be encouraged (via the WCAG as an "until
user agents support..." clause) to provide a link to a page which lists the
accesskeys for the current page, as i have done at:
        http://www.hicom.net/~oedipus/books/rfbd_form.html
(note: the accesskey for the link to the accesskey legend is k)

gregory.

Received on Friday, 1 October 1999 20:59:57 UTC