RE: [WebAIM] More data on accesskeys (New article written Nov. 1)

Lachlan Hunt wrote:
> you might be interested to know
> that the (X)HTML 5 draft currently does not include accesskey for
> links. 
> 
> http://www.whatwg.org/specs/web-apps/current-work/#the-a
> http://www.whatwg.org/specs/web-apps/current-work/#the-link
> 
> Although, for some reason, it's still included for form controls, but
> I don't know why yet.

Lachlan,

First, thanks for this.. I will investigate further, especially in light of
TBL's announcement this past weekend.


> 
> We'd really appreciate feedback and
> suggestions, particularly about the accessibility enhancements.
> 
> http://www.whatwg.org/mailing-list

Great, another list! Sure, I'll wander over and sign up

> 
>> Is there anybody out there comfortable enough to hack a modified DTD
>> together so that @role could validate today?
> 
> Does it really matter that much?  DTD based validation is just a tool,
> and just because it reports an unknown attribute, it's not going to
> affect the accessibility of the site.

I don't disagree with you, but the issue is linked more with policy
requirements and institutional mandates.  In the absence of any real
standard, WCAG 1 (and specifically Priority 2) compliance is being
referenced as a base line, and in at least one instance that I know of
(Canadian Federal Common Look and Feel Standard) *mandated* as the minimum
requirement.  WCAG 1 P2 - 3.2 calls for validation to a published formal
grammar.  So while the merit of this requirement can stand debate, for
developers who have no option but to follow the guidelines, they could not
include @role today, even if browser support existed, without a
corresponding DTD to validate against.  It has as much to do with risk
management (lawyers and other bean-counters) as it does true accessibility,
but having worked with well meaning and hard working Canadian Federal web
developers in the past, I can appreciate their pain as well.

If @role is going to be adopted as a "standard", then surely inclusion into
a DTD is part of that process.  Jon Gunderson's toolbar is a proof of
concept implementation of @role that shows today how it works, but the test
cases cannot as yet validate (*) - meaning that forward thinking, concerned
developers who might use @role for the benefits it should and will bring,
can't today.

(* at least, I cannot ensure that it is valid using the tools at my
disposal, being the W3C and WDG validators)

> 
> Andy Mabbett wrote:
>> 
>>         <link rel="home" href="http://www.example.com/index.htm">
>>         <link rel="search" href="http://www.example.com/search.htm">
> 
> I agree with the concept, but I don't agree with using the <link>
> element. 


Why, or why not?  Inter-page navigation (such that accesskeys are supposedly
there to provide) are links relative to the page in view.  From a formal
perspective, it is correct terminology (to me).  More importantly, they
exist in the specs today, they are just poorly used (if ever), and have
minimum support from the browser makers.  But if we were to add the semantic
richness that @role is advertised as providing, then they would make the
relative links meaningful.  I've always supported the concept of @role,
although questioned privately why we even need ACCESS - to me it seem a bit
of a re-invention of the wheel.  In my lengthy objection to the XHTML2
authors [http://www.wats.ca/show.php?contentid=47] (and in numerous postings
outside of that) I have always used the mantra - "Declare the intent and
leave the keybinding to the end user".  I still believe this to be true
today, and that @role is the mechanism to declare the intent.

Consider:

	<link rel="home" href="http://www.example.com/index.htm"
Title="Home" role="home">
	<link rel="index" href="http://www.example.com/index.htm#nav"
Title="Navigation" role="navigation">
	<link rel="contents" href="http://www.example.com/index.htm#content"
Title="Main Content" role="content">
	<link rel="bookmark" href="http://www.example.com/index.htm#blog"
Title="Daily Blog" role="RSSfeed">
		 /* in page content itself, not the actual RSS feed, which,
is already referenced via a relative link <grin>  */
	<link rel="bookmark" href="http://www.example.com/search.php"
Title="Search this site" role="search">
	<link rel="copyright" href="http://www.example.com/index.htm#footer"
Title="Copyright and Other Polices" role="policies">

Everything above (with the exception of @role) would validate as HTML4.1
(!!), and/but with the small addition of @role values (so like microformats
today), you've extended discoverable meaning to the relative links.  You
could write a simple Firefox extension for this, Chaals would be smiling (as
Opera supports relative links now), and future user-agents could implement
this with I suspect little overhead.

> 
> The following list of access keys has been taken from Gez's recent
> article.  Along with each, I describe a suggestion for how it can
> already be hanlded using HTML4 markup or the drafted HTML5 markup.

<snip>

