W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2006

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sat, 04 Nov 2006 08:01:54 +1100
Message-ID: <454BAE42.3000807@lachy.id.au>
To: John Foliot <foliot@wats.ca>
CC: Chaals@opera.com, 'WebAIM Discussion List' <webaim-forum@list.webaim.org>, w3c-wai-ig@w3.org

John Foliot wrote:
>>> Is there anybody out there comfortable enough to hack a modified DTD 
>>> together so that @role could validate today?
>> 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. [...] WCAG 1 P2 - 3.2 calls 
> for validation [...] developers who have no option but to follow the
> guidelines, could not [use @role].

That sounds like bureaucratic, political nonsense.  I can't understand 
why any organisation would let a little, meaningless cross on some form 
get in the way of real-world, practical accessibility benefits.  It 
makes me glad that HTML 5 dispenses with useless DTD based validity.

> If @role is going to be adopted as a "standard", then surely inclusion into
> a DTD is part of that process.

If it's in an XHTML document, the DTD is practically useless and there's 
no point even including the DOCTYPE.  You're better off finding a 
RelaxNG schema, adding the role attribute to it and claiming "validity" 
against that (just so you can tick the box on the form and keep the 
bureaucrats happy :-)).

> 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 (*)

Can you send me a link to the implementation and test cases for it?  If 
that can demonstrate real practical benefits along with an existing 
implementation, that could strengthen the case for including role in HTML5.

>> 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?

Only because the <a> element is a better alternative for links, given 
that <link> is not useful to the vast majority of users without 
something like a link toolbar in their browser.  However, from an 
implementation perspective as far as keyboad binding are concerned, 
those links should work just as well as the equivalent <a> links.

> More importantly, they exist in the specs today, they are just poorly used 
> (if ever), and have minimum support from the browser makers.

Exactly!  Poor use and lack of support is a very good reasons to drop a 
feature.  Given that HTML4 has been around 8 years, if those features 
aren't supported yet, there's little hope they will be.

For example, that's exactly why various attributes like rev, longdesc, 
charoff, char, etc. have been (or will be) dropped from HTML5.  We have 
quantifiable evidence to show they're either widely unsupported, or 
they're rarely used and mostly used incorrectly when they are.

>> 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 handled 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,

I know.  The only reason I chose them was because they were a convenient 
list of use cases for keyboard shortcuts that could be (mostly) 
semantically marked up to allow user defined key bindings.  I fully 
agree with you about accesskey.

> 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,

Yes!  But, whether or not role="search" is better than <input 
type="search">, or some other mechanism, is separate question.

> 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.

The role the link plays here would be role="navigation".  However, the 
<nav> element says it's part of the site naviation, the <menu> says it's 
part of a navigation menu and the <a> says it's a link.  In this case, 
role="navigation" provides absolutely no additional information 
whatsoever.  For the key binding, in this case, the specific 
relationship between this page and the resource is what's important.

> 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, 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)

Yes, that's exactly right!  New link types are planned to be included in 
HTML5.  I don't know for sure, but it will probably include those that 
have gone through the microformats process, which have already proven to 
be useful.  To include any new link type in HTML5 (or anything else for 
that matter), we'd need solid use cases, evidence to back up whether or 
not authors would actually use it and a good description of the benefits 
it provides to users.

>> 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.

Well, I'm sure you would agree, that having a useful mechanism to find 
help for filling out form controls is good for both accessibility and 
usability.  In this example, we already have <label> to assoicate some 
content with a specific form control and we have rel="help" to indicate 
a link to get help, merging the concepts seems quite logical.  It's 
basically the same way some microformats work, by building new semantics 
from a combination of existing semantics.

> 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...

Well, a similar technique I've come across relatively recently is to 
indicating error information for form controls by including the error 
message within the <label> element.  Something like this:

<label for="...">Email <em>error: invalid address</em></label>

The reason for that is a practical one, because of the way screen 
readers apparently work in forms mode.  Personally, I would like to see 
some kind of explicit error markup so they could be separated, but it 
doesn't exist yet and we have to work with what we've got.

>> *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, [...]

Yes, I agree.  The way we need to do it is to identify the use cases and 
then try to meet those use cases with what we've already got.  If what 
we have is clearly inadequate for the use case, then we can look at 
introducing something new.

> 	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)

If you're correct, it sounds to me like Chaal's argument is effectively 
that "RDF doesn't solve our problem, so we need to give a keybinding as 
well".  If that's true, that indicates that they need to rethink their 
solution, rather than patch a broken one.  I'd also like to add that RDF 
is a complex language for the average author and it's highly unlikely to 
see any significant use for this in the real world.

> 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...

That's sums it up nicely!

> (IMHO) It's the values that are important, not the attribute.

Absolutely agree!  I'm not against role in any way, it just needs to be 
proven useful.

> 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"...

If the only reason it's getting implemented is that it's "new" and 
"edgy", then that would seem like a good indication of being useless. 
So I hope that's not the case.

>  We have to sell this to the mainstream developers out there today, who have
> for the most part ignored the relative link anyway...)

No, microformats seem to be bringing new life into link relationships. 
Just look at XFN, rel-tag and (sadly) rel-nofollow.  It's interesting 
that after only a few months, rel="nofollow" became the 6th most 
frequently used link relationship!


Lachlan Hunt
Received on Friday, 3 November 2006 21:02:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:35 UTC