UA Telecon -- 07 Aug 2008

<Jan> Scribe: Jan

<AllanJ> scribe: Jim

<AllanJ> scribe: AllanJ

AU thinking on application guidelines

<Jan> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080801/WD-ATAG20-20080801.html

JR: Above is editors draft from F2F in Redmond
... AU given up on benchmark claim.
... important to UAWG is application accessibility guidelines.
... ATAG felt application accessibilty was over kill
... already saying follow platform conventions which is a bit loose
... want to say the same thing about accessibility of software
... could not put out software accessibilty guidelines that are parallel or equivalent to ISO
... now say - follow accessibility guidelines for your platform

Judy: long history with accessibility of software
... want to check on
... clear requirement to meet ATAG must meet ISO spec
... ATAG has specifics to authoring tool, not covered in ISO

JR: yes, ATAG will have guidelines for specific authoring tool application interface accessibility

Judy: how does this relate to UAAG

JR: need a review of UAAG guidelines to remove 'generic' ATAG items that were added in recent drafts.

Judy: any comments, concerns.

Shaper and Alan: need to review both documents

JR: Part A of ATAG, sccessibilty of authoring tool to the user with disabilities
... reviews structure

<Jan> JA: Only concern is haven't looked at ISO

JR: ATAG simplification, UI vs content issues have lessened
... ATAG kept somethings to do with keyboard

<Jan> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080801/WD-ATAG20-20080801.html#principle-operable

JR: specific keyboard accessibility guidelines will stay in ATAG

Judy: concerns - ATAG changes sounds straight forward, but is complex
... perhaps need an action in UAAG to review items.
... ISO cost concerns

JR: no normative reference to ISO, up to conformant to choose software accessibility guidelines
... explaining rationale

Judy: many standards are in flux. current 508 does not have coverage that UAAG10 has. Users and developers have complained about insufficient coverage of browser-specific UI coverage in the current 508
... 508 Update still 2 years out. not nearly finished.
... ISO much more robust.
... perhaps table for a few weeks. Action to watch what happens with ATAG and ISO.
... Need a specific and relevant and free standard to reference
... No other spec has gotten keyboard right.

JR: agree

Judy: thanks Jan for bringing up

JR: ATAG will point to WCAG for web-based interface, will always need desktop interface and mobile interface

<scribe> ACTION: http://www.iso.org/iso/catalogue_detail?csnumber=30858 [recorded in http://www.w3.org/2008/08/07-ua-minutes.html#action01]

<Jan> http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=39080

ISO/TS 16071:2003

<judy> Judy: (had also said, above) Another major concern is that we apparently do not yet have any guarantee that the ISO spec (ISO 16701 ergonomics of human system interaction: guidance on software accessibility) will indeed become freely available; and until it does, any discussion to consider dropping certain parts of our work here would be premature

<Jan> Ergonomics of human-system interaction -- Part 171: Guidance on software accessibility