Lachlan, the "issue" with the UK standardized list of accesskeys (which are
the ones referenced) is that they do not allow for conflict resolution, and
in some instances conflict with keybindings already reserved for various
adaptive technologies. (Once again:
http://www.wats.ca/show.php?contentid=43)  In one instance ("S"), the
keystroke declaration would be problematic in user-agents such as a cell
phone that lacks a full keyboard... Oh, sure, you could probably work it out
(Q-R-S-7), but that is hardly useful, usable or productive. It also has a
specific conflict with IBM HomePageReader (settings) and the laptop
configuration of JAWS (screen echo).  

But if I declared the "role" of navigation and content (divs) but left it to
the cell phone or what-have-you to do the mapping internally, well then
you've made that functionality useful beyond just the desktop.  And in
user-agents like Opera today, you could conceivably even customize the
keybinding to your wishes... Lachlan if *every* website declared the role of
"search", you could then map your personal browser so that ALT+Ctrl+Shft+F7
brought you to search - every time, every site (not that you would want such
an easy to remember binding, but the point is made).  Instead, what we have
is a situation where authors go about declaring accesskeys for Search in any
manner they wish, and can use any keystroke they wish: S for Search, Q for
query, B for Búsqueda...

I'll jump back in here:

> 
>    <nav>
>      <menu>
>        ...
>        <li><a href="/help" rel="help">Help</a>
>      </menu>
>    </nav>

Role, rel - rel, role?  Rel to me means relationship (or relative - as in it
relates to), which is not incorrect in this example, but the "role" it plays
for the end user is slightly different - we're talking shades of grey here I
admit, but still - what it is vs. what it does.

However, I think what is more important than the rel/role debate is the
concept of a 'standardized' list beyond that which exists today for the
relative link [http://www.w3.org/TR/html4/types.html#idx-link_type], which
is essentially what you are alluding to here.  A listing of intent (similar
to what has emerged for microformats) is what is needed, but the
mechanism(s) to "use" that intent should be left to the user-agent(s)
(again, similar to microformats).  In many ways, inter-page navigation is a
"Semantic Web" concept as well, as we have added contextual meaning to text
strings.  But just like a method exists to mark up microformat data
(geographic references for example) so that it can be shared across multiple
user-agents, so too common document containers (search, navigation, content,
policies, etc.) should be declared, but just like microformats, we should
leave it to the end user on how they wish to consume and use the data, the
intent. 

> 
> However, when included within a <label>, for instance, it could
> identify help for a specific control.
> 
> <label for="...">Foo <a href="#help-foo" rel="help">(help)</a></label>
> 
> 

A bit of a mixing here... I would have to think this one through a bit
further, as up until now I've generally thought of <label> as being part of
form input data.  It identifies what data is being sought for the form
input, but I'm not sure if it is also the appropriate place to add
"meaning", as there may be times when we do not yet know what the value may
be, thus it would be hard to add that meaning.  Worth thinking about
though...

> 
> 
> *The Role Attribute*
> 
> As I mentioned above, HTML5 currently doesn't include the role
> attribute, though it has been discussed on the list several times
> before.  AIUI, the reason is that, given it's current definition and
> values, HTML5 covers many of the use cases with new elements.

Well... There are mechanics and then there are results.  From a pragmatic
perspective, I really don't see much of a difference between rel and role as
you have outlined it.  I think the bigger issue is that a standardized list
of "intent characters" (again, think microformats) is required, so that:
 
	A) authors could reference with some level of assurance, 
	B) user-agents could also re-use consistently, 
	C) is not dependant on specific key-bindings (they must be scalable
to accept that different user-agents must, due to other factors, use
different keybindings to achieve the desired goal of keyboard navigation
shortcuts)
	D) (and this is critical) does *NOT ALLOW* the content author to
declare the binding (I know Chaals will argue this, but I will leave it to
him to jump in - Chaals?)
	E) @role currently suggests the ability to define custom roles (RDF)
- this may in fact be very useful - although again how it would be consumed
by user-agents is not yet 100% clear (and is, I believe, the crux of Chaal's
argument for the ability to "hint" a keybinding - but again, I won't speak
for him)

I personally like the idea of role as it more closely defines what we are
talking about, but if one of the goals of HTML 5 is to re-use as much of
what we have now (rather than starting over again) then REL works too...
(IMHO) It's the values that are important, not the attribute.  That, and the
uptake by developers (which may itself be a vote for ROLE, as at least it is
"new", and may see implementation for no other reason than it is "edgy"...
We have to sell this to the mainstream developers out there today, who have
for the most part ignored the relative link anyway...)
	

Thanks for listening.

JF
---
John Foliot

Received on Friday, 3 November 2006 18:42:01 UTC