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

Shane McCarron wrote:
> Well....  I am not sure how vigorous I can be.  In general,
> the working
> group attempts to only *remove* features when there is alternate
> facility that provides similar functionality in a more portable,
> scalable, general, or accessible manner.  Sometimes things just get
> removed (e.g., the blink element).  In the case of
> @accesskey, there was
> no other facility that could provide equivalent
> functionality, there is
> a segment of the community that uses the feature, and it is not
> perceived to be harmful except in that it was inadequate for
> solving the
> REAL problem (@role).

"In all affairs it's a healthy thing now and then to hang a question mark on
the things you have long taken for granted."
            -- Bertrand Russell

At one level I am challenging that perception.  While "great harm" might be
an exaggeration, some harm can arise.  The possibility exists (because
conflict resolution is not clearly mandated or defined) that author supplied
accesskeys (in the old spec) or the newly envisioned access key="" may
interfere with an adaptive technology, alternative user agent, or fail due
to internationalization reasons.  Given the current lack of standardization
of the situation, it has been until now a catch-as-catch-can for individual
authors (both web content and software), with the net result that there are
virtually no keys consistently available.  We have detailed a chart, which
is posted at: http://www.wats.ca/resources/accesskeysandkeystrokes/38 which
seeks to track this.  It is admittedly incomplete and just yesterday I
received new information in regards to internationalization (Finnish/Swedish
keyboards), which further impacts on the conflict situation.

At the very least, it can (and does) introduce frustration to the end user
when author supplied access keys over-ride predetermined user-agent
settings.  For users of the Sage News Reader extension in Firefox, Alt+S is
supposed to open the application.  Yet whenever a page with an author set
key of "S" is loaded (UK Standard?), it over-rides this function.  I ask the
working group, is this right?  Should some page authors that are writing to
the UK accesskey standard have the right to modify *my* software collection?
The sense of frustration this brings has been previously commented on though
the WAI-IG discussion list - so it is not a perception, it is a recorded
comment.

For those users who experience any form of cognitive disability, having
expected or learned behaviours interrupted can be "harmful" (in the soft
sense).  In the first example above, I showed what happens when the conflict
resolution mechanism within an application (Firefox) defaults to the author
supplied mapping.  

But what if it is the reverse?  What if the user-agent respects user-defined
mappings and ignores author set mappings?  What happens if a disadvantaged
user reads on a web site that a quick way to reach the "Search" function (or
skip navigation - ugh) is to use Alt+S? (never mind that authors often
specifically write this windows-centric instruction, even when other OS'es
use alternative modifiers - another battle, another day)  It doesn't work.
Is it broken?  Did the user do something wrong?  What's going on?  Could
this not be considered "harmful"? "Frustrating"? "Wrong"?

> 
> As to the origin of requirement 1, I am afraid it is lost in
> the mists
> of time.  However, my archives lead me to believe it had to do with
> continuing to support current use.   For content developers who need
> this facility, there is no portable, media and user-agent independent
> alternative. 

Yet.  

Is this reason enough then to prop up a bad concept?  Push for a better
solution, even if that means having to wait for a little while.  If the need
truly exists, a solution will be found quickly, if it doesn't it will sit on
the shelf waiting.

<snip>
 
> It [access element - JF] does NOT have to be associated with a specific
key.  Let
> me say that
> again.  IT DOES NOT HAVE TO BE ASSOCIATED WITH A SPECIFIC KEY.  A
> content author may choose to associate a role with any sort
> of event, or
> with none.  A user agent may choose to expose standard role values in
> standard ways.  It may choose to give users the ability to define
> mappings for standard roles, or indeed for other roles through
> auto-discovery.   That's the utility of @role, and has nothing to do
> with the access element, per se.
> 

Not to be argumentative, but in a private posting you stated that if it was
not mapped to a keystroke for a custom role, it would not be used.  If
<access> *DOES NOT* need to be mapped to a specific key, why are you then
providing that ability, given that MORE OFTEN THAN NOT the author will get
it wrong?  That the author will choose a key that will not work for some
users?


> Because the content author is the ultimate authority.  They
> get it right
> *by definition*.  It's their content.  You might not like
> what they do,
> or what they think is right.  I usually don't. But that
> doesn't matter.

Good sir, they are the authority on the intellectual content, not on how the
end user wants or *NEEDS* to interact with their computer, software, user
agents, etc.  The author has no idea who I am, what tools I use, or how I
access their authored content - and we've been saying *that* for years!  I
can defend an authors right to be as wrong as they want, but I cannot
support their ability to interfere with another persons means of accessing
that content.  That steps beyond the boundaries of reasonable, and I would
hope that the W3C would agree.


