W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2008

minutes May 8

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 8 May 2008 17:15:54 -0500
To: "'WAI-UA list'" <w3c-wai-ua@w3.org>
Message-ID: <000001c8b159$158b3730$40a1a590$@edu>

http://www.w3.org/2008/05/08-ua-minutes.html


XHTML Access Module Rewording

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding

<Jan> http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement

<oedipus> JR's re-wording: "The access element assigns an accessibility
mapping to elements within a document. Actuating the mapping results in the
element gaining focus <INS>(either the document focus or an inspection
focus, as determined by the user agent), and, if set by the author and
permitted by the user's settings, in one or more other events being
activated.</INS> "

JR: Access element is where we have the most agreement.

if it is going to fire, it must be set by the author and approved by the
user agent.

The "optional" is redundent

<oedipus> plus 1 from GJR

<AllanJ> +1 on Jan Rewording

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement

reviewed JR rewording of access element definition and accepted Jan's
rewording.

JR has updated in wiki

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute

<oedipus> original wording: "The activate attribute indicates whether a
target element should be activated or not once it obtains focus. The default
value for this attribute is "no", indicating that the element will not be
"activated". User agents may provide mechanisms for overriding the setting
of the activate attribute. In such user agents, user-specified settings must
take precendence [sic]. "

<oedipus> GJR's re-wording: "The activate attribute indicates whether a
target element should be activated or not once it obtains focus. The default
value for this attribute is "no", indicating that the element will not be
"activated". User agents <INS>must provide a means of identifying the
shortcuts that can be used in a document. This may be accomplished in
different ways by different implementations, for example through direct
interaction with the application or via t

