RE: access module summary

Gregory,
I see no problem with you putting up the extant and moving old versions/discussions to a different page.
Jim

> -----Original Message-----
> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
> Behalf Of Gregory J. Rosmaita
> Sent: Tuesday, May 13, 2008 11:52 AM
> To: Jim Allan; 'Jan Richards'; w3c-wai-ua@w3.org
> Cc: alfred.s.gilman@ieee.org; gez.lemon@gmail.com; chaals@opera.com
> Subject: RE: access module summary
> 
> 
> aloha, all!
> 
> thanks, jim, for the synthesis -- i agree with jan that it is the best
> verbiage we've been able to construct...  i have only one minor nit: the
> phrase "see 3.1.2" should actually be "consult section 3.1.1. Activate"
> 
> i also have a quick question -- shall i replace the extant text with
> jim's latest version before today's supplemental telecon?  if i do, i
> will move the extant text and extraneous text to a sub-page, such as:
> 
> http://www.w3.org/WAI/UA/wiki/KeyMappingBinding/Talk
> 
> talk to y'all at 2pm boston time,
> gregory.
> -------------------------------------------------------------------
> It is difficult to say what is impossible, for yesterday's dream is
> today's hope and tomorrow's reality.           -- Robert P. Goddard
> -------------------------------------------------------------------
> Gregory J. Rosmaita, oedipus@hicom.net
>       Camera Obscura: http://www.hicom.net/~oedipus/
>              Oedipus' Online Complexes: http://my.opera.com/oedipus
> -------------------------------------------------------------------
> 
> ---- Jim Allan <jimallan@tsbvi.edu> 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
> > >
> > >
> >
> >
> >
> >

Received on Tuesday, 13 May 2008 17:13:59 UTC