Re: access module summary

Hi Jim,

OK, your persistence wording looks ok to me.

Cheers,
Jan



Jim Allan wrote:
> Jan, 
> Very clean. 
> 
> Need to add the 'persistence' statement. Added it twice, once for user override, once for user agent supplied. Tried to combine them in one statement but the resultant statement was too cumbersome.
> 
> So 'tersification' with 'persistence'
> 
> 3.1.2. key = Character
> 
> This attribute assigns a key mapping to an access shortcut. An access key is a single character from the document character set.
> 
> Triggering the access key defined in an access element moves focus from its current position to the next element in navigation order that has one of the referenced role or id values (see 3.1.2 Activate for information on how the element may be activated). Note that it is possible to deliver alternate events via XMLEVENTS.
> 
> The invocation of access keys depends on the implementation. For instance, on some systems one may have to press an "alt" or "cmd" key in addition to the access key.
> 
> The character assigned to a key, and its relationship to a targetrole or targetid attribute SHOULD be treated as an author suggestion. User agents may override any key assignment (e.g., if an assignment interferes with the operation of the user interface of the user agent, if the key is not available on a device, if a key is used by the operating environment). Also user agents SHOULD allow users to override author assigned keys with their own key assignments (UAAG 11.3). If a user chooses to change the key binding, the resultant user-defined remapping SHOULD/MUST persist across sessions.
> 
> If no key attribute is specified, the user agent MUST assign a key and alert the author to the key mapping and the resultant user agent assigned key SHOULD/MUST persist across sessions.
> 
> The rendering of access keys depends on the user agent. We recommend that authors include the access key character in label text or wherever the access key is to apply. If the user agent can recognize that the currently mapped access key character appears in the label text of the element to which it is mapped, then the user agent may render the character in such a way as to emphasize its role as the access key and distinguish it from other characters (e.g., by underlining it).
> 
> A conforming user agent MUST also provide a centralized view of the current access key assignments (UAAG 11.1, 11.2).
> 
> Thoughts...
> Jim
> 
>> -----Original Message-----
>> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
>> Behalf Of Jan Richards
>> Sent: Monday, May 12, 2008 2:47 PM
>> To: unagi69@concentric.net
>> Cc: Jim Allan; w3c-wai-ua@w3.org; alfred.s.gilman@ieee.org;
>> gez.lemon@gmail.com; chaals@opera.com
>> Subject: Re: access module summary
>>
>>
>> Attempted "tersification"...
>>
>> 3.1.2. key = Character
>>
>> This attribute assigns a key mapping to an access shortcut. An access
>> key is a single character from the document character set.
>>
>> Triggering the access key defined in an access element moves focus from
>> its current position to the next element in navigation order that has
>> one of the referenced role or id values (see 3.1.2 Activate for
>> information on how the element may be activated). Note that it is
>> possible to deliver alternate events via XMLEVENTS.
>>
>> The invocation of access keys depends on the implementation. For
>> instance, on some systems one may have to press an "alt" or "cmd" key in
>> addition to the access key.
>>
>> The character assigned to a key, and its relationship to a targetrole or
>> targetid attribute SHOULD be treated as an author suggestion. User
>> agents may override any key assignment (e.g., if an assignment
>> interferes with the operation of the user interface of the user agent,
>> if the key is not available on a device, if a key is used by the
>> operating environment). Also user agents SHOULD allow users to override
>> author assigned keys with their own key assignments (UAAG 11.3). 
>>
>> If no key attribute is specified, the user agent MUST assign a key and
>> alert the author to the key mapping.
>>
>> The rendering of access keys depends on the user agent. We recommend
>> that authors include the access key character in label text or wherever
>> the access key is to apply. If the user agent can recognize that the
>> currently mapped access key character appears in the label text of the
>> element to which it is mapped, then the user agent may render the
>> character in such a way as to emphasize its role as the access key and
>> distinguish it from other characters (e.g., by underlining it).
>>
>> A conforming user agent MUST also provide a centralized view of the
>> current access key assignments (UAAG 11.1, 11.2).
>>
>>
>>
>> Thoughts?
>>
>> Cheers,
>> Jan
>>
>>
>>
>>
>> Gregory J. Rosmaita wrote:
>>> aloha, jim!
>>>
>>> what follows are my comments on your analysis of the state of the access
>>> module re-wording -- i have used four equals signs to indicate a change
>>> of topic/verbiage under consideration...
>>>
>>> CURRENT PROPOSED RE-WORDING 1:
>>> The rendering of access keys depends on the user agent. We recommend that
>>> authors include the access key in label text or wherever the access key
>> is
>>> to apply. <DEL>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).</DEL>
>>>
>>> <jim>I think the deleted section should stay. The author can only label
>> what
>>> the author knows about. And, should provide that information for all
>> users.
>>> IF a user chooses to change the binding, it should persist across
>> sessions
>>> (a UA issue not for this document).</jim>
>>>
>>> GJR: i agree, jim, but also understand why others are reluctant to retain
>>> it...
>>>
>>> PROPOSED GJR: The rendering of access keys depends on the user agent. We
>>> recommend that authors include the access key in label text or wherever
>>> the access key is to apply. 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 <INS>in a manner consistent with the user's
>>> pre-defined preferences.</INS> <DEL>(e.g., by underlining it).</DEL> If
>>> a user chooses to change the key binding, the resultant user-defined
>>> remapping SHOULD/MUST persist across sessions.
>>>
>>>
>>> ====
>>> CURRENT PROPOSED RE-WORDING 2:
>>>
>>> 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 the user's guide. The key defined by the author might not be made
>>> available by the user agent (for example, it may not exist on the device
>>> used, or it may be used by the user agent itself).</INS>
>>>
>>> <jim> suggest removing the <ins> seems redundant give previous paragraphs
>>> about override and centralized view. The <ins> seems more of a UAAG
>>> technique.</jim>
>>>
>>> GJR: the original (14 april 2008) Access Module draft contains the
>>> following, which the INSerted text was meant to clarify -- if the WG
>>> agrees that enough clarification has already been provided, shall we
>>> return the paragraph to its original wording:
>>>
>>> ORIGINAL WORKING DRAFT 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].
>>>
>>> GJR: i would still prefer that we make the "must" in the final sentence
>>> a normative RFC2119 "MUST", and am sorely tempted to change: "User
>>> agents may provide" to (at the VERY least) a normative RFC2119 "SHOULD",
>>> so that the last 2 sentences would read
>>>
>>> <GJR2>
>>> User agents SHOULD provide mechanisms for overriding the setting of the
>>> activate attribute. In such user agents, user-specified settings MUST
>>> take precedence.
>>> </GJR2>
>>>
>>> ====
>>> CURRENT PROPOSED RE-WORDING 3:
>>>
>>> <INS>Therefore, the user agent MUST make the specified action(s)
>> available,
>>> but may map the shortcut to a different user interaction behavior. Note
>> that
>>> timely notification of any remapping or reassigning of an author-defined
>>> "key" MUST be issued to the user through the user agent's native
>> interface,
>>> so that the user is aware of the reconfiguration. A user agent SHOULD
>>> provide a broad option of alert mechanisms, all of which must be issued
>> in
>>> conformance with user-defined settings for alert mechanisms (for example,
>> if
>>> an audio file is played to signify remapping or reassignment, it must be
>>> fired in such a way that the operating system's "Show Sounds" or "Sound
>>> Sentry" or equivalent mechanism can be used to alert a user whose device
>> is
>>> incapable of rendering the aural cue or for whom the processing of an
>> audio
>>> clip is either impractical or impossible).</INS>
>>>
>>> <jim>This also seems like a UAAG technique. To me, it provides too much
>>> information for the Access Module. I think the statements and references
>> in
>>> the previous paragraph referencing relevant checkpoints is sufficient.
>> This
>>> <ins> should be deleted </jim>
>>>
>>> GJR: if we delete the paragraph from the current re-wording, as you
>>> recommend, then we should add it (the spirit of the principle, if not the
>>> actual wording) to UAAG 2.0's discussion of discovery and alerts (at the
>>> very least in the techniques document), especially as, once the access
>>> module is sent to LC by the XHTML2 WG, i plan on submitting it to the
>> HTML
>>> WG, as per the initial request of the HTML WG by al gilman on behalf of
>>> PF/WAI, archived at:
>>>
>>> http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html
>>>
>>> which specifically calls for either adoption or adaptation of the ACCESS
>>> element into HTML5...
>>>
>>> gregory.
>>>
>>> ---- Jim Allan <jimallan@tsbvi.edu> wrote:
>>>
>>>> Open issues
>>>> 1. Gez question about "Persistence" of users override of author "key"
>> value.
>>>> This should go in Keybinding
>>>> 2. Keybinding - see comments below
>>>>
>>>>
>>>> Unless there are serious issues related to the AccessElement and the
>>>> ActivateAttribute (approve wording below) I would like us to focus on
>> the
>>>> Keybinding editing.
>>>>
>>>> We have approved the following wordings:
>>>> http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement
>>>> The access element assigns an accessibility mapping to elements within a
>>>> document. Actuating the mapping results in the element gaining focus
>> (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.
>>>> =======
>>>> http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute
>>>> 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,
>>>> Checkpoint 9.5.
>>>>
>>>> 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.
>>>> ======
>>>> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding
>>>>
>>>> This attribute assigns a key mapping to an access shortcut. An access
>> key is
>>>> a single character from the document character set. (editor's note: the
>>>> following sentence should either be moved or deleted entirely)
>> <DEL>Note:
>>>> Authors should consider the input method of the expected reader when
>>>> specifying an accesskey.</DEL>
>>>> <jim> ok </jim>
>>>>
>>>> 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
>>>> 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. <INS>If an element accepts
>>>> multiple events that dispatch different actions, the user agent MUST
>> provide
>>>> a way for the user to discover the all events, which events are
>> available,
>>>> and how they are triggered.</INS>
>>>> <jim> I have concerns about the <ins> about multiple events, the
>> activate
>>>> will only active one thing. </jim>
>>>>
>>>> An access element <INS>MUST</INS> have either a targetrole or a targetid
>>>> attribute specified. If neither a targetrole nor a targetid attribute
>> are
>>>> specified, the user agent MUST NOT define a mapping nor deliver any
>> events.
>>>> <jim> ok</jim>
>>>>
>>>> The invocation of access keys depends on the implementation. For
>> instance,
>>>> on some systems one may have to press the "alt" key in addition to the
>>>> access key. On other systems, one generally has to press the "cmd" key
>> in
>>>> addition to the access key. A conforming user agent MUST allow the user
>> to
>>>> override any author-defined binding.
>>>> <jim> ok</jim>
>>>>
>>>> The rendering of access keys depends on the user agent. We recommend
>> that
>>>> authors include the access key in label text or wherever the access key
>> is
>>>> to apply. <DEL>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).</DEL>
>>>> <jim>I think the deleted section should stay. The author can only label
>> what
>>>> the author knows about. And, should provide that information for all
>> users.
>>>> IF a user chooses to change the binding, it should persist across
>> sessions
>>>> (a UA issue not for this document).</jim>
>>>>
>>>> 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., for access to help). The keyboard
>>>> combinations offered for rebinding SHOULD 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>
>>>> <jim> ok</jim>
>>>>
>>>> If no key attribute is specified, the user agent MUST assign a key.
>>>> <INS>When a user agent assigns key values to access elements that have
>> no
>>>> key defined for them, the user MUST provide the user with multi-modal
>>>> notification that keys have been defined for the following values: x, y,
>> z,
>>>> etc. and that there are no specific keys defined for "foo" and "bar", so
>>>> "foo" and "bar" have been assigned keys 1 and 2.</INS>
>>>> <jim> ok - "the user MUST provide the user with multi-modal..." should
>> be
>>>> "the user agent MUST provide the user with multi-modal..."</jim>
>>>>
>>>> <INS>A conforming user agent MUST also provide a centralized view of the
>>>> current author-specified input configuration. (UAAG 1.0, Checkpoint
>>>> 11.2)</INS>
>>>> <jim> ok</jim>
>>>>
>>>> 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 the user's guide. The key defined by the author might not be made
>>>> available by the user agent (for example, it may not exist on the device
>>>> used, or it may be used by the user agent itself).</INS>
>>>> <jim> suggest removing the <ins> seems redundant give previous
>> paragraphs
>>>> about override and centralized view. The <ins> seems more of a UAAG
>>>> technique.</jim>
>>>>
>>>> <INS>A keyboard user will not know the value of activate when invoking
>> the
>>>> appropriate 'key' defined for an ACCESS element. A conformant user agent
>>>> MUST, therefore, allow the user to exercise control over the user
>> interface
>>>> in accordance with the requirements set forth by the User Agent
>>>> Accessibility Guidelines, 1.0 [UAAG10]:
>>>>
>>>>     *
>>>>
>>>>       Allow the user to activate, through keyboard input alone, all
>> input
>>>> device event handlers that are explicitly associated with the element
>>>> designated by the content focus. (UAAG 1.0, Checkpoint 1.2)
>>>>     *
>>>>
>>>>       Allow configuration so that moving the content focus to or from an
>>>> enabled element does not automatically activate any explicitly
>> associated
>>>> event handlers of any event type. (UAAG 1.0, Checkpoint 9.5)
>>>>     *
>>>>
>>>>       For the element with content focus, make available the list of
>> input
>>>> device event types for which there are event handlers explicitly
>> associated
>>>> with the element. (UAAG 1.0, Checkpoint 9.6)</INS>
>>>> <jim> ok</jim>
>>>>
>>>> <INS>Therefore, the user agent MUST make the specified action(s)
>> available,
>>>> but may map the shortcut to a different user interaction behavior. Note
>> that
>>>> timely notification of any remapping or reassigning of an author-defined
>>>> "key" MUST be issued to the user through the user agent's native
>> interface,
>>>> so that the user is aware of the reconfiguration. A user agent SHOULD
>>>> provide a broad option of alert mechanisms, all of which must be issued
>> in
>>>> conformance with user-defined settings for alert mechanisms (for
>> example, if
>>>> an audio file is played to signify remapping or reassignment, it must be
>>>> fired in such a way that the operating system's "Show Sounds" or "Sound
>>>> Sentry" or equivalent mechanism can be used to alert a user whose device
>> is
>>>> incapable of rendering the aural cue or for whom the processing of an
>> audio
>>>> clip is either impractical or impossible).</INS>
>>>> <jim>This also seems like a UAAG technique. To me, it provides too much
>>>> information for the Access Module. I think the statements and references
>> in
>>>> the previous paragraph referencing relevant checkpoints is sufficient.
>> This
>>>> <ins> should be deleted </jim>
>>>>
>>>> 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
>> --
>> Jan Richards, M.Sc.
>> User Interface Design Specialist
>> Adaptive Technology Resource Centre (ATRC)
>> Faculty of Information Studies
>> University of Toronto
>>
>>    Email: jan.richards@utoronto.ca
>>    Web:   http://jan.atrc.utoronto.ca
>>    Phone: 416-946-7060
>>    Fax:   416-971-2896
>>
>>
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Tuesday, 13 May 2008 13:10:51 UTC