RE: @key - XHTML Role Access Module still flawed (PR#7845)

Steven Pemberton wrote:
> John,
> 
> Thanks for your (long!) comment.

And thank you for your response - which I will presume to be an informal
response as opposed to a formal one on behalf of the XHTML Editors.  My
comments follow:

> 
> First let me say that XHTML2 is being designed with direct contact
> with 
> the accessibility groups at W3C and Richard Schwerdtfeger is on the
> HTML 
> WG himself.
> 

Yes, and I am also in discussion with Al Gilman on this subject, amongst
others.

> Let me try to address your points one by one.
>
> It is not an aim to get rid of all behavioural markup in the
> language. On the contrary, where there are clear needs identified by
> current use of scripting (in HTML4/XHTML1), then we have introduced
> declarative markup to cover that case. Navigation lists are a good
> example of this.    

While this is true, you leave the actual rendering of the list (and any
other "functionality") to the individual user agents and or DOM
scripting, as not all UA's will deal with <nl> in *exactly* the same
manner.  This is one of the fundamentals of my argument - you read my
Mantra: Declare the intent and leave the binding assignment to the end
user.  This is also consistent with the earliest "rules" of HTML, where
the semantic meaning is "marked up" but final rendering is decided upon
by the end user agent.  My GUI browsers generally (not exactly) render
<h1> as large text (when unstyled), whereas my Lynx browser deals with
<h1> in a completely different way - yet the meaning is consistently
conveyed in all of these browsers.  This is HTML 1.01

> 
> We did indeed attempt a solution to the requirements we had to that
> used a DOM-based declarative markup, but with the lack of sufficient
> architectural support, we fell back to the current design.  
> 

Given that no user agents currently supports XHTML 2 anyway, is this not
a weak argument?  I am unaware of anything that can currently parse the
proposed RDF declarations for custom @roles as proposed, yet that does
not preclude you adding this to the Spec. 

> 
> There are two communities who have expressed to us a need for
> author-supplied key bindings, and with which we have had discussions.
> One is the accessibility community, 

To which I am most certainly a vocal and recognized member, and I have
already garnered some support for my perspective, from both developers
and end users via a number of discussion lists.  Please do not confuse
the opinions of a few as being representative of the entire community -
those that speak on behalf of the Accessibility community at the W3C,
while commended (and to which I have both much respect and admiration),
were never *elected* or otherwise appointed to speak for all.  The jury
is still most certainly still out on this matter - suffice to say there
are dissenting voices on the topic.

> the other is the mobile
> community. There is also a third, the HTML community, who want to be
> able to continue to do what they do in existing versions of the
> language.   

Except, more often than not, the HTML community are not using ACCESSKEY,
due to the inherent problems with it.  I have been talking and cajoling
and generally seeking to teach on this subject for over 3 years now, and
even a perfunctory search on any major Search Engine for "accesskeys"
will quickly point to either one of my articles or a site that
subsequently points to one of them.  My simple little chart that details
known key stroke conflicts is referenced, on average, 1000 - 1500 page
views per month, and has been almost since the date it was published.  I
can safely say that the tide of developers who do not use accesskey
(either through ignorance or due to the evangelism of myself and others)
is far greater than those that cling to them.  For the most part, the
only sites that continue to perpetuate ACCESSKEY are those that are
mandated to (i.e.: UK "standard")
  
> 
> I think that the community that uses it the most is the mobile
> community for binding keys (0-9*#) to menu entries. 
> 

<snip>

> 
> However, in non-accessibility
> environments, such as in mobile use, there is still a perceived need
> to be able to specify a key.   

But that perception is wrong - and it should be the W3C that helps them
to see this!  This community, more than any other, must/should know that
attempting to bind something to an alpha key will not work on their
devices - yet they claim that authors should be able to do it?  What is
wrong with this picture?

Can anyone honestly say that they anticipate sophisticated "web
applications" (which, BTW, should more honestly be referred to as web
APIs, as the actual application is the User Agent, which interacts with
the authored materials) will be accessed via mobile devices
(telephones?)  An honest response, please.

The mobile community, more than any other, stands to benefit the most by
specifically NOT allowing authors to bind functions (et al) to specific
keys, as this community has far fewer keys to work with than standard
keyboards. By removing the ability for an author to bind a specific to
an alpha key, the @role declaration is left open to the user agent to
access, un-encumbered.

The Draft Recommendation intends to define Common Roles, and in fact has
already started to do so.  The manufacturers of these devices must
surely wish that a standardized list exists, so that they could then
universally map to them with their limited keystroke combinations. This
then raises an interesting point: Since the W3C is already defining a
Common Collection of ROLES, why not also, as part of the XHTML 2
specifications, specifically map these same Common Roles to specific
numeric keys?  You know the answer as well as I - yet if an authorative
body such as W3C cannot state a universal set of bound keys to even the
Common Role Collection, what leaves anyone to believe that individual
authors can do a better job?  

However, if we leave that job to the proper actor (the user agent), then
who cares?  My Nokia phone binds "Privacy" (which, BTW, should be a
Common Role item) to "#9", Kyocera uses "*4", JAWs uses "Alt+Z" -
whatever works for each user agent.  Why are you going to let some yahoo
in Kalamazoo bind it to "Alt+F"?  At this point, with the proposed draft
solution, we now require these same devices to intercept, re-map or
otherwise react and over-ride Kalamazoo Kevin's bindings?  This is
intelligent design?
 
> 
>> 	MANTRA: Declare the intent and leave the binding assignment to
the
>> end user.
> 
> A good tenet, but not a reason in itself for disallowing explicit
> bindings. 

Perhaps, but I have not even heard a supportable reason for *allowing*
explicit bindings, save for a "perception" which can easily be
de-bunked.


>> Technical Reports: [T] - In most mainstream browsers, this is
>> supposed to open the "Tools" dialogue, in  HomePageReader it is the
>> shortcut for Table Navigation, and in the laptop configuration for
>> JAWS, it is supposed to "Speak the Title of the Current Window" -
>> except at the W3C site of course (Oops again...)
> 
> I don't understand why this is this a bug in HTML4 or W3C, and not in
> Jaws. I would complain to Jaws personally. Althought the HTML4 spec
> doesn't disallow using the same key combinations as the chrome, it
> doesn't require it either; it seems like a bad choice for a browser
> to use it. 

Please re-read that.  This is not a "bug" in one user agent ), but a
conflict in ALL user agents that I have tested.  For shame! (And for the
record, JAWS is not a browser/user agent at all, but rather an essential
Adaptive Technology application used by the visually impaired, which
interacts with other applications on the Windows Platform). At best it
is a shared guilt - the user agents for not providing appropriate
conflict resolution, and the author and authoring language that allows
such conflicts to exist. At least with JAWS, it *does* over-ride the
user-agent, but unfortunately not the author supplied binding (perhaps
because they are so rare?) 

