SV_MEETING_TITLE -- 08 May 2008

<oedipus> i have to reboot my machine - haven't had time to reply to JR's comments, but i like his access rewording

<oedipus> hopefully the review will be quick....

<oedipus> off to reboot...

<Jan> scribe: Jeanne

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.

- DRAFT -

SV_MEETING_TITLE

08 May 2008

Attendees

Contents

XHTML Access Module Rewording

keymapping GR rewrite

Summary of Action Items

Scribe.perl diagnostic output