@role (was RE: More data on accesskeys (New article written Nov. 1))

Moved to the W3C WAI-Interest list only (per requests), with a one-time
separate notification sent out to WebAIM and WHATWG lists for those who may
not follow wai-ig.

Cheers!

JF
************

Lachlan Hunt wrote:
> 
> 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.

LOL - hey, I don't disagree, although it is a real world bureaucratic
requirement.  But at it's base there is some validity:  If you are going to
have and use standards, then have and use standards, and use them in a
standard way.  Else don't have standards and do things in a non-standard
way... But be prepared to suffer the consequences.  I don't think a pedantic
approach is always the right way, but there is an equal argument to be made
for being "proper".

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

...and Lachlan, if that is what it takes, then sure, give 'er.  But as any
scientist will tell you, you need to have a benchmark or standard to measure
up against, and if a DTD is not the place, then where and how would you
propose?  I can see the scientist/bean-counter perspective too, whether at
some levels it is "nonsense" or not.

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

Test cases:
http://www.cita.uiuc.edu/software/mozilla/test/ts-test-page-role.php
Toolbar download: http://cita.rehab.uiuc.edu/software/mozilla/

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

While I would be hard pressed to disagree, I suspect that part of the
problem with their current non-use is both a lack of understanding and
awareness, as well as a failure of WYSIWYG tools to provide access to these
most useful elements.  Sadly, we've also been cobbled with a negative
chicken and egg scenario, where, because they weren't being used, browser
support for them became less critical (especially during the first browser
wars, where <marquee> and <blink> fought it out, and on-screen flashy was
naively the rage and focus of browser development).

Developer awareness of Semantic Web structure, standards, and on-line
accessibility issues have matured to the point where I suspect that a bit of
an overhaul and re-introduction of the relative link could see a resurgence
of these elements. (I like to believe so)  There may be times when linking
to a concept container ("policies"?) may not be directly achievable (or
desirable) via the anchor element; this would be the perfect case for the
relative link with an @role declaration.  I would caution not to toss the
baby out with the bathwater.

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

Well, at this time, this may be hard to "prove".  I have engaged many, many
people on the subject of accesskeys, and the overwhelming consensus is that
a means of providing accelerator keyboard shortcuts for interpage navigation
is not only desirable, but in some cases truly needed.  I've never argued
that point, and totally agree with that assertion.  

The problem has always been the way accesskey is/was implemented, which has
lead to poor uptake by developers, and poor adoption by end users.  The
current problems are pretty well documented (and I could assemble a more
cohesive collection of them if so required), but we need to now come up with
a better way.  So adding a new method requires something of a leap of faith,
and needs to be better thought out than what we currently have. 

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

In that context, yes, that makes sense.

> 
>>> *The Role Attribute*
>> 
>> 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.

Hmmm... There is inadequate and then there is logical/practical.  Since
we've referenced microformats already, I can look there as a possible
use-case.

While I understand why microformats have chosen "class" as the identifier of
choice, I think honestly that it is a "make-do" solution rather than a
structured and reasoned solution.  One overarching concern I have is that as
we move forward, everything is going to be dumped into <div>s with classes
and IDs, and that good old-fashioned semantic HTML (lowercase s) will give
way to this "classed" style markup, which would have I believe practical
negative effects for accessibility.

I think that @role would actually benefit microformats; which makes more
sense - <p role="vevent"></p> or <p class="vevent"></p>? (<p role="vevent"
class="weekday"></p>, <p role="vevent" class="weekend"></p> - ?!?)

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

Well, again, I can hardly speak for Chaals (who is quite eloquent in his own
right), but I don't think that is exactly what he is saying.

The overall concept of @role (as I understand it in terms of
"accessibility") is that we now have a means to identify content blocks and
other key fragments within a document, so that they can be accessed quickly
using non-traditional means (keyboard shortcuts, but possibly others).  Part
of that work is/was the creation of a common collection of roles - a
standard list, again similar to the class assertions of microformats.  For
the majority of web-developers out there, implementation and
"standardization" of this common collection would suffice 99.99% of the time
- so long as we get the common collection right [action item].  @role also
allows (in specialized circumstances) for the creation of custom roles.  For
these roles to be effective, they need to be defined (and RDF is good for
that) - yes, RDF is "tricky", but if the common collection is robust enough,
the need for custom roles would be rare, and if you can create a need for a
custom role, then you should be able to define it well enough to use RDF to
do so.

Chaals suggests (if I understand him correctly) that for user agents, some
method of "hinting" a keybinding (in a vacuum) would be a good thing,
although I would counter that if a browser could discover a custom role, why
would it need to discover a keybinding, and not just instead announce the
presence of the custom role and allow the author to set their own key?
However, I am hardly a browser developer, so I do not know or appreciate the
technical challenge this may present.  Remember as well, that this is all in
the context of my concern over @key in XHTML 2.

>> I personally like the idea of role as it more closely defines what we
>> are
>> talking about, 

<snip>

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

<snip>

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

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

Well, taken out of context, but in order, I think you've kinda made my
point.  A 'new kid on the block' (microformats = "new & edgy") breathes life
into a forgotten bit of old-school HTML - the relative link. A year (18
months?) ago the argument for abandoning the relative link (or at least good
chunks of it) would have been quite strong... But then along comes XFN and
it's need/use of the relative link and all of a sudden it's a whole
different ball-game; as you stated, now link-relationships are being
re-thought and implemented - sometimes in ways not originally conceived when
the spec was created.

At this time we are hard-pressed to "prove" the usefulness of @role, because
we do not have a means to implement or use the concept.  Unlike the machine
consumable microformats, @role suggests a way to improve user-interaction,
but again, it's a chicken and egg scenario - we have no mainstream tools
today that adequately expose and avail itself to the benefit (Prof.
Gunderson's toolbar aside).  It would be sad that the only reason something
as useful as @role (and it's potential) did not get taken seriously is
because everyone is sitting around waiting for the other guy to blink.  At
some point there *does* need to be some leadership - it can't all be
reactionary (IMHO).

JF

Received on Monday, 6 November 2006 17:46:01 UTC