The very simple fact is for Adaptive Technology users, they *MUST* use
key stroke navigation, as pointing devices are simply a non-starter.
For most blind or visually impaired users, the "ALT+T" keystroke is a
reliable and learned action which *should* (read MUST) produce a
standardized result; you will note that the 2 referenced A.T. solutions
use ALT+T differently, yet for those unique users, it should be a
consistent result *regardless* of the web site they are on.  That any
given author can over-ride this today is criminal, doubly so that it is
the W3C.  To argue that this is a flaw of JAWS (never mind IBM's
HomePageReader plus all of the major user agents) strikes real fear (and
sadness) into me, as it clearly illustrates a complete lack of
understanding of the issue at hand.  I do not say that to be insulting,
honestly I do not, but please... This is clearly an author error - plain
and simple, as on the majority of web sites this is not a problem - it
is only broken at the W3C because the author added it to their source
code.  This is why they should not be allowed to do so!
   

>> 	User settings over-ride all user-agent mappings and author
declared
>> 	bindings. (Highest Priority) User-agent mappings over-ride
author
>> 	declared mappings. (Second Highest Priority) Author declared
>> mappings be exposed/honored. (Lowest Priority) 
>> 
>> While this is still a less-than-perfect solution to me, I believe it
>> to be an acceptable compromise to address some of the concerns
>> raised. 
> 
> Good.

However, if this is truly the case, why would any author ever want to
apply a key-binding?  In most if not all instances it will be
over-ridden, and this may in fact cause the opposite effect - authors
will simply not bother with access because "...it doesn't work" (<cite>
anyone?). This does a great dis-service to the community that most
require advanced key-board navigation - the Accessibility Community. 

To re-quote the preamble to the XHTML 2 Draft Recommendation, is not the
intent to create "...a common framework that allows data to be shared
and reused across application, enterprise, and community boundaries...to
create a general-purpose markup language...[that] does not attempt to be
all things to all people..."  If this is truly the case, then there is
no need for key-binding: this is (rightly) the current and future
responsibility of the end user and their user agents.

> 
> 
> Please send us your design. Since there are communities that would
> not be happy if we removed @key, we will not do so, but if you can
> come up with something that you consider a better design, we'd be
> happy to see it.   

I outlined a scenario in my original posting.  It moves the hinting to
the RDF declaration, where it belongs.  User agents that can extract
useful information from this same said RDF file will be able to provide
a hint to the user agent, to then be acted upon by the end user - with
one of the end user's very real options to simply ignore the hint.  Your
scenario has the user agent being told what the key-binding is, and then
forces the end user to modify author supplied instructions - which would
seem to me to require more overhead on the part of the end
user/user-agent (has the mobile community thought about that?).  One
gives the choice to the user (mine) the other to the author (yours).
This is wrong.

Finally, there will always be communities not happy to see something go
- yet I do not see <marquee> or <blink> in the XHTML 2 draft (said half
joking, half seriously - sadly the written word lacks any ability to
convey body language or subtlety).

Thank you for your time.

Sincerely,
John Foliot

> 
> Best wishes,
> 
> Steven Pemberton
> For the HTML Working Group

Received on Thursday, 8 December 2005 01:36:07 UTC