WebAIM - Web Accessibility In Mind

E-mail List Archives

@key (was RE: looking for html technique toprovideamethodtoskiprepetitive navigation links)

for

From: John Foliot
Date: Oct 13, 2006 12:30PM

Alastair Campbell wrote:
> John Foliot wrote:
>> I am still fuming
>> about the addition of @key to XHTML 2 - has no-one learned?
>
> Have you seen the ARIA roadmap? It defines within page navigation
> using the role element in XHTML 2.0:
> http://www.w3.org/TR/2006/WD-aria-roadmap-20060926/#landmarks
>
> I haven't caught up on XHTML 2 yet, but that might make the @key
> redundant?

Well, yes, this is sort of both the point and the problem.

The mechanism of @role *should* make this type of interpage navigation a
breeze, as all content authors need to do is declare the role of the
container (<div>, <ul>, whatever) and then the rendering tools (User Agents,
or User Agents with AT), will take over for processing.


So, what you could have is a situation like:

<ul role="navigation">
<li>Home</li>
<li>About</li>
<li>Search</li>
<li>Contact Us</li>
</ul>

...and because "navigation" is part of the common collection, UA's could
ship "out of the box" with pre-configured key-bindings. Different UA's
*might* map different keys (and certainly the conflict that exists today
could still exist), but at least within a common user-seat a user would know
that [modifier-key + key = "go to navigation"]; and because content authors
are declaring the role, not the key, it would work on every site.

As well, end users could also re-map whatever keystroke they wanted (ala
Opera) to the "common collection" of roles that are being defined (and I
keep wondering out loud if the current draft common collection is enough
[http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-roleAttribute.html#col_Rol
e], but I digress).

So this is way cool!

However, the current situation is such that with @key, content authors can
once again presume to guess what the best key is, so that within the "legal"
specification, authors could go:

<ul role="navigation" key="f">
<li>Home</li>
<li>About</li>
<li>Search</li>
<li>Contact Us</li>
</ul>

Now, one of the assumptions is that the modifier key will continue to be
ALT, and if that is the case, then we have the continued problem with ALT +
F: it has already been taken by another application thank-you-very-much, and
so we have a conflict. And while there is talk (but still nothing in
writing) about a cascade style default scheme that goes:

author specified bindings take precedence
<else> program specified bindings take precedence (which addresses
AT natively)
<else> content author specified bindings are used

...this forgets to address one key point: if the content author states in
their page prose (accessibility statement?) that "To skip quickly to the
navigation use ALT+F" and it doesn't work, then what? What impact does this
have on those with cognitive challenges? And despite my one-man out-cry
(did somebody say hobby-horse), there does not seem to be any discussion on
this topic.

If we have given content authors the ability to declare intent, why must we
continue to also allow them to control the user experience - to me, this
flies in the face of one of the basics of what we preach - to *not* try and
out-guess our end users.

But I will step down of my soap box now and get back to work.

Cheers!

JF
---
John Foliot

*STANDARD DISCLAIMER ABOUT MY OPINIONS BEING MINE AND NOT MY EMPLOYERS -
BLAH BLAH*

Academic Technology Specialist
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
560 Escondido Mall
Meyer Library 181
Stanford, CA 94305-3093