- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 10 Jul 2008 21:01:30 +0100
- To: w3c-wai-ua@w3.org
aloha, all!
minutes from the 10 july 2008 UA WG telecon are available at:
http://www.w3.org/2008/07/10-ua-minutes.html
and are attached as plain text following my signature; there is also
an IRC log located at:
http://www.w3.org/2008/07/10-ua-irc
as usual, any errors, misattributions, omissions, clarifications, and
corrections should be logged by replying to this post on-list
please remember that, at least for the next few meetings, the UA WG call
will last 90 minutes, beginning at 1900h UTC (2pm to 3:30pm Boston time)
gregory.
- DRAFT -
User Agent Weekly Teleconference
10 Jul 2008
Agenda
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0012.html
See also: IRC log
http://www.w3.org/2008/07/10-ua-irc
Attendees
Present
+1.512.206.aaaa, Gregory_Rosmaita, Jan_Richards, Jeanne,
Jim_Allan, Judy, Mark_Hakkinen
Regrets
Kelly_Ford, Alan_Cantor
Chair
Jim
Scribe
Gregory_Rosmaita
Contents
* Topics
1. Regrets, agenda requests, comments?
2. Review of Action Items
3. Keyboard access and visibility of keyboard controls
4. 4.1.7
5. 4.1.8
6. 4.1.9
7. Wrapping Up
* Summary of Action Items
_________________________________________________________________
<AllanJ> title: UAWG Telecon
aloha, jim! thanks -- sorry for no explanation - health and
infrastructural problems both
i will scribe (my penance, part 1)
<scribe> Scribe: Gregory_Rosmaita
<scribe> ScribeNick: oedipus
Regrets, agenda requests, comments?
JA: mark may join
JB: was here last week
... agenda additions?
JA: noticed that working on success criteria, not specific guidelines
JB: everything with 3 numbers
JA: may be confusing; need to be reworded so are testable
JB: at least 1 (4.1)
JA: everything else working on in area are SC - normative bits for
keyboard access
JB: level should be working on?
JA: yes
... full keyboard access has a lot that needs to be included -
bindings, remappings, etc.
... how far did we get?
JB: new block of proposals from Jeanne; sorted out 1 or 2 and
identified 1 or 2 for follow up
... move forward from that point - if need to backtrack for
wordsmithing, can check at end of meeting
... ok?
JA: fine
Review of Action Items
<scribe> ACTION: SH draft new rationale text for 4.1 keyboard
shortcuts [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action01]
trackbot, drop action 1
JA: Jan? resizing window techs
JR: examined with Jeanne and am ok with what we ended up with - Jeanne
did you send to group?
... one piece in following URI
<Jan> Keyboard Operation: All functionality can be operated via the
keyboard using sequential and/or direct keyboard commands that do not
require specific timings for individual keystrokes, except where the
underlying function requires input that depends on the path of the
user's movement and not just the endpoints (e.g., free hand drawing).
This does not forbid and should not discourage providing...
<jeanne> http://www.w3.org/WAI/UA/2008/keyboardProposals20080709.html
<Jan> ...mouse input or other input methods in addition to keyboard
operation.
<Jan> 4.1.1
Jeanne: updated
JR: am happy
JA: reading - confused - where does it adress resizing windows?
JR: just because requiring keyboard a11y, have to ensure don't break
mouse access
http://www.w3.org/WAI/UA/2008/keyboardProposals20080709.html
JB: Mark, action item status?
MH: hand-written notes - have actual text on laptop - need to pull
off; looked at ATAG as model for rationale; some text there, but 4.1
"Ensure Keyboard Access" is verbatim from ATAG; others not so good;
will post to list when get laptop working again
... draft comments will be posted ASAP - hopefully later today
JB: action items - need to check and see if Simon posted to list and
can close actions
<jeanne>
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0006.html
JB: his point is if can't articulate rationale don't include; wants us
to backup every rationale where possible with references from
scientific literature; wary of that - JTC1 has tried that and there
are a lot of risks in doing that; literature isn't comprehensive, will
follow-up on list and should address in future meeting
JA: second that; while laudable, have a lot of other issues and tasks
that need work
JB: might be a mismatch; could link from an "understanding" document,
but weird things happen when try to do that in primary doc
JS: dates document more rapidly
<Judy> ACTION: jb reply to multiple concerns on SH's suggestion about
linking literature references from UAWG 2.0 [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action02]
JB: can't link to external references from guidelines themselves
MH: something living independent of guidelines?
JA: have many other tasks and techniques to draft and review
JB: other Action Item or Agenda Review items?
JA: rationale for 4.1 was action item - keep on through SC
JB: don't need rationale for SC?
JA: ATAG does only for top level guidelines
JB: didn't realize shouldn't be doing rationale at that level
JA: personally, not as chair, think is over kill
JR: understanding UAAG document would cover it; WCAG doesn't do it per
SC, but address in understanding doc
JB: haven't committed to "understanding" doc - what do WG members
think?
scribe's note: silence
JA: have enough on plate - good idea, but how to find cycles
JB: curious how many read email from 4 july 2008
http://lists.w3.org/Archives/Public/w3c-wai-ua//2008JulSep/0006.html
JB: proposes rationale for a lot of 4.x - what do we think about this?
should go into understanding document if one created; would benefit
adopters, but how useful and how necessary; do we agree with what SH
wrote?
... 4.1.1 to 4.1.6 - what do people think about proposed text?
JR: good explanations of why those things are SCs; more development
overhead from doc development POV; would be easier to produce if doc
more stable
JA: should state that will create document if have time; always have
rational for SC, but not in formal listing; formal listing useful, but
what will we do with it in future? think need GLs first, test suite
next, then listing
JS: too long - one sentence rationales was aim; a lot more readable
and powerful to have sentence than paragraph
MH: goal is "as short and concise a rationale statement" -
JB: my take on these and comments on them is a concern: interesting
and helpful to think about SC (helps focus on it and whether worded
right) on other hand, approach is inconsistent
... main approach SH uses is to give negative examples
... "if such isn't available... then user won't be able to do ..."
... preferential statement requirements mixed in; if keep, have to
shoehorn them all into a standard type of statement
MH: tried to keep to consistent format -
JB: like a formula for each
MH: yes
... step plus whatever
JA: SH's work is useful, but not immediately; is important, but needs
to be reworded and be put into supplemental document
JB: think is important - if use would NEED to go in supplemental doc
and not sure if WG will have resources to produce supplemental doc
... appreciate SH and MH's energy, but focus on documents we have to
do
... troubles me slightly is for 1 through 6 came up with rationales
that need rewording; for second half, the attempt to write a rationale
triggered a "wait a minute?" reaction; could be due to newness to
group or great way to quality check what we've done
JA: second half more granular because subsets of what came before (in
1 through 6)
... 4.9 seems like part of 4.1.2 and that's why double-A
JB: not most efficient time to do these b/c will force us to cycle
through questions that already are marked for clarification
JA: call out rationales, collect them for use if can make explanatory
doc
JB: Mark x.1.1 level or x.1 level
MH: x.1 level
ack me'
<AllanJ> GJR: collect these on the wiki page, and work on refining as
time permits
JB: will include request in my note to SH
<AllanJ> request is for collecting rationale on wiki
Keyboard access and visibility of keyboard controls
JA: Jeanne posted both proposals?
JS: really only 1 - 2 variants; JR and i worked on it and have revised
4.1.5 and 4.1.x
<jeanne> http://www.w3.org/WAI/UA/2008/keyboardProposals20080709.html
JA: move onto 4.1.6
... proposed "no change"
<AllanJ> 4.1.6 Standard Text Area Conventions: Views that render text
support the standard text area conventions for the platform including,
but not necessarily limited to: character keys, backspace/delete,
insert, "arrow" key navigation (e.g., "caret" browsing), page up/page
down, navigate to start/end, navigate by paragraph, shift-to-select
mechanism, etc.
JA: reads from proposal
JB: maintaining platform consistency to reduce congnative burden - but
explanation is a bit of a cognative burden
GJR: seconds that
JA: most platforms have CTR+RightArrow will always move by word
JB: nomenclature questions -- need clear concise titles
... one question is what is our goal in terms of standard language
format for 4.1 GL
... extant text makes sense - a statement/command
... SC level are noun phrases
... is it our intent to leave like that instead of a statement of what
these things are?
... what are standard TEXTAREA conventions?
JA: In ATAG contains short keywords
... good to raise if makes more understandable
... important to have outsider review
JB: ATAG SC 8.1.3.1 - not consistent
JS: WCAG SC are 2.1.1 keyboard 2.1.2 no keyboard trap 2.1.3 no
exceptions
JB: noun-phrase but descriptive
JR: can you tell?
JB: perhaps not always
... very short keywords
JA: been following example set by others
JB: majority of ATAG SC are short keywords
... 4.1.6 - will comment on it offline
JA: only thing i think should have is standard TEXTAREA navigation
convention so we know talking specifically about keyboard navigation
<Zakim> oedipus, you wanted to ask if should collect in UAWG wiki
page? and to say PF is addressing this with TEXTAREA and ARIA
JR: agree with JimA at this point
MH: nothing to add
JB: in this case, would be easy to put verb in front =
... "use ..."
... others may not be so easy to
JA: verbify
JB: exactly; good keyword makes text more understandable
... need to orient developer
JA: principles and GLs are verbified, SCs are mostly noun keywords
JB: online discussion or editors' discussion?
... could gather few editing items and put on agenda to address one by
one
proposed ACTION: Judy and Jeanne - figure out right time and place to
cluster editorial issues to get UAAG2 more consistent - verbify
keywords for SC
<scribe> ACTION: Judy and Jeanne - plan time and place to discuss
cluster of editorial issues to get UAAG2 more consistent - address
verbification of keywords for SCs [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action03]
<Judy> ACTION: JA, JB, JS to figure a time & place to discuss a bunch
of editorial issues (such as whether to "verbify" the success
criteria) [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action04]
rssagent, make minutes
JB: 4.1.6 - no changes other than our discussion above about heading
phrasing - other comments?
JA: add word "navigation" before convention
... close 4.1.6, move on to 4.1.7
<AllanJ> 4.1.7 User Interface Navigation: The user can use the
keyboard to traverse all of the controls forwards and backwards,
including controls in floating toolbars, panels, and user agent
extensions using the conventions of the platform (e.g., via "tab",
"shift-tab", etc. ")
i/4.1.7. User/TOPIC: 4.1.9
4.1.7
JS: chrome navigation versus UI navigation
JB: had chrome discussion last week - trying to be careful to reduce
use of it where possible, since defining differently from where using
in certain places encased in quotes - not universal dev jargon;
appreciate were we go to with that
JA: glad discussing this again; in past, over a year ago, had
discussed separating UAAG into 2 parts: 1) everything to do with UI
with SC; 2) section on just content/viewport a11y stuff with GLs for
keyboard and DI; 1 part for UI 1 part for content
... confusing in UAAG 1.0 - should readdress this now
... how to keep straight UI of chrome versus UI of content/viewport
JB: keep honing in on titles of SCs - this title is misleading
... "using conventions of the platform" overlaps with requirement in
4.1.6; less about UI navigation and more about keyboard access TO
keyboard navigation
... reviewed other SCs - ought to change title - sounds like random
bit about navigation, but this is something we are keying in on and
want maximum exposure
JS: example of what rather see?
JB: keyboard access to keyboard navigation
... too long? is it in the right place? should be called something
else, would belong where currently is
JA: last bunch specific to UI; understand JB's issue with keyword
intro; description addresses keyboard
GJR plus one to JB's Keyboard Access to Keyboard Navigation
JR: looking at 4.1.1. - all functionality can be operated from the
keyboard..."
JB: redundant
JR: user can traverse all controls sequentially
JB: redundant
JR: not necessarily - not all controls, but all functionality - can't
get to panels, but can get to menus
JB: "all functionality" sounds inclusive to me
JR: would drop to double-A
JA: yes
JR: if something on toolbar, should be able to get to it somehow
JA: mis-spoke - is single A
JB: 4.1.7 sufficiently covered by any differences should be folded
into 4.1.6 unless something significantly different to warrant
separation
... 4.1.6 standard conventions of platform
JR: 4.1.7 adds to 4.1.1
JA: 4.1.1 history is got granular because overall base user agent
covered by 4.1.1 and trying to get granular in 4.1.7 - if add
extension to UA, provide keyboard interface
JB: should be in 4.1.1
MH: 4.1.7 - user agent extensions; what if developed on one platform
that is inconsistent on other platforms
... potential problem
should i log ACTION: Jan & Jim - review 4.1.1, 4.1.6, and 4.1.7 for
redundancy ???
<scribe> ACTION: Jan & Jim - review 4.1.1, 4.1.6, and 4.1.7 for
redundancy ??? [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action05]
JB: more we can distill these down, the better it will be for all
... move on to 4.1.8
4.1.8
<AllanJ> 4.1.8 Ensure Keyboard Commands: Any user interface component
that can receive focus has a keyboard command unless the operating
environment prevents it. Currently visible user interface components
visually indicate their keyboard shortcuts.
JA: used to be huge and proscriptive; pulled from UAAG1, been
tersified
... wording contains a confusing part
JB: this is one where need to de-verbify to be consistent with current
format; if did wouuld be indistinguishable from others in section;
helps with skim reading, which is important
... devs want ability to skim and understand scope on skim
... in terms of phrasing, first sentence makes sense
JA: original stated user has option to enable keystrokes to particular
function; that concept fell out in this proposal
JR: some things so important need keyboard access, now saying need
keyboard access to everything
JB: 4.1.8 is redundant with 4.1.5
JS: didn't get sense of uniqueness in 4.1.8 - important, need clear
way to say; easy to get lost
JA: level 2, so is extension of 4.1.5
JR: 4.1.1 says sequential or direct to get to all functionalities; in
this case, these set of things have to be accessible; then we state
you need to programmatically indicate them
JA: path of finer granularity
JB: 4.1.5 - show on screen and programmatically; looking at 4.1.5 one
problem that i've seen is confusion between programmatic access and
people turning into an either or
... 4.1.5 should be split so absolutely no confusion
... wonder if would be advantage to split, because use cases could be
handled differently
... do those things apply to programmatic bindings as well as visual
indicators
JR: 4.1.x that Jeanne and i proposed split thte other way UA commands
(open menu item) and recognized commands from content (accesskey)
scribe's note: #60 to mute, #61 to unmute
scribe's note: #40 to raise hand; #41 to lower hand
JR: agree with JB's division - need to ensure people see as AND and
not OR
JB: opportunity to clarify other items, too
... original meaning somewhat lost; what have now is redundant; need
fresh effort to rewrite 4.1.8
<scribe> ACTION: Jeanne - propose rewrite for Section 4.1.8 [recorded
in http://www.w3.org/2008/07/10-ua-minutes.html#action06]
JB: for next pass, leave this intact as background and have one page
on which the most stripped down version of latest proposals are
presented sequentially (refer only as "used to be x.x.x" - don't want
to trip WG up over too much history; streamlined view will facillitate
scrubbing up
GJR: plus 1
JS: plus 1
<scribe> ACTION: Jan - propose rewrite for 4.1.5 and nex 4.1.x
[recorded in http://www.w3.org/2008/07/10-ua-minutes.html#action07]
JS: put into editors draft to be reviewed in context
JB: may be one week away from doing that
proposed ACTION: Jeanne - build new streamlined framework (1 or 2
sentences for each SC)
<scribe> ACTION: Jeanne - build new streamlined framework for 4.1.* (1
or 2 sentences for each SC) [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action08]
4.1.9
<AllanJ> 4.1.9 Precedence of Keystroke Processing: Keystrokes are
processed in the following order: user agent user interface, user
agent extensions, content keystroke operations administered by the
user agent (e.g., access keys), and executable content (e.g., key
press events in scripts, etc.).
JB: also comment on 4.1.9
<jeanne> Simon's comment:**COMMENT*** It seems we should look at this
and 4.1.2 together - if
<jeanne> we define a precedence why do we then need to make sure the
<jeanne> precedence is documented unless 4.1.2 is A conformance and
4.1.9 is AA?
JA: more granularity
JB: SH comment was look at this and 4.1.2 together
... in next draft, ought to reconstruct priority level and do rough
attempt at reordering them?
... all single A first then double A right
JA: that's how are organized
... wanted to make this a single A with 1.2 - all browsers if
javascript gets first, trickle in through another mechanism
... preference: UA gets first, cascade down and scripts get last
... user agent first then extension (UA knows about and controls) -
that which happens in javascript UA knowns nothing about it, but
author can override keybindings with script; user has no cognizance
just frustration; current practice is scripts get first and then write
to Accessibility API to alert AT
JB: significant problem and not asking for what is needed?
JA: didn't think would ever happen
JB: need to be clear
JA: specific rationale explaining why this is where is appears in doc
flow
JB: priority grouping concern a perception or based on feedback;
putting priorities on level by priority, forces more discussion to
happen on most essential parts of need be addressed; seen example in
another GL group where happened
JR: end-run around issue: make this be a user option - level A that
user can choose to have UA process keystrokes first
GJR: didn't we build that into access module?
JR: UAs don't process this way because user goes to GMail think "i am
using GMail" not browser x
GJR: this is similar to the dropped role in ARIA "application"
JR: can bring to proper priority level by allowing for user control
(greater and less)
proposed ACTION: Jan - start discussion on UA list about scripting
cascade issues, SC and solutions/techniques ??
JA: browser a platform for applications, good point JR
q}
MH: developer's POV: nothing specific to add
<AllanJ> GJR: was covered in ARIA 1.1 'template ID', perhaps take back
to PF
GJR: dropped role is templateid not application
JA: send to list, GJR
GJR: implementor support for "templateid" in ARIA, but dropped
TWO MINUTE WARNING
Wrapping Up
JA: propose we stop here for now and pick up on list -- getting close
to nailing this
JB: one more call could probably make it not only to end of list, but
also talk about reordering; for 10 through 12 will need to track
background
JA: discussion on list is key
... proposal needed for 10; 11 needs grammatical fix; 12 ok
JB: housekeeping: meeting scheduled for 90 minutes; going to give it a
try; anyone else have problem with 90 minutes starting at 2pm Boston?
GJR: no
JB: Jeanne put on agenda scheduling publication of next draft -
important to satisfy heartbeat req; might be good to do after keyboard
part is straightened out
JA: good idea
JB: talk at next week's meeting
JA: will be number 1 on agenda; if get kbd section done, good place to
issue a draft
JB: some members we haven't heard from who have a lot of interest in
keyboard; coherent for feedback check with those who have been out of
touch when have new proposed text
... regrets for next week?
proposed ACTION: Jan - start discussion on UA list about scripting
cascade issues, SC and proposed solutions/techniques
jan, are you still on IRC - i didn't capture your last action
definitively
proposed ACTION: Jan - start discussion on UA list about scripting
cascade issues, SC and proposed solutions/techniques
<scribe> ACTION: Jan - start discussion on UA list about scripting
cascade issues, SC and proposed solutions/techniques [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action09]
Summary of Action Items
[NEW] ACTION: JA, JB, JS to figure a time & place to discuss a bunch
of editorial issues (such as whether to "verbify" the success
criteria) [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action04]
[NEW] ACTION: Jan & Jim - review 4.1.1, 4.1.6, and 4.1.7 for
redundancy [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action05]
[NEW] ACTION: Jan - propose rewrite for 4.1.5 and nex 4.1.x [recorded
in http://www.w3.org/2008/07/10-ua-minutes.html#action07]
[NEW] ACTION: Jan - start discussion on UA list about scripting
cascade issues, SC and proposed solutions/techniques [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action09]
[NEW] ACTION: jb reply to multiple concerns on SH's suggestion about
linking literature references from UAWG 2.0 [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action02]
[NEW] ACTION: Jeanne - build new streamlined framework for 4.1.* (1 or
2 sentences for each SC) [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action08]
[NEW] ACTION: Jeanne - propose rewrite for Section 4.1.8 [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action06]
[NEW] ACTION: Judy and Jeanne - plan time and place to discuss cluster
of editorial issues to get UAAG2 more consistent - address
verbification of keywords for SCs [recorded in
http://www.w3.org/2008/07/10-ua-minutes.html#action03]
[NEW] ACTION: SH draft new rationale text for 4.1 keyboard shortcuts
[recorded in http://www.w3.org/2008/07/10-ua-minutes.html#action01]
[End of minutes]
_________________________________________________________________
Received on Thursday, 10 July 2008 20:02:12 UTC