Re: [XHTML Access] must "activate" be boolean? (not must, but should)

summary at foot, but the bottom line is that it should remain boolean

On 14 Apr 2008, at 1:03 PM, Gregory J. Rosmaita wrote:

>
> disclaimer: i fully realize that simply because the XHTML Access
> Module is so named, it isn't a document that is intended for
> accessibility per se, but exists to define a standardized mechanism
> for anyone to access objects and elements from the keyboard, whatever
> form that keyboard might take...
>
> still, i have a question on the most recent working draft, given the
> second paragraph of Section 3.1.2.
>
> <quote
> cite="http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/ 
> #sec_3.1.2.">
>
> Triggering an access key defined in an access element changes focus to
> the next element in navigation order from the current focus that  
> has one
> of the the referenced role or id values. Note that it is possible to
> deliver alternate events via [XMLEVENTS]. It is also possible to  
> have the
> target element activated through the use of the activate attribute.
> Finally, it is possible to associate additional event handlers with
> target which might then perform additional actions once focus is  
> changed.
>
> </quote>
>
> must activate be boolean?  or, rather, can it logically be boolean,  
> given
> that alternate events may be available through the defined "key",  
> and it
> is usually the user who knows which event is most suitable for that
> user's needs...

The author's guess will be most suitable for most people most of the  
time.

In other words, this feature *is* designed for "author proposes, user
disposes" and the 'author proposes' part still adds value.

> which brings us to the the scenario where a user who wishes to move
> focus to an element for which an access element has been defined, but
> who needs to delay the event (if activate="yes") in order to inspect
> the object with focus for whatever options it might contain...  is the
> assumption that this be where an assistive technology kicks in by
> responding to an access command by moving focus and then -- through  
> the
> assistive technology's UI -- provide an exposition of possible
> actions/options, before the user decides to trigger the event?

AT is the user preference agent of last resort.  The browser may
offer the global option to rewrite @activate to 'no' or more subtle
@activate rewriting policies.  But the people who need to second-guess
the hotkeys the most are people who get along with the help of AT
at the current state of practice.  The point is that the 'user disposes'
should be implemented in AT, browser, or context-adaptive server and
not in the authoring process.

The authoring process leaves the necessary options open because
'focus' affords the user the opportunity to 'inspect' and the
markup leaves the control in the DOM where post-author processing
can overrule the author's proposal as necessary or preferred.

> there
> is a large population served by accessibility features that do NOT use
> nor need a dedicated assistive technology, so is it fair to place the
> onus for
>
> activate="inspect"

any difference between activate="inspect" and activate="no" should be
handled in onFocus processing of the destination object, and not in
the accelerator, pending richer XML Events as noted.

> on assistive technology, when, given the possibility of defining  
> multiple
> events for a single element, such a functionality should be built into
> the access module itself?  it is similar to the trigger concept,  
> endowing
> activate with an additional safety mechanism -- the ability to half- 
> cock
> the trigger before deciding whether or not to fire, at which target to
> fire (in the case of multiple targets/events, or whether to uncock the
> trigger...

Summary:

We should leave the 'activate' attribute boolean.

The user who wishes to always focus and not activate
will need to arrange their UA to overwrite onLoad this attribute
to not activate.  The format does its part
by putting the option in a state in a DOM attribute
where the user policies communicated to the client software
can overcall the author's proposed behavior.

Once the destination element is focused, inspection is appropriate
when the pattern of actions at the target element is unfamiliar.

accessible custom hotkeys:
http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0013.html

If an element accepts multiple events that dispatch different
actions, the system needs to provide a way for the user to
discover the multiplicity, and what the actions are and how
they are triggered.

There are a variety of ways to achieve this:

Element has a familiar role and the repertory of actions
reflects that role.  Role is reflected by the visible appearance
of the object and spoken / injected by AT.

Another is context help written by the author.  New and uncommon
actions should always have this.   With declarative handlers more
of this can be generated, but the state of practice isn't there
yet.  So the authors writing the scripted behaviors have to write
the hypertext help as well.  But they know that.

not that we shouldn't also tell them so.

Context help generated by the browser and/or AT based on inspecting
the DOM.  We have in the queue in DOM3 the ability to query what
events an object is sensitive to.

The main point is that if the user needs help noticing that they
need to inspect this object to ask "what can I do" then they
need to arrange their user software to automatically query the
context help and not just the author's tooltip onFocus.

And they need this whether they hotkeyed to the object or focused
it by tabbing.

If a user wants to selectively accept some hotkeys at the author's
level of fire-or-focus, but wants to inspect the destination object
of some hotkeys, there are a variety of approaches.

The onLoad processor that edits the @activate attribute on access
elements can have more subtle policies driven by selectors for trusted
actions (where the hotkey will activate) and those not on the whitelist
get forced to not activate.  Or the user can install a handler that  
responds to
a variant user input gesture based on the same mnemonic, but that  
only navigates
to the destination element per the access element as if @activate  
were negative.

The author knows which action they think their users will want  
automated.

The presumption in this design is that of the multiple actions on a
multi-action object, only one action per object will be on the  
'accelerate'
menu.  This is the dominant action of the object that is termed its
'activate' action.  This certainly covers the vast majority of shortcuts
attempted to date with ACCESSKEY.  This restriction only holds until XML
Events as planned is available.

The user may know which of the alternate actions they would prefer.  But
also only the user knows if they want to justDoIt or they want to dally
inspecting.

Forcing @activate on <access> to not-activate onLoad keeps the user in
firm control but requires the user to take more time and generate more
user input events.

The main reason that 'focus' is enough and 'inspect' is not suitable
as a value of the @activate attribute is that the difference between
them belongs bound to the destination object, and not on the  
accelerator.
The inspection is needed or wasted time as a function of the destination
object and its actions, familiar or unfamiliar; regardless of whether
focus arrives at that object as a result of the accelerator or some  
other
means.

Al

> gregory.
> -----------------------------------------------------------
> IMPARTIAL, adj.  Unable to perceive any promise of personal
> advantage from espousing either side of a controversy or
> adopting either of two conflicting opinions.
>                   -- Ambrose Bierce, The Devil's Dictionary
> -----------------------------------------------------------
>     Gregory J. Rosmaita: oedipus@hicom.net
>          Camera Obscura: http://www.hicom.net/~oedipus/
> Oedipus' Online Complex: http://my.opera.com/oedipus
> -----------------------------------------------------------
>
>

Received on Thursday, 24 April 2008 11:07:22 UTC