See also: IRC log
<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
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?
... 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
... move forward from that point - if need to backtrack for wordsmithing, can check at end of meeting
<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
... 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...
<Jan> ...mouse input or other input methods in addition to keyboard operation.
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
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
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
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
... 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
... 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
<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
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
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
... good to raise if makes more understandable
... important to have outsider review
JB: ATAG SC 126.96.36.199 - 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
... 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
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'
... 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
... 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
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
... 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..."
JR: user can traverse all controls sequentially
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
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
<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
... 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]
<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
... preference: UA gets first, cascade down and scripts get last
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
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
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
... 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?
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
s/TOPIC: 4.1.7/TOPIC: 4.1.9
<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]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/follow up on/reply to multiple concerns on/ FAILED: i/4.1.7. User/TOPIC: 4.1.7 Succeeded: s/1.1/4.1.1/ Succeeded: s/TOPIC: 4.1.7/TOPIC: 4.1.9/ Succeeded: s/UI gets first/UA gets first/ Succeeded: s/-- aggregation of content// Succeeded: s/MINUTES/MINUTE/ Succeeded: s/for next week/for next week?/ Succeeded: s/TOPIC: 4.1.7/TOPIC: 4.1.9/ FAILED: s/TOPIC: 4.1.7/TOPIC: 4.1.9/ Succeeded: i/JS: chrome/TOPIC: 4.1.7 Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus Default Present: Gregory_Rosmaita, Jeanne, +1.512.206.aaaa, Jim_Allan, Jan_Richards, Judy, Mark_Hakkinen Present: +1.512.206.aaaa Gregory_Rosmaita Jan_Richards Jeanne Jim_Allan Judy Mark_Hakkinen Regrets: Kelly_Ford Alan_Cantor Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0012.html Got date from IRC log name: 10 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/10-ua-minutes.html People with action items: - ja jan jb jeanne js judy place plan reply sh time WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]