<oedipus> JR's re-wording: "The activate attribute indicates whether a
target element should be activated or not once it obtains focus. The default
value for this attribute is "no", indicating that the element will not be
"activated". User agents may provide mechanisms for overriding the author
setting with user-specified settings in order to ensure that the act of
moving content focus does not cause the user agent to take any further
action, as required by UAAG 1.0 (Chec

<oedipus> In any case, user agents MUST provide keyboard mechanisms for
"activating" any event associated with the focused element, as required by
UAAG 1.0 (Checkpoint 1.2).

<oedipus> "

take the second paragrash and move it to the keybinding section.

GR will update wiki to move all to the third section.

the info on providing a means of identifying the shortcuts will migrate to
the third section.

JA: 9.5 is also a P2

<Alan> Testing...

<Alan> Thanks Jeanne

Gez Lemen says we haven't addressed the issue of persistence.

scribe: he gives the example of alternate stylesheets that change back to
main when page is refreshed or changed. The access keys should also persist.

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding

JA: that should move to key binding and not stay in @activate.

when a user overrides the author's preferred key, that the user's preferred
key should presist. That should go to keybinding, not activate

<oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding

Resolution: accept JR rewording
keymapping GR rewrite

<oedipus> <INS>If an element accepts multiple events that dispatch different
actions, the user agent MUST provide a way for the user to discover the
multiplicity, what actions are available, and how they are triggered.</INS>

Needs to be discoverable. Add a phrase on the complexity of discovery.
Example of Word 07:

<oedipus> <INS>A conforming user agent MUST allow the user to override any
binding that is part of the user agent default input configuration except
for conventional bindings for the operating environment (e.g., for access to
help) or author-specified bindings. The keyboard combinations offered for
rebinding include single key and key plus modifier keys if these are
available in the operating environment, as specified in UAAG 1.0, Checkpoint
11.3</INS>

scribe: it is discoverable, but not usable. The multiplicity leads to a
situation where nobody will do it.
... can we put constraints on discoverability?

The information on how to execute a task is exposed (event handlers)

UAAG 1.0 11.3

JA: the user needs to know how to activate it, but still doesn't know what
will happen

What actions are available and how they are triggered, and what events are
available and how they are triggered?

Opera has a mechanism that will tell all the keys and allow remapping.

<oedipus> <INS>The author knows which action she thinks her users will want
automated. The user, however may know which of the alternate actions he
would prefer. Only the user knows if he wants to allow the events to fire as
defined by the author, or whether he needs to inspect the object to
determine which events to fire. Although the author can define multiple
actions for a multi-action object, only one action per object will be
displayed on the "accelerate" menu. This

JA concern that we are giving more functionality to the keyboard user than
the mouse user.

These event handlers need an explanation, recommended a "purpose" attribute
to XML2.

XML events 2 needs more work to bolster what information will be avilable to
the user agent and the technology

some of this isn't really relevant to access.

the activate will map to one thing, not the mouse up, or mouse down, etc.

It won't be concerned with the mouse up and down, just with the one thing
the event does.

scribe: the keyboard user doesn't really care about all the sequence of
events, they just want to know the main event.
... activate maps to that one main action.
... simplifies the @activate. Material written can be repurpused to XML 2

"we want the user agent to treat the activate as negative while it is being
quieried.

scribe: "

because @activate only reacts to a mouse click, does that mean that other
events, like mouseover do not have accessibility notifications?

with the mouseover, we want a whitelist. Like on hover over a submit, we
want the mouseover to say "you have not completed fields x. y"

scribe: this comes from scripts, not from user agent.

JB proposes we extend by 20 minutes for thorough discussion.

resolution: table rest of agenda to complete this issue.

GR cut out the excursion into event handling and moved other back in.

scribe: "A conforming user agent" and cites UAAG checkpoints.
... Added material that JR cut out of the other page.

JR: take it from the top and we say what pieces we say we want to keep and
have GR impose order on it.

+1 from JA.

del: It is also possible to have the target element activated through the
use of the activate attribute.
... it is already covered under @activate

JA: the sentence on XMLEVENTS stays because it is the first mention of it.
Agreed.
... if @targetrole and @targetid are specified, but the author did not
assign a key, the user agent should provide them.

??The user agent should assign or the user assigns?

These are the free keys you have available, pick one, then why not pick the
top one on the list?

<oedipus> The character assigned to a key, and its relationship to a role or
id attribute, are a suggestion of the author. User agents may provide
mechanisms for overriding, disabling, or re-assigning keys. In such user
agents, user-specified assignments MUST take precedence. <INS>A conforming
user agent MUST allow the user to override any binding that is part of the
user agent default input configuration except for conventional bindings for
the operating environment (e.g

if no key attribute is specified, the user agent MUST provide a mechanism
for the user assignment of a key.

"s/If/When the user agent assigns a key..."

JA: how will this work with mobile devices where there may not be a key.
that may be why they are using "character"

<oedipus>
http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_Character

if we are using a specific character set, use keys from that character set.

reword "key plus modifier keys or to a single key" to "modifier key plus
key..."

just put "keybinding", not specify the modifier key plus key or other
combinations

conflict with the sentence on "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)."

<oedipus> xhtml2

<scribe> ACTION: JR will follow up with XHTML2 [recorded in
http://www.w3.org/2008/05/08-ua-minutes.html#action01]

discussion on the displaying the value of the access key and how would the
user agent display thevalue if it is remapped?

The wording of "The character assigned to a key," is inherited from UAAG1.

are we saying that any key can be remapped, or are there keys that cannot be
used?

The user agent won't allow the user to remap to those reserved keys anyway.

Keys are available are a pool that are available to both users and authors.

JA: We can't go there, because it causes cross-browser problems. the user
agent decides what is avilable

the user then uses what is available. Get rid of all the keys and modifier
language.

JR: We need to wrap up.

JA will look for a space on Tuesday and put out a note to see who is
available.
Summary of Action Items
[NEW] ACTION: JR will follow up with XHTML2 [recorded in
http://www.w3.org/2008/05/08-ua-minutes.html#action01]
 
[End of minutes]

Jim Allan, Webmaster & Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 8 May 2008 22:19:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:57 GMT