RE: Access Element is WRONG (was RE: Are we really still talking about Access Keys?)

Al Gilman wrote:
> Thank you for this beautifully-wrought argument.  Much of
> this I agree with.
> Let me expand on a few points of divergence.

Thank you for your kind words.  Many long time readers of the WAI-IG list
know that this topic borders on religion for me.  I too will respond
in-line:

> 
> ** summary
> 
> Yes, 'author proposes' is required for hotkey bindings.  

Fair enough.  Propose intent, not action.  If it is sufficiently important
to declare a hot-spot of "disclaimer", do so.  If it is not a 'standard'
access role, define it (using RDF?) and provided it an such a way that the
user-agent can then auto-discover.  But *STILL*, leave the keystroke
bindings to the end user, as this person is the only person best suited to
define the keystroke required to activate the hot-spot.

> This
> is needed both
> for application-specific hotkeys and for getting the authors
> to identify the
> hotspots whose access should be accelerated.
> 
> Yes, an element is needed because what is needed is a menu entry and
> that needs to be internationalized, including essential
> markup such as <ruby>.

Pardon if my lack of pure technical expertise emerges... But *why* must it
be an element?  Why not an attribute?  Are not attributes also exposed in
the DOM?

> 
> This is not to say we shouldn't be accelerating items based on their
> roles.  Quite to the contrary.  Review the Table of Contents function
> in the Mozilla Access Extension being developed in conjunction with
> the 'role' work. 
> 
> http://lists.w3.org/Archives/Public/wai-xtech/2005May/0011.html

Right, and I have looked at this tool.  I congratulate Jon Gunderson and his
team for interesting and useful work.  I will point out that it does *not*
bind keystrokes to functionality, yet still manages to expose said
functionality (albeit in a "proof of concept" mode).  So by concrete
example, it has been proven that assigning actual keystroke selectors is not
a basic requirement.

(As an aside, and not to embarrass Dr. Gunderson or his team, the actual
'homepage' for the Access Extension -
http://cita.disability.uiuc.edu/software/mozilla/index.html - can be, in Al
Gilman's words, my poster child for why authors should not be able to bind
keystrokes.  I refer all to the bottom left corner of this page:

Accesskeys

    * A: Announcements
    * B: Bugs
    * D: Download and Installation
    * H: Version History
    * O: Overview
    * S: System requirements
    * T: The Team
    * U: Documentation
    * H: Home
    * O: Software
    * S: Search

<rhetorical>
Question:  Should "S" then a) focus on 'System Requirements' (item 6)?, b)
go to 'Search'(item 11)?, or c) Open my Sage news-reader, yet another
Mozilla extension? Or d) go to user settings in IBM's HomePageReader? )
</rhetorical>


<massive snip>

> 
> If that functionality has been broken in this draft, we need
> to fix it.
> 
> In my theoretical model, the 'access' element is specifying a
> pseudonym for the event DOMfocusIn(here) or in other uses
> a pseudonym for DOMactivate(here).  This is a binding
> that belongs in the 'views' layer of the DOM.  And since half
> the accesskeys are actually intended as pseudonyms for firing
> DOMactivate(here) there is not point for a half-replacement
> with a dedicated element that only generates the focus
> behavior.
> 
> What we need to get across is that we are really annotating
> an event with a [menu entry and] hotkey.  Not an element.
> And since the 'focusIn' and 'activate' events are already
> well defined, we don't need any new constructs to create them.

So why then did the concept go from being an attribute in Draft 20040722 to
being an element in the latest draft?  As you have stated, it really isn't
an element per-se.

>> 
>> This is, frankly, poppycock.  The real question is *why*? By
>> preserving this capacity for explicit binding you perpetuate the
>> basic problem that exists with the current accesskey - lack of
>> standardized keys, pre-claimed and conflicting key bindings for
>> various user-agents and adaptive technology, etc., etc.
> 
> There are two 'why' answers that to me validate the requirement
> for an "author proposes" part to this "author proposes, user
> disposes" key binding. 

Response in reverse order:

> - the other is author interest.  If the author is not given
> the opportunity
> to create a complete user experience, they won't create the semantic
> underpinnings, either.  

...and if the author is omnipotent then they will be able to completely
understand and anticipate all variations of said user-experience.  Else they
will be hoping for at the very least a general approximation across UI
applications.  This is nothing new for developers who already conceptually
deal with a multitude of browsers/OSes, etc.  It is *why* better developers
use fluid layouts, separate style from content, use relative sizings instead
of fixed, etc. etc.

> If we let authors nominate hotkeys, they will
> identify the top hot-key-able targets in the page.

See, this is where it falls down.  You are allowing them to nominate a
user-behaviour, and not a document intent (semantic idea).  The focus
shifted from semantics to behaviours, and this is my complaint in a
nutshell.  

Allowing the author to control behaviours is what is wrong.  We decry fixed
font sizes (a behaviour), we condemn and deride sites that produce
horizontal scrolling (another behaviour), we encourage developers to not
launch pop-up windows (a behaviour), and we have a whole raft of guidelines
in the WCAG which address other harmful behaviours (auto-refresh, blinking,
etc.).  Yet we then see a new W3C draft *advocate* controlling yet another
behaviour.

My arguments may seem simplistic, yet the problem is also very simple.
Which of the above "S" functions should work?  And why would a spec ever
allow this type of problem to exist in the first place?

> Else,
> not.  We need
> them identified; we need the carrot to bring the authors to the table.
> I believe that asking authors to create intent-based events
> without affording
> them the means to nominate UI event triggers for them will create
> a feature gathering dust on the shelf like the 'link' element in HTML.

Here I disagree.  Already, smart energetic people and teams are providing
"extensions" to a certain browser (see above), other browser manufacturers
are committed to evolution and growth, and far from being stagnant this area
appears to be once again in flux (IE 7??).  With the release of XHTML 2
browser developers will all be scrambling to make their tool *the one* that
works best, in pursuit of market share, bragging rights, or whatever else
motivates their growth.  With a robust, well thought out and easily
implemented enhancement, it should be relatively easy to see it embraced.
Remember too, that in certain circumstances it will be imposed upon the
developers (witness the "UK Standard") - the 'stick' to your carrot.

5 or 6 years ago, a band of "we're not going to take it anymore" web
developers formed a group called WaSP, and very quickly we saw CSS
'standardization' and compliance (sic) emerge.  I am not worried that if
this is/was done right that there would be a real difficulty in getting
developer buy-in.

> 
> - one is application-specific verbs.  My posterkids for these are some
> of the actions in a web-ified email archive or WebMail ap.
> These would
> include "next message in thread" or "this message in threaded index
> view."  Waiting for standard terms for these is a losing
> play.  

Which is why allowing the 'roles' to be defined via RDF makes sense.

> 
> So, there is sufficient reason to let the author propose something.

Agreed, propose intent, not action.

> 
> The flip side is also true: removing the author's ability to nominate
> keys will not achieve the standard UI names that you would prefer.
> That is a topic of balance-of-terror detente among the OS vendors.
> JTC1 SC35 is trying to do that and like ISO HTML, it will be roundly
> ignored in the real world. The place where we can have a reasonable
> expectation of uptake in the commercial Web is at one remove from the
> user experience, in naming the intent-based events.

I'm not sure exactly what you are getting at here...

> 
>> I like "Role", I like the pre-determined list of common roles and
>> the fact that role is extensible via RDF.  Leave it there.  Let the
>> users determine the how and what. Never mind letting the author
>> "guess" which key is most appropriate.  I honestly thought that we
>> had gotten past "look" as a criteria, leaving that to CSS.
> 
> CSS needs semantic info in the 'content rep' to key when to do what.
> If the hotkey is specified in a CSS rule with a #id selector, then
> the CSS is not style, it is holding content hidden from the AT
> cruising the DOM through the access API.

???  Intent, semantics, and functionality are not style issues.  I never for
once suggested that this type of function be relegated to CSS.  Perhaps I am
naive or ignorant, but here's my conceptual idea:

A) W3C has a 'standard' list of common roles (as per Draft 20050505)

B) Custom 'roles' are defined via RDF

C) "Access" becomes simply a meta element (akin to link) so that when
defining custom 'roles' it can be auto-discovered by user-agents.  This type
of function already exists in "auto-discovery" RSS feeds.  <access
role="disclaimer" rdf.resource="">. Admittedly, this is the weakest link in
my proposal, however I do not think this outside the realm of possibility.

D) "Role", as an attribute, becomes the intent declaration.  Like other
attributes (lang, title, class, etc.) role can then be applied to any
semantic construct: <p role="disclaimer">.  Good UI's will then "announce"
when a custom role is present and allow the user to bind (or ignore) on a
case-by-case basis. (perhaps the "title" attribute would also be required to
give the role a human readable identifier?)

E) Binding is left to individual user-agents / user preferences.  This does
not preclude any user-agent from providing a "default" key binding within
their UI to the list of 'standard' roles defined and published by the W3C.
I will point specifically to Opera as a tool that demonstrates this type of
function, allows this, and allows end users-to re-map via the UI directly
(not by fiddling with alternate style sheets, userJS, or other arcane,
"geeky" methods).  As has already been pointed out, this is not realistic
either.

The net effect here is that, by and large, those developers that you are
seeking to "carrot" get their functionality without having to "guess" at
appropriate keystrokes, the majority of end-users have a stable, learnable,
reliable and CONSISTENT method of invoking keyboard navigation, yet
customization of key-bindings is left directly with the end user if and when
required.  The content author never had a say in it.

...*and* not yet brought to the table is the idea of internationalization...
What happens when "S" is not on Mr. Zhang's keyboard?  If the intent is
declared, then any key (not the "S" key) can be mapped - further
extensibility.

I am prepared to have holes punched through this, please.


> 
> You're lost in some theoretical world if you don't admit that web
> developers *must* optimize the look and feel of their web aps to stay
> in business. 

Sir, as a long-time web accessibility evangelist, I have heard this argument
for more than 5 years now.  I am not lost in the clouds; I like and
appreciate well designed, "pretty" web development.  As a small indie shop,
I "get" that all too well, as this is the point of view *all* of my small
business client base understands.  But I also understand user frustration,
as this same client base I work with generally tends to be of the "casual"
user variety.  Revisit the example I pointed out above, with the Web
Accessibility Extension page.  As a casual user, which "S" function would
*you* expect to work, and if it didn't how would you feel?  As I proudly
claim on my personal site, The Web Is Not TV!  To have this kind of thinking
suggested at the W3C is frustrating to me.

> 
> We *must* preserve the adjustability of that look and feel.  But we
> will simply fail if we try to do anything less than facilitating that
> optimization by the content developers.

Optimize, yes.  Control, no.

> 
> 
> Sir, you're dealing with two working groups, here.

With due respect, I am dealing with the W3C - arbitrators, and controllers
of the final spec.

> 
> The latest draft XHTML 2.0 has been developed by the HTML WG.
> 
> The idea that the XForms language is "good enough" in terms of
> assuring access is a matter that was consensus in the PF WG the
> last time it came up for consensus.
> 
> The current draft was supposed to be a Last Call draft, that the
> HTML WG considered 'done.'  It is not.  Not even the HTML WG
> thinks that they have got every detail right in this draft.  So
> bear with us, it is a work in progress.

<snip>

> 
> Thank you for your persistence in trying to keep us honest.

Just trying to do my part to keep the web accessible for all.

 "The power of the Web is in its universality. Access by everyone regardless
of disability is an essential aspect."
-- Tim Berners-Lee, W3C Director and inventor of the World Wide Web

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   
Phone: 1-613-482-7053

Received on Saturday, 4 June 2005 16:16:10 UTC