<snip>
> 
> By your argument, end users should be able to define the keyboard
> shortcuts in every application.

Well... I can do it with Opera, I can do it in HomeSite, GW Micro's
WindowEyes and Freedom Scientifics' JAWS allow me to do so...

However, Web content is not an application.  Yes, though markup, scripting
and CSS "application-like" behaviours can be delivered to the end user, but
a thin client (the browser/user agent) sits between the author and the user.
Are you suggesting that a content author be allowed to modify the way the
thin client operates, regardless?  That's what's happening now, and that's
what I fear the new spec will continue to support.

> The application I am using
> right now,
> for example, uses Alt-F to bring up the file menu. Are you suggesting
> that I should prevail upon the developer to allow that to be
> Alt-Ctrl-F or Ctrl-mouse to the left?  Its the same thing. 

Actually, it's the reverse.  Depending on the user agent and Operating
system set up (etc.) I could conceivably author access key="F" to access
"Financial Disclaimer" and IT COULD OVER-RIDE YOUR APPLICATION MAPPING? (see
SAGE example)  Or not work, at which point, what's the point?  Or require
that you as an end user go in and re-map one of the two so that they can
peacefully co-exist?  Why not just inform you that I have provided a custom
@role of 'financialdisclaimer' that you can map to or not, and leave the
resolution to you - the one who knows best.

> Really it
> is.  Web content is an application.  Sometimes simple, sometimes
> complex.  True,
> it is exposed to its user through yet *another* application, but that
> user agent is not there to get in the way of the portable web
> application.  It is there to facilitate it.
> 
> And, again, there is no requirement that any web application
> map any key
> to anything.  It is an option, not a requirement.  If I am
> defining new
> role QNames (and the associated RDF definition) as a navigation
> convenience for my users, who is the HTML Working Group to tell me I
> can't specify what key should be bound to that new QName by default?

Why you're the Standards authors, that's who.  If it is not in the standard,
then user-agents will not (should not) be natively built to support a
function.  The content authors and "designers" (I called them Photoshop and
Dreamweaver jockeys in a previous post) may not like that, but I'm sure
there are other things they don't like as well.  If they truly believe that
this functionality is a basic requirement, then build a true application and
deliver *that* to the client.

The spec should allow for the author to declare the intent (it does), but
leave it to the end user to take advantage of that intent (shortcut
mapping).  As I have said before, ONLY THE END USER knows for sure the best
or most appropriate means of invoking that advantage, of using *their*
tools.

I'm not the only one saying this either.  David Woolley succinctly stated:

"In my view any true web application that needs instruction documents on
how to use it is badly designed.  Most people use individual applications
so infrequently that they cannot remember all the details from one 
session to the next.  There are a lot of bad web applications out there.

<snip>

For true web applications it is particularly important that global user
interface standards are followed and designers are not allowed to be
too creative.  Unfortunately, the money is in branding, not in making
the web as a whole easy to use and easy to learn for people who have
not been using it for the last ten years (particularly older people, 
although I've seen references that even young people don't like the
usability of the current web)."

