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

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

** summary

Yes, 'author proposes' is required for hotkey bindings.  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>.

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

And I suspect once we have it right, the default ToC will pick up headers
automatically without having to add 'role' qualification to them.

But the author-extension option needs to be there, duly integrated into
the event model.

Given the fact that SVG 1.2 Tiny is ahead of XHTML 2.0, we may be 
able to lose the 'access' attribute and element entirely in favor of 
an sXBL application before this format is done.


** details inline below

At 5:06 PM -0400 6/2/05, John Foliot - WATS.ca wrote:
>Al Gilman wrote:
>>
>>  But at a simpler level, the framework for Multi-modal interaction
>>  will cover, hopefully, the needs of handling alternate
>>  modes of input as configuration options.  The latter case is what
>>  we are trying to institutionalize in replacement for ACCESSKEY.
>
>By creating an element known as "access" and giving it a possible attribute
>of "key"?  You have got to be kidding.
>(http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule)

No, that would not be my first choice.

but it is a feasible syntax so long as the client-side management and
overriding of the UI-event bindings is duly specified and implemented.

http://lists.w3.org/Archives/Public/www-html/2004Aug/0032

The precedent is set in the XForms specification.

<quote>

accesskey

Optional attribute defines a shortcut for moving the input focus
directly to a particular form control . The value of this is a
single character which when pressed together with a platform specific
modifier key (e.g., the alt key) results in the focus being set
to this form control .

The user agent must provide a means of identifying the accesskeys
that can be used in a presentation. This may be accomplished in
different ways by different implementations, for example through
direct interaction with the application or via the user's
guide. The accesskey requested by the author might not be made
available by the player (for example it may not exist on the
device used, or it may be used by the player itself). Therefore
the user agent should make the specified key available, but may
map the accesskey to a different interaction behavior.

</quote>

found by string searching 'accesskey' in:
http://www.w3.org/TR/xforms/index-all.html

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.

>  > However, we want to preserve the *author's* access to binding
>  > the events in a provisional way, so that they can create their
>>  own look-and-feel and not be totally dependent on published
>  > conventions.
>
>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.

- 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.  Standard
terms in new application domains (such as 'home' in the Web) will
emerge, but predicating

- 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.  If we let authors nominate hotkeys, they will
identify the top hot-key-able targets in the page.  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.

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

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

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.

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.

>(Besides, doesn't the RDF extensibility of
>Role extend it beyond the "common conventions"?)
>
>>  [The balance here is a matter of contention in the
>>  community.  But the current thinking in PF is that the author
>>  proposes UI bindings, and the User and User Agent may override
>>  these where the user asserts a clear preference.]
>>  http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html
>
>
>If the WG feels

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

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.

>that having the "key" attribute is important, why are you
>deprecating accesskey?  What, honestly and truthfully is the difference
>between:
>
>  access key="S"  and  accesskey="S"
>
>...outside of the fact that one is an attribute, the other an element?  Both
>bind that particular "thing" to "S", whether or not "S" is already claimed
>by something else on my configuration or not.  It does not solve many of the
>inherent problems currently experienced with accesskey.  So why bother? 
>
>To further state that user agents and/or end users should then somehow be
>allowed to explicitly over-ride the author's binding... C'mon...

Is the only way to strike a deal between author and user interest that will
fly in the massively distributed-authoring flow of information on the Web.

>How did all of this:
>
><q>The user has better knowledge of what works for them and what does not
>than an author trying to prepare an experience for multiple users.
>
>{plus}
>
>Users quite generally prefer not to change the author's presentation or
>UI design, and to change it as little as possible where necessary.  Most of
>the people using something other than the default presentation or input
>binding the author offered are people who need to use something different.
>
>{and finally}
>
>When there are many settings associated with adapting a user interface,
>the user may not be able to navigate the interface state to an optimum.</q>
>(http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html)
>
>...end up like this:
>
>(The Draft states:) "Note. Authors should consider the input method of the
>expected reader when specifying an accesskey." Plus the brilliant: "User
>agents should render the value of an access key in such a way as to
>emphasize its role and to distinguish it from other characters (e.g., by
>underlining it)."  [Let's be sure to let all our blind friends over at WAI
>know to watch out for an underlined letter, OK?]
>(http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule)
>
>That's a lot to put on the end user, all for the benefit of some
>Photoshop/Dreamweaver jockeys who want to preserve their "look and feel"...
>
>We've already seen, first hand, what happens when well meaning but poorly
>informed authors impose what they think is best; You get entities such as
>the UK government *mandating* an accesskey of "S" to be bound to "search",
>despite the fact that a tool like IBM HPR uses the same keystroke (ALT+S) to
>get to user settings! (http://wats.ca/resources/accesskeysandkeystrokes/38)
>Why even give them the opportunity to mess things up? 
>
>How did this come to pass?  In Draft 20040722 (http://tinyurl.com/797na) you
>guys had it right, one draft later it's gone to being yet another useless
>oddity ripe for abuse.
>
>THIS IS JUST PLAIN WRONG!

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

Al

>
>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 Friday, 3 June 2005 16:47:12 UTC