<scribe> ACTION: Jan to monitor ATAG development as the relate to software accessibility [recorded in http://www.w3.org/2008/08/07-ua-minutes.html#action02]

<judy> Judy: Also I had raised a concern that pointing for conformance purposes to non-specific guidance elsewhere may be insufficient; it should be specific.

<Jan> ACTION: JR monitor whether ISO9241-171:2008 will be released freely [recorded in http://www.w3.org/2008/08/07-ua-minutes.html#action03]

<Jan> Scribe: Jan

Proposal for placement of keyboard items

JA: My proposal at http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0050.html
... Simon's comments: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JulSep/0059.html
... Proposing new guideline 3.11.7

<AllanJ> JR: There is a problem, difficult concept for people to understand

JB: To begin with I don't think things should be written parenthetically
... Not right - we were talking about mode
... We would not be indicating how to do it

AC: Is this referring to Ctrl+S and S underlined

JA: Yes

<AllanJ> rewrite without parentheticals: Any currently visible UI operable controls that have direct UI keyboard commands have their keyboard commands visually displayed in context

AC: Very different things...first is way to quickly do task without menu and other second provides way for quickly navigating menu

JB: Think a lot of times those overlap
... Also looking at 2...are these so different

AC: See reason for seperating them...especially with accelerator keys
... When two keys have same accelerator, pressing key bounces between them...in dialog only one works
... Two totally different functions

<AllanJ> JR: agree,

<AllanJ> ... the reason is begins with "Any currently visible UI operable controls" is because you can't provide direct UI commands because they are not visible

SH: Is this like 3.6.1?
... Seems like we are trying to highlight

JR: Yes it's highlighting plus letting user know what keystrokes are

<AllanJ> in UAAG20 http://www.w3.org/TR/UAAG20/

3.6.1 Highlighted items: The user has the option to highlight the following classes of information: @@10.2 in UAAG10@@

(a) selection,

(b) content focus,

(d) recently visited links.@@Remove since so common?@@

SH: This highlights your options...

JB: Do we define highlight?

JA: Defined

<AllanJ> In this document, "to highlight" means to emphasize through the user interface. For example, user agents highlight which content is selected or focused. Graphical highlight mechanisms include dotted boxes, underlining, and reverse video. Synthesized speech highlight mechanisms include alterations of voice pitch and volume ("speech prosody").

JR: Warning about 3.6.1 is in content, the req. in question is chrome and uses OS

SH: Think highlighting works...doesn't require it to be visual

AC: Confusion...some people call selection highlighting

JB: Prob we would be getting into confusions

JA: So I'm hearing not 3.11, not 3.6

JB: Have we determined for sure
... Can see what you're saying, but 3.6 feels right

oops that was SH

JA: Originally thought it didn't fit in 4...but maybe it does
... Perceivable vs operable

JB: "Guideline 4.1 Ensure full keyboard access" is obvious

SH: Pref 3.6
... Seems to me that we want to let people know they can make selection

JA: Think back to using the Mac
... Prob wasn't use it was perception

JB: Was a combination of several things...
... Came down to I couldn't use keyboard
... Phrasing of perceivable...

Make sure the user interface perceivable

<AllanJ> Judy: this bridges both perceivable and operable.

<AllanJ> JR: tried to make it thematic - keyboard operation (you must perceive and operate)

JR: Perceivalbe operabl hard to cut apart - Keyboard is thematic

JB: Want things together because how it affects developers getting lost

SH: I'm not UI developer directly but would suggest we need to bring enough stuff to perceivable to have a keyboard section in perceivable

JB: If we look at other things under 3....
... Sorry but this keyboard requirement doesn't seem to fit...better in 4
... Straw poll...

SH: OK either way but pref perceivable

AC: Can easily go into either

JR: Can see SH's point but would pref it stay in 4 for now

JA: Really makes sense for it to be in 4

SH: OK with that if we can get the terminology polished up
... terminology->phraseoology

Resolve: Keep req. on showing shortcuts in 4.1

User configuration has an option to display keyboard shortcuts for all visible controls

JR: How is this diff from the first...is this content and that was chrome?

AC: Sounds like content
... Maybe could apply to both chrome and content
... What's usually missing now iare theshortcuts in web apps
... Would would an option to display mean?

<AllanJ> JR: when I wrote this. It does not describe how things work now. It does not depend on tooltips.

<AllanJ> ... there are no conventions for this at the momement

AC: Important point to get this in
... Would it be ok if tool/balloon tips came up as user tabbed around theui
... Other way is what JR suggests with overlay of controls in a particular mode

JB: THink that would be incredibly distracting
... Sometimes other keystroke to make that go away
... Type of solution for some things...underlined letters in menu...
... Beauty of that is less dynamic etc

AC: So a separate list?

JB: This re: embedded content

AC: Would be very nice eg. on embedded media player

JB: So why can't reuse same mechanism as for chrome UI?

AC: Different mechanism

JB: Does appear as icons etc
... So presents problem..

AC: This is adding something brand new

JR: Excatly

JB: But we shouldn't ask something special of embedded apps
... So requirement should only be easily discover...

JA: I've been looking at this...
... In first one...UI controls need shortcuts and underlines
... 4. is for the content
... 2 is just ability to turn them off

JR: We should remove the one that is just an option

<AllanJ> Judy: combine UI and content and configuration

<AllanJ> JR: Everybody does UI, but content visibilty is new. should be separate

<AllanJ> Judy: can live with it.

AC: Brings up example of Web app that takes ctrl commands

JA: That sounds like AJAX

JB: Hope we made progress today...let's pick up again next week
... THanks all

<AllanJ> ACTION: Jallan to combine 1&2 and 2&4 [recorded in http://www.w3.org/2008/08/07-ua-minutes.html#action04]

- DRAFT -

UA Telecon

07 Aug 2008

Attendees

Contents

AU thinking on application guidelines

Proposal for placement of keyboard items

User configuration has an option to display keyboard shortcuts for all visible controls

Summary of Action Items

Scribe.perl diagnostic output