(http://lists.w3.org/Archives/Public/w3c-wai-ig/2005AprJun/0383.html)

<snip>

> 
> I understood your example.  However, I guess I am missing something.
> They can't cause a conflict really. 

Yes, they can and they do.  Alt+S does not open my Sage Reader when I am at
a UK government site.  That is a conflict, and one that I cannot currently
correct.  That it's severity is low is not the issue.

> They can be inconsistent among
> various web applications, just as they are inconsistent among Windows
> applications.

One of the biggest complaints about the current Accesskey today is this lack
of consistency.  Allowing authors to continue to choose their best idea for
which key is mapped to a certain 'role' perpetuates this problem.  I offered
up my infamous "S" examples as examples of existing inconsistency.  While
the new spec does not mandate a key mapping, if each author out there WANTS
TO DO SO, we will continue to have the same tower of Babel situation we are
currently faced with, making what should be a good thing less than good
(again).  It does not fix the problem.

> But within a specific domain (web application,
> web page,
> XHTML document) they are whatever the author and you say they
> are. 

Why must I consult with the content author on how my system should behave?
What right does she have to tell me that she knows better, that *these* keys
are the best mnemonic choice?  I cannot buy this, this is just wrong.  By
completely removing the ability FOR THE AUTHOR to map a key to an intent, it
leaves it completely in the hands of the end user as to how they will access
this intent, this internal navigation scheme.  User knows best! 

> In
> any user agent worth its salt, your settings are going to take
> precedence anyway (user preference trumps document
> preferences, just as
> in CSS.  I will ensure this is clear in the draft).

Except there is a difference between *should* and *must*.  Can we expect the
word 'must' in the spec?  

Throughout this discussion we've pretty much conceded that for the common
roles, good next-gen user agents will probably (should? must?) provide
internal default mappings to those common roles.  In these cases, what
matter; for the end user, whatever key they map (or has been mapped by
default) in their tool will always perform (conform?) as they have
configured it.  Consistently, across all sites or web applications that
invoke the common roles - power user or newbie.  The benefit here is that
the author does not have to guess which key, the software comes
"pre-configured" and thus with conflict resolution addressed.  If these are
defined as user-settings, then by your vision they will over-ride any
mapping that the author will supply, so the authors won't bother declaring
them.  This is then a complete circle, and negates the need for author
mapping to common roles in the first place.

This leaves us with specialty roles and their mappings.  While this is in
fact the difficulty, should it be left to the content author to start
guessing again which key to map to?  We tried that with accesskey and look
where it got us.  Look at my chart, which key would *you* choose?  Did you
evaluate internationalization concerns?  Have you checked to ensure that if
there *is* a conflict with something out there (and remember, my chart is
far from complete), that the conflict resolution causes no harm or confusion
AT ALL?  The W3C cannot mandate authors to do these things, and so the
potential for 'harm' does exist.  Remove the ability for author mapping, and
you have removed the potential for harm.

> 
> I cut out your example below, but thinking about the 'S' key:  If a
> web application indicates that 'S' should map to save (as in save the
> content of this wiki entry I am composing), that's important.   If the
> user agent had some default mapping for the 'S' key (e.g., the
> File->Send operation for a page) that should get overridden
> by the web
> application I am using. 

It should?  How and why can you say that? That is an intrusive decision on
your part, without consulting me. How is this any different then serving me
a pop-up window with an ad for a spycam? (and we all know how much people
love those popup windows!)  I want "S" to stay as the launch of my Sage News
Reader - you should not be able to over-ride that.  Your proposed solution
is that the end user can then go in and re-map based upon user preference,
to which I have argued that in my opinion that is a backwards scenario; I as
the end user should not have to be over-ridding anything you have done, it's
my machine gosh darn it, not yours.

> If, however, the user specified some setting
> for the 'S' key (launch external mp3 player), then that should take
> precedence.  Just as in CSS. 
> 

How is this level of importance being defined and declared?  Who decides?  I
don't see this anywhere in the XHTML 2 spec.


<snip>

> ...in general don't confuse role handling with
> access @key mappings.

But the spec is explicitly mixing the two together.  See, that's my point!

> @role values and (default or user
> specified) key
> mappings for those values should just work if a user agent supports
> them.  I am not certain what the working group's position on this is,
> but my position would be that if there is an @key associated with an
> @role value, that would only be effective if there were no local
> setting.  (I have submitted a formal issue about precedence rules of
> @key in conjunction with @targetrole to the working group).

And if there are pre-existing local settings?  One of two options exist -
you the content author over-ride my settings (wrong), or supply broken
functionality and advertise it (wrong).  Review my chart - which key will
you chose?

> 
>> By allowing the author to get in the middle, you introduce that
>> "random" factor - the author is over-riding default behaviours.
>> 
> No.  Or rather, I think *no*.  More on this in the near future.
> 
> Thanks for your comments.  This is a good dialog, and has
> brought a few
> new issues to light.

Some other random thoughts:

* My understanding is that the XHTML 2 draft seeks to be a watershed
Recommendation, plotting the definitive language for the future.  Many new
items are being introduced (like <access>) which have never been available
before.  The W3C has taken great pains seeking to separate form from
function from design from behaviours.  I cannot think of any other semantic
mark-up element that specifically has a behaviour mechanism directly
attached to it like <access> does with @key. 

* That XML Events or DOM 3 events do not yet address the perceived
"requirement" of allowing the author to do key mappings (a position I
question) should have little bearing on authoring a semantic mark-up
language - you *know* it should be in those realms (scripting), but you're
sticking a band-aid on the issue because there is currently no other way of
doing it.  Wrong choice!

Thank you for taking the time to continue the discussion.

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 Wednesday, 8 June 2005 13:49:45 UTC