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:39:37 -0400
Message-ID: <E105C19702FF4DBC831AE928741113D4@HANDS>
To: "Jan Richards" <jan.richards@utoronto.ca>, "WAI-ua" <w3c-wai-ua@w3.org>

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 13:40:47 GMT

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