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

Re: Minutes from Special Meeting User Agent Teleconference for 13 May 2008

From: David Poehlman <poehlman1@comcast.net>
Date: Wed, 14 May 2008 09:58:10 -0400
Message-ID: <30B7CFA2D4544DB78BFBE41C50510362@HANDS>
To: "Jan Richards" <jan.richards@utoronto.ca>
Cc: "WAI-ua" <w3c-wai-ua@w3.org>

I see this.  It seems to be somewhat contrary to the track though.  If these 
are positions, perhaps another word than may would reflect this better or a 
construct to better reflect these as positions.  I gather that this is an 
exception tool with which I can agree.

----- Original Message ----- 
From: "Jan Richards" <jan.richards@utoronto.ca>
To: "David Poehlman" <poehlman1@comcast.net>
Cc: "WAI-ua" <w3c-wai-ua@w3.org>
Sent: Wednesday, May 14, 2008 9:47 AM
Subject: Re: Minutes from Special Meeting User Agent Teleconference for 13 
May 2008


Hi Dave,

Thanks for reading things over. I think the word "may" reflects the
complexity of this. For example:

- a user agent may decide to respect access keys in the content above
its own user interface keyboard commands.
- the user agent may not know what type of keyboard is available (e.g.
on a cell phone)
- the user agent may not know what keys the operating environment will take.

Cheers,
Jan



David Poehlman wrote:
> Reading through this, I see:
> ..."The character assigned to a key, and its relationship to a role or id
> 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).", 
> and
> the word "may" jumpped out at me and caused me to reflect upon our concern
> over conflict which we clearly state early on is not alloud.  Should "may"
> not then be changed here?
>
> Thanks!
>
> ----- Original Message ----- 
> From: "Jan Richards" <jan.richards@utoronto.ca>
> To: "WAI-ua" <w3c-wai-ua@w3.org>
> Sent: Tuesday, May 13, 2008 3:16 PM
> Subject: Minutes from Special Meeting User Agent Teleconference for 13 May
> 2008
>
>
>
> Minutes:
> http://www.w3.org/2008/05/13-ua-minutes.html
>
> Action Items:
> None
>
> Full Text:
> <oedipus> having really nasty hardware problems -- will dial in 
> momentarily
>
> <oedipus> can't get on zakim... conference full..
>
> <oedipus> ok, glad it isn't just me -- one computer died and another
> isn't working right (won't let me copy-and-paste)
>
> <oedipus> just send a post to the ua list -- will try and mirror
> contents on wiki as i was attempting before my last reboot
>
> gregory, what's your home number?
>
> We'll try to conference you in
>
> <oedipus> yes
>
> <oedipus> shall i try again?
>
> <oedipus> wiki version of GJR's latest post:
> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding?action=show#head-207273ee9925092c36445764808702fc23379f8a
>
> please give us your phone number and we will try calling you
>
> <AllanJ> what is your home phone we will try and conference you in
>
> <oedipus> +1 973 746 1192
>
> <scribe> Scribe: Jan
>
> <KFord> phoning now.
>
> <oedipus> older re-write moved to:
> http://www.w3.org/WAI/UA/wiki/KeyMappingBinding/Talk
>
> <AllanJ> Discussion of gregory's 3 issues
>
> <AllanJ> 1. <INS> An access element must 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. </INS> was dropped
>
> <AllanJ> all: agree to re-insert into document
>
> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding
>
> <oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute
>
> <oedipus> http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement
>
> http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement
>
> <AllanJ> all: move rollid statements into Access Element section
>
> <oedipus> UAAG chp 1.2 chp 9.5 chp 9.6 ckp 11.4
>
> <oedipus> UAAG 1.0 1.2 and 9.5 addressed in
> http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute
>
> <oedipus> missing from rewording previously cited UAAG 1.0 checkpoints
> 9.6 and 11.4
>
> <AllanJ> discussion of keybinding override implementation
>
> <AllanJ> ...and SHOULD or MUST requirement
>
> <oedipus> 2. Conformance Requirements
>
> <oedipus> This section is normative.
>
> <oedipus> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
> are to be interpreted as described in [RFC2119].
>
> <oedipus> Note that all examples in this document are informative, and
> are not meant to be interpreted as normative requirements.
>
> <oedipus> key words for use in RFCs to indicate requirement levels:
> http://www.rfc-editor.org/rfc/rfc2119.txt
>
> <AllanJ> JR: test case: author thinks through the controls. then a user
> wants to remap due to range of motion to concentrate keys on left side
> of keyboard
>
> <AllanJ> KF: or using an AT, and the author key conflicts with AT,
> yes...can bypass the key but gets tedious, so user remaps author key to
> not conflict with AT
>
> <oedipus> www.foobar2000.org
>
> <oedipus> all basically, author proposes, user disposes
>
> <oedipus> RFC 2119: 1. MUST This word, or the terms "REQUIRED" or
> "SHALL", mean that the
>
> <oedipus> definition is an absolute requirement of the specification.
>
> <oedipus> RFC 2119: "3. SHOULD This word, or the adjective
> "RECOMMENDED", mean that there may exist valid reasons in particular
> circumstances to ignore a particular item, but the full implications
> must be understood and carefully weighed before choosing a different
> course."
>
> <AllanJ> SHOULD make available the list of input device event types for
> which there are event handlers explicitly associated with the element.
>
> Review work
> <AllanJ> Access element wording
>
> <AllanJ> JR: +1
>
> <AllanJ> GR: +1
>
> <AllanJ> KF: +1
>
> <AllanJ> JA: +1
>
> <AllanJ> Activate element wording:
>
> <AllanJ> JR: +1
>
> <AllanJ> KF: +1
>
> <AllanJ> GR: +1
>
> <AllanJ> JA: +1
>
> <AllanJ> Key binding wording:
>
> <AllanJ> JR: +1
>
> <AllanJ> GR: +1
>
> <AllanJ> KF: +1
>
> <AllanJ> JA: +1
>
> <AllanJ> all final approved wordings are found in the Propose Wording
> sections of the following
>
> URLS: http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement
>
> http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute
>
> http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding
>
> In all 3 cases, the relevant section is: "Proposed Re-Wording"
>
> 3.1. The access element
>
> 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.
>
> An access element must 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.
>
> 3.1.1. activate = ( yes | no* )
>
> 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...
>
> scribe: take any further action (UAAG 1.0, Checkpoint 9.5).
>
> User agents MUST provide keyboard mechanisms for "activating" any event
> associated with the focused element (UAAG 1.0, Checkpoint 1.2) and
> SHOULD make available the list of events associated with the element
> (UAAG 1.0, Checkpoint 9.6).
>
> 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 (consult Section 3.1.1, 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 role or id
> 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).
> User agents SHOULD also allow users to...
>
> scribe: override author assigned keys with their own key assignments
> (UAAG 1.0, Checkpoint 11.3). If a user chooses to change the key
> binding, the resultant user-defined remapping SHOULD persist across
> sessions.
>
> If no key attribute is specified, the user agent SHOULD assign a key and
> alert the user to the key mapping and the resultant user agent assigned
> key SHOULD 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...
>
> scribe: role as the access key and distinguish it from other characters
> (e.g., by underlining it).
>
> A conforming user agent SHOULD also provide a centralized view of the
> current access key assignments (UAAG 1.0 Checkpoint 11.1, UAAG 1.0
> Checkpoint 11.2).
>
>
>
>
>
>
>
>
>
> Jim Allan wrote:
>> Apologies for the short notice. We have a deadline to get the completed
>> for
>> XHTML by May 14.
>> Hopefully this works for folks and schedules permit participation.
>> We got pretty close on completing the work on the Access Module. But we
>> need
>> some more ear-2-ear time. Any effort on list and wiki to resolve wording
>> before Tuesday's call is appreciated.
>>
>> User Agent Teleconference for 13 May 2008
>> ------------------------------------------------------------
>> Chair: Jim Allan
>> Date: Tuesday, 13 May 2008
>> Time: 2:00-3:00 pm Boston Local Time, USA (19:00-20:00 UTC/GMT)
>> Call-in: Zakim bridge at: +1-617-761-6200, code 82941# for UK use
>> 44-117-370-6152
>> IRC: sever: irc.w3.org, port: 6665, channel: #ua.
>> -------------------------------------------------------------
>>
>> Agenda:
>>
>> 0. Regrets, agenda requests, or comments to the list
>>
>> 1. Choose a scribe
>>
>> 2. XHTML Access module - keyboard access, accesskey, event firing
>> a.
>> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0088.html
>>
>> 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 Wednesday, 14 May 2008 14:10:12 GMT

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