User Agent Weekly Teleconference -- 10 Jul 2008

<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

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

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]

- DRAFT -

User Agent Weekly Teleconference

10 Jul 2008

Attendees

Contents