Minutes

IRC Log

Action Items
ACTION: JA to contact PF for assistance with Issue-23
ACTION: JA to contact the i18n (Keiko) and PF to see if there are specific needs we to specify for Issue-22
ACTION: JA: To write status section for Introduction due 30/10/2008
ACTION: JR to clean up Principle 2, putting it in the proper format so it can be shared with other groups for comment.
ACTION: JR to review glossary
ACTION: JS to draft a guideline for Principle 5 understanding that covers the points in Issue-19
ACTION: JS to draft a new guideline on the ease of options and configuration of options
ACTION: JS to write a addition to the conceptual overview to state that UAAG addresses the needs of the ageing population in addition to the disability population.
ACTION: JS to write a proposal for 3.2.2 breaking it down into more granular
ACTION: KF to KF and JS to write proposal for Guideline 3.1 improving perceivability of user interface and passive status.
ACTION: kford jeanne to add guideline in 3.1 around improving perceivability

Text of Minutes

W3C
User Agent Accessibility Guidelines Working Group Teleconference
21 Oct 2008

Agenda

See also: IRC log
Attendees

Present
    Jim_Allan, Jan_Richards, Jeanne_Spellman, Kelly_Ford, Mark_Hakkinen, Anna_Zhueng(observer), Judy_Brewer
Regrets
Chair
    Jim, Judy
Scribe
    kford, Jan, jeanne

Contents

    * Topics
         1. PRINCIPLE 3: Ensure that the user interface is perceivable
         2. Guideline 3.2 Provide access to alternative content
         3. Andrew Arch - WAI-AGE Project
         4. Guideline 2
         5. Principle 2
         6. Guideline 2.1
         7. Guideline 2.2: DOM access to HTML/XML content
         8. Guideline 2.3
         9. 2.4 Programmatic Access to non-HTML/XML content
        10. Guideline 2.5 Programatic operation of user interface
        11. Guideline 2.6
        12. Guideline 2.8 API character encodings [Techniques]@@6.8 NEEDS WORK@@
        13. <scribe> Topic: Guideline 2.9 DOM access to CSS
        14. Guideline 2.10 Timely exchanges through APIs
        15. Scheduling of future issues and action items
    * Summary of Action Items

 

 

<trackbot> Date: 21 October 2008

<KFord> scribe: kford

<Jan> New Draft: http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081021/WD-UAAG20-20081021.html

JAllan: Goes over plan for the day.
... Hard stop at 5:30P. One hour before stop and priortize action items with timelines and such.

group continues to look at newest draft at http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081021/WD-UAAG20-20081021.html
PRINCIPLE 3: Ensure that the user interface is perceivable

JAllan: Anyone have any general problems with the wording?

none heard.

Now looking at Guideline 3.1 Provide text alternatives for non-text components

group is ok with general wording.

JR: I wanted to comment on something we found in ATAG. The item one that says you need to cover the accessibility of your platform is likely to cover this.

Jeanne: I wanted to ensure we covered the accessibility of documentation.

>From my mail 10. Principle 3, in particular 3.1 needs to be more clear. I�ve mentioned on a few calls how the user interface does a lot visually to convey meaning. I don�t think these guidelines give enough detail on what needs to happen or the expectation around accessibility. User agents today do a lot to convey state from security to page functionality with unique UI elements. AT jumps around loads of hoops today to convey this info.

<jallan> KF: should keep, need to be a bit explicit, to make sure the point gets across

More discussion about whether 3.1 is covered in guideline 1.

<jallan> KF: user interface everything is labeled and available programatically

<jallan> ... the UA could do more to make the information available.

<jallan> JA: 3.1.1 does not say make information available programatically

<jallan> JR: should be in Principal 2

<jallan> JA: information is available passively, the user must request the security state, rss feed, etc.

kford more discussion about this.

<jallan> ... do we need some SC to allow option to provide overview of current states in the UA

JR: I think principle two would cover most of this.

<jallan> JS: this is needed for low vision people.

kford: kford and Jeanne think principle three needs to be strengthened.

<jallan> ... ARIA has section on passive alerts, perhaps we need something like that

JAllan: we've talked a lot about screen readers. Visually you glance around.
... if this is all available programatically, isn't it then the AT's job to grab this info.

<jallan> KF: what is the state, what is important, the UA has gone through the effort to provide an icon. How is the user to decide what is important

<jallan> ... I am missing the gestalt of the information

<scribe> ACTION: kford jeanne to add guideline in 3.1 around improving perceivability [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action01]

<trackbot> Sorry, couldn't find user - kford

<jeanne> ACTION: KF to KF and JS to write proposal for Guideline 3.1 improving perceivability of user interface and passive status. [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action02]

<trackbot> Created ACTION-48 - KF and JS to write proposal for Guideline 3.1 improving perceivability of user interface and passive status. [on Kelly Ford - due 2008-10-28].

<jallan> JR: add to examples, kinds of important state information

JR: I think we need to add to examples, some of what kford was saying about important state in modern browsers.

JAllan: 3.1.1 needs to reveal info programatically and there needs to be some mechanism to provide a overview of important state items.
Guideline 3.2 Provide access to alternative content

JR: I have a long standing general concern about mixing content and user interface.

JAllan restates JR's concern.

JS: This goes back to what I was saying in the beginning about the overall principle. This talks about content and user interface.

JR: You either split into two principles or expand scope of the current principle.

JAllan: I prefer to keep one principle if possible.

Jeanne: We need to ensure any author controls like ARIA are perceivable.

<jallan> JA: the user agent provides a user interface to allow access to the author provided alternative content

kford: I think we need to expand the scope of principle 3.
... Today the web author can easily extend what's traditionally thought of of the user agent

<jeanne> http://www.w3.org/TR/2008/CR-WCAG20-20080430/#perceivable

<jeanne> I think we should use the WCAG wording:

<Jan> PRINCIPLE 3: Perceivable - The user agent's user interface and rendered content must be presented to users in ways they can perceive

<jeanne> issue: relook at the phrasing of Principle 3 to ensure clarity.

<trackbot> Created ISSUE-16 - Relook at the phrasing of Principle 3 to ensure clarity. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/16/edit .

<jeanne> +1 to not clear

<jeanne> s/+1 to not SC 3.2.1 having particularly poor clarity

<jeanne> Presence of Alternative Content: The user has a global option to be notified of alternatives to rendered content.

group talks about definition presented by Jeanne.

kford: We need to include ability to view alternatives. Just telling me they are there.

group agrees next checkpoint covers this.

group discussing wording of each guideline, i.e. do we want noun verb or what?

<jeanne> issue: Editors need to set standards for SC handles, and review document for consistency of handles.

<trackbot> Created ISSUE-17 - Editors need to set standards for SC handles, and review document for consistency of handles. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/17/edit .

group agrees on wording for 3.2.1.

group now discussing 3.2.2 browse and render

<Jan> The user can browse the alternatives and render them according to the following

group continues to talk about alternative content viewing, order and such.

working on eliminating terms like alternative content stack.

<jallan> JR: separate a) and b)

group agrees to separate out various media types to better represent each and unique issues. All agreed this was good.

<jeanne> ACTION: JS to write a proposal for 3.2.2 breaking it down into more granular [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action03]

<trackbot> Created ACTION-49 - Write a proposal for 3.2.2 breaking it down into more granular [on Jeanne Spellman - due 2008-10-28].

group moves on to 3.2.3 available programatically.

group thinks this is clear.

group talking about 3.2.4

�3.2.4 Simultaneous Rendering: The user has the option to simultaneously render any and all items from the alternative content stack (which will cause the document to reflow accordingly) unless the user agent can recognize a mutual exclusion (e.g., conflicting soundtracks). (Level AA)@@NEW@@

<jallan> JR: perhaps this is overkill, may be redundant to rewrite of 3.2.2.

Jeanne: I'll take this one under consideration in rewrite of 3.2.2.

JAllan: further explains how we think this would then be duplicative.

group talking about 3.2.5 �3.2.5 Configurable Default Rendering: The user has the option to set preferences for which items in an alternative content stack will be rendered by default. (Level AA) @@2.9 in UAAG10@@

Discussion about if this is covered in 3.1.

MH: Why shouldn't this be level a?

<jeanne> +1 for level A for 3.2.5

all agree this should be level a.

more discussion about whether the two items around alternatives should be combined into 1 or not.

kford: Not too concerned about if they are one checkpoint or not but that they appear in the document in order.

<jeanne> resolved: 3.2.5 moved to 3.2.2

<jallan> http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081021/WD-UAAG20-20081021.html#principle-perceivable

JAllan: brought up note about exposing ability to make choices for alternative content. @@New Technique 3.2.5=User agents should expose configuration choices in as highly visible a fashion as is practical such as on a menu entry or dialog settings devoted to accessibility@@.

<jeanne> ACTION: JS to draft a new guideline on the ease of options and configuration of options [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action04]

<trackbot> Created ACTION-50 - Draft a new guideline on the ease of options and configuration of options [on Jeanne Spellman - due 2008-10-28].

<jallan> KF: don't disagree, UA developers should have some flexibility in how they implement the SC

group moving to guideline 3.3.

Guideline 3.3 Provide control of content that may reduce accessibility

rrsagent make minutes

s/rrs agent/

Jeanne: This should not be under perceivable but under operable.

JAllan: I agree.

Group agrees to move to principle four.

talking about background images 3.3.1.

Discussion about what background images we are talking about.

<jeanne> 3.3.1 any time text overlays an image that the user agent can recognize, the user has the option to turn off the background image.

JR: If this is really trying to improve text readability, do we go from a different approach?

Discussion of Jeanne's proposal.

<jeanne> 3.3.1 the user has a global option to turn off background images

Not agreement that this should only be when text is present.

Various gave examples of image complexity.

<Jan> 3.3.1 Background Image Toggle: The user has the global option to hide/show background images@@DEFINE@@ (i.e., images that are rendered on the base background). (Level A)

MH: the thing that nags me a bit is that these need to be non-informational images.

<jeanne> issue: Background Image toggle (4.9) has concerns about identifying decorative vs. no -decorative images.

<trackbot> Created ISSUE-18 - Background Image toggle (4.9) has concerns about identifying decorative vs. no -decorative images. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/18/edit .

<jeanne> break

<jallan> back at top of hour

<Jan> scribe:Jan
Andrew Arch - WAI-AGE Project

<andrew> http://www.w3.org/TR/wai-age-literature/#training

AA: Bit of background...
... EC funded project...age related issues overlap with issues for people with disabilities
... Few things...comprehension of UI is an important issue
... Several people have said can we simplify
... Univ Dundee tried to simplify IE interface...
... Found training flowed better (training older people who have not used computers)
... Particularly over 70 age group
... Figs 5 and 6 other people simplifying user interface...."non-browser"....
... 5 buttons...back to start...back a page...look up, down, black and white, magnify
... At CSUN...IBM Easy Web browser interface...
... took quite a bit of functionality away...have magnify on front, spanner tool to change colours etc
... so lots of people typing search terms into address bar
... Some other discussion about what UAs should do...
... simplified magnification...maybe up front on some UIs
... Maybe a young and old users interface
... Cognitive users who benefit in same way

JB: UA currently deals with configurable...but not a prepackaged simplified interface...
... Maybe we need to have a new requirwmnt...simplified UI.

JA: Maybe under Understandable

JB: Maybe

JR: Google Chrome already doing many of these things

MH: Good idea

AA: When we looked at these simplified browsers many groups came up with same things independently

JS: I wonder about size of clickable items...
... In the non-browser the + and - buttons look too small
... Think we should have min. button sizes in chrome
... Another conclusion of studies I have seen is aging users ...consistentlyu slower to select link...more cautious about what clicked on
... Anything about how to make more clear

AA: Studies doid show they were much slower to select...found older users read whole screen...younger users skimming then clicking quickly...

<jallan> Simple browser interface example: Zac Browser http://www.zacbrowser.com/

AA: In the end though some tasks took same time....since Seniors make more considered choices

JS: When verb in link text...higher success in studies I saw

AA: Many studies discuss clarity of links
... Many said consistent fashion...blue underlining

JA: SImplified UI....we discussed making UI components bigger...fatter scroll bars etc.

AA: SOme studeies found scroll bar difficult for manuy older users...
... But these studies did not talk about keyboarding...
... Also did not see much on ATs or assistive strategies

<jeanne> issue: including ageing issues in UAAG

<trackbot> Created ISSUE-19 - Including ageing issues in UAAG ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/19/edit .

JA: Any other specific UA items?

<andrew> http://www.w3.org/WAI/WAI-AGE/comparative.html

AA: This URI .... includes mapping to WAI guidelines...particularly WCAG
... Atudies recommend 12-14 font...but we require scaling
... Still in draft

JA: I would be thrilled to work with you to add User Agent column
... I can see lots of places for user agent to make repairs on these items

<andrew> http://www.w3.org/WAI/WAI-AGE/comparative-WAI.html - more detail

AA: I would appreciate that

Shadi: Yes we did want to get UA input on that
... Older users/avg users can't find the settings to override display settings
... So those functionalities need to be made easy to find

JA: Right...we were talking earlier about the fact we say confirurable but need more guidance on which should be easier etc

AA: Also with simple UIs they found users liked simple UI for start of training but wanted to add more later on

KF: Comment...not saying we shouldn't...but in Office....reason to change to ribbon was to try to get people to most frequent commands
... Want to make sure we are careful not to mandate too explicitly how to address these things

JS: We can say some core things

KF: OK

JA: Is complex UI issue time sensitive?
... Is it going to go away? But then thought 2 billion people who have never seen computer...

JS: Also cognitive users

AA: Also issue of updates...many older people have trouble adjusting to updated techniques

KF: Did any of the litt. show correlation between older first-time users and users with cognitive issues?

JB: Not good reliable source of info on requirements of people with cognitive issues...huge area
... People often think first of people with intellectual disabilities...and people are starting to look into this.

<Zakim> jeanne, you wanted to discuss web site revisions and access to older versions of the web site.

JS: One key complaint...website revised and aging users could no longer find things they could use before
... And AT users upset that scripts no longer worked etc
... Maybe that's something we can look at

JB: relevant to WCAG too

JR: Tricky to say don't change

JS: Not necessarily

JB: Coul;d leave an old version...but content often changes at same time so then it is harder

JS: Maybe something we could put in as triple A

JR: So guidance to browser would be "Give old UA interface" (not advocating this)

JA: Is that possible?

KF: It's just typing....anything is possible...
... Not technically impossible

MH: Like having different skin....
... Tried this with various skins for DAISY

KF: Right so depends on ability to separate UI from functionality

JA: Foundational accessibility concept
... I could see a lot of this being done by an extension...don't want to go down this road
... Want to reach a balance on what goes in base UA and what can go in extension

MH: It's subsetting full UI into subsets....default subset...etc

JA: Riht...we could add skins

MH: Not just appearance...actual functions available

JA: Any other thoughts?

AA: Good discussion

JS: Tentatively in Sec 5 new guideline for Option of Simpler UI....2nd is scalable font sizes....clarity of links....customization of appearance of links....size of scrollbars and other controls....ease of configuration...
... THen when UI is upgraded-option to use old....simplified skins...specify default setup

<jeanne> ACTION: JS to draft a guideline for Principle 5 understanding that covers the points in Issue-19 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action05]

<trackbot> Created ACTION-51 - Draft a guideline for Principle 5 understanding that covers the points in Issue-19 [on Jeanne Spellman - due 2008-10-28].

JB: Noticed not many studies on older users of mobiles
... UAWG should prob give some dedicatred time to mobile devices...should look at mobile best practices
... And consider older users
... Maybe need to be highlighting some things from Mobile best practices

<jeanne> issue: Take a look at user requirements for mobile users with disabilities and see if there are additional requirements needed in UAAG.

<trackbot> Created ISSUE-20 - Take a look at user requirements for mobile users with disabilities and see if there are additional requirements needed in UAAG. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/20/edit .

JB: Only was able to get out the door on UAAG1 by limiting to desktop browser
... We ought to talk about this at a followup meeting

AA: Did find a few studies on older users of mobile phones...but not mobile browsers

JA: Any industry group looking at older users of mobile browsers

Anna: Haven't heard of any specific studies

JA: Many older people don't see selves as having disabilities...
... "Ease of use" much better term

JS: Interesting point to put in conceptual overview

<jeanne> ACTION: JS to write a addition to the conceptual overview to state that UAAG addresses the needs of the ageing population in addition to the disability population. [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action06]

<trackbot> Created ACTION-52 - Write a addition to the conceptual overview to state that UAAG addresses the needs of the ageing population in addition to the disability population. [on Jeanne Spellman - due 2008-10-28].

<jeanne> break for lunch

<andrew> browser wizard - http://www.cs.washington.edu/ai/supple/ & http://www.youtube.com/watch?v=B63whNtp4qc

<KFord> minutes are at:

<KFord> http://www.w3.org/2008/10/21-ua-minutes.html

<jeanne> scribe:jeanne

recap of lunch conversations on the importance of coordinating with PF on ARIA and mobile working groups on incorporating accessibility into mobile.
Guideline 2
Principle 2

KF: Would like to see "programatic" in the Principle.

<jallan> kelly's comments http://lists.w3.org/Archives/Public/w3c-wai-ua/2008OctDec/0020.html

<jallan> jan comments 1 http://lists.w3.org/Archives/Public/w3c-wai-ua/2008OctDec/0013.html

<jallan> jan comments 2 http://lists.w3.org/Archives/Public/w3c-wai-ua/2008OctDec/0014.html

<jallan> simon comments http://lists.w3.org/Archives/Public/w3c-wai-ua/2008OctDec/0019.html

<jallan> JR: discusses how ATAG tackles this http://www.w3.org/TR/ATAG20/#principle-facilitate-at

JR: The "accessibility platform architecture" used in ATAG is useful to UAAG.
... this would replace much of Principle 2 success criteria and guidelines

<Jan> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080310/#principle-facilitate-at

<Jan> A.1.2.1 Accessibility Platform Architecture (user interface "chrome", content display): Non-Web-based authoring user interfaces implement an accessibility platform architecture relevant to the platform.

<Jan> accessibility platform architecture

<Jan> A programmatic interface that is specifically engineered to enhance communication between mainstream software applications and assistive technologies (e.g., MSAA and IAccessible2 for Windows applications, Gnome Accessibility Toolkit API for Gnome applications, Java Access for Java applications). On some platforms it may be conventional to enhance communication further via implementing a DOM.

<Zakim> jeanne, you wanted to say this is more technology independent

<Jan> JA: Reading guideline 2.2.1....WCAG says provide "Name, Role, Value"....ARIA says same...what do we need to support

<Jan> JR: I think so

<Jan> MH: THese are just attributes.

<Jan> JA: Let me backup...we started with changing words for principle 2....

<Jan> JA: We all agreed "Facilitate programmatic access by assistive technologies"...

<Jan> JS: Principle should stay the same

<Jan> JS: Would like to bring ATAG wording over....then look at gaps and use existing UAAG text to fill gaps

<Jan> JA: OK

MH: Concern that ATAG says "must" and UAAG does not.

JR: Perhaps ATAG should move to harmonize with UAAG.

<Jan> 1.2.1 Accessibility Platform Architecture: Non-Web-based user agen tinterfaces implement an accessibility platform architecture relevant to the platform.

<Jan> A.1.2.2 Accessible Alternative: If any non-Web-based user agent interface functionality is not supported by the implemented accessibility platform architecture(s), then a separate accessible alternative for that functionality that is supported by the implemented accessibility platform architecture(s) is provided and a description of the inaccessible functionality appears in the conformance claim.

The above quotes from ATAG are under consideration, to see if they include all the 2 Guidelines and SC.
Guideline 2.1

JR: we haven't addressed XML. We could wordsmith 2.1 to mean programmatic access to both the content being rendered and the user interface.
... 2.1.1 and 2.1.2 then become Techniques

KF: We need access to the content being rendered, the user interface and the Document Object Model.

JR: We said Accessibility Architecture Platform to include the DOM

<Jan> accessibility platform architecture

<Jan> A programmatic interface that is specifically engineered to enhance communication between mainstream software applications and assistive technologies (e.g., MSAA and IAccessible2 for Windows applications, Gnome Accessibility Toolkit API for Gnome applications, Java Access for Java applications). On some platforms it may be conventional to enhance communication further via implementing a DOM.

KF: If your application uses the DOM, give access to AT.

JA: The user agent creates its DOM and it allows its accessibility API and DOM to have access to it.

KF: But you don't have to do it that way. The accessibility API could just be considered another AT.
... In order to consider your application complete, you don't have to implement the DOM. If you use DOM, allow programatic access to it, and support platform accessibility architecture.

<Jan> 2.X.C If the user agent implements a DOM, this should be made accessible to assistive technologies.

<Jan> 2.X.C If the user agent implements a DOM, this should be made programmatically available to assistive technologies.

<Jan> 2.X.A Accessibility Platform Architecture: Non-Web-based user agent interfaces implement an accessibility platform architecture relevant to the platform.

<Jan> 2.X.A Accessibility Platform Architecture: Non-Web-based user agent interfaces support an accessibility platform architecture relevant to the platform.

<jallan> JR: do we need to include this from WCAG 4.1.2 Name, Role, Value: For all user user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available...

<jallan> ...to user agents, including assistive technologies.

<mth> mark stepping away for a moment

KF: This is the bare minimum you need to expose for all UI elements is name, role and value.

JS: +1

<mth> back

<Jan> Name, Role, Value: For all user user interface components (including the user interface and rendered content), the name, role and value are made available via an accessibility platform architecture.

JR: We also need to make a version that is the "write" version.

<Jan> 2.X.A Name, Role, State, Value, Description: For all user user interface components (including the user interface and rendered content), the name, role, state, value, description are made available via an accessibility platform architecture.

discussion on including Name, role, state, value, description.

issue: re-evaluate Principle 2 to see if name, role,state, value, and description are complete and sufficient for minimum accessibility

<trackbot> Created ISSUE-21 - Re-evaluate Principle 2 to see if name, role,state, value, and description are complete and sufficient for minimum accessibility ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/21/edit .

JA: this section now moves to Techniques.

KF: If you can click a menu it is availabe with the same degree as read access.

<Jan> 2.X.D If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), programmatic write access to the current state or value is available with the same degree of write access programmatically as is available through the user interface.

<Jan> 2.X.D If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is availble programmatically.
Guideline 2.2: DOM access to HTML/XML content

JS: 2.2.1 sounds like a Technique, not a SC

JA: 2.2.2 is a real issue for Javascript and AJAX where the script is trapping the keybinding

MH: That is not covered by this SC.

KF: We are trying to separate out techniques from requirements. This rewrite reflects that.

JA: it is getting cleaner and the language makes more sense.

MH: The is simple and better.
Guideline 2.3

2.3.1 is covered with 2.X.D

2.3.2 is covered by 2.X.D and becomes a Technique

2.3.3 is also a Technique

JA: Where at least 1 API is implemented, does that mean that it is being passed to the Accessibility Architecture.

JR: If the API isn't implemented by commercial screen readers, it is useless. That's why it is better to use the platform APIs.

JA: This cascade was written to not allow any deviation with AT.
... but I think this should be a technique

KF: If you are a user agent, the technique is to figure out what to do. The cascade is useful for that.

JR: We are not interested in low level APIs, we are already requiring platform architecture. The note should be deleted.

KF: At some point we have to define what a platform accessibility API is.

JR: We have primarily going to define it by example.
2.4 Programmatic Access to non-HTML/XML content

KF: The list of name, role, state, etc. This is saying what level of detail do you need?

<jallan> KF: the bounding information should be provided to the accessibility API

<jallan> ... one limitation. if access api does not support a piece of information ... then what

<jallan> ... user agent changes color of address bar. msaa does not have a concept of color or text attributes and cannot provide that information.

<jallan> .... screen readers get that information from their off screen model

<jeanne2> JR: If the API can handle it, then the information about color is important.

<jeanne2> JA: If the API can use it, ship it everything you got. If the API can't use it, throw it away.

<jeanne2> KF: Once we get the draft out there, we need to get as much feedback as possible.

<Jan> 2.X.E If any the following properties are supported by the accessibility platform architecture, they must be made available via the architecture:

<Jan> (a) the bounding dimensions and coordinates of rendered graphical objects

<Jan> (b) font family of text

<Jan> (c) font size of text

<Jan> (d) foreground color of text

<Jan> (e) background color of text.

<jeanne2> agreement that "graphical" should be removed. All types of browsers need access to all the property information

<jeanne2> JR: IF you are using another DOM (like CSS DOM) then you need to make them available programmatically.

<jeanne2> resolved: edits to 2.X.C to say:

<Jan> 2.X.C If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies.

<jeanne2> KF: Another wrinkle: In web browsers, when you click on links they change colors becvause they have a new state, "visited".

<jeanne2> ...Freedom Scientific changed the way they report "visited". MSAA added a state "traverse

<jeanne2> KF: Add a technique for "visited link" state.

<jeanne2> JA: CSS Dom has that information. There is a tremendous amount of information in the CSS DOM that never make it into the off-screen model because it didn't exist then.

<jeanne2> KF: The CSS spec specifically excludes putting information in the DOM.

<jeanne2> JA: That's why we need to include the CSS DOM>

<Jan> http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081021/WD-UAAG20-20081021.html

<jeanne2> The Note following 2.4.1 should go to Techniques.
Guideline 2.5 Programatic operation of user interface

<jeanne2> JR: Controls have been handled.

<jeanne2> JA: 2.5.1 & 2.5.2 go to Techniques. 2.5.3 is deleted because we got rid of the API cascade.

<jeanne2> consensus

<jeanne2> scribenick:jeanne2

The note on inclusions and exclusions will be deleted as no longer relevant. COnsensus.

The Note on API will go to Techniques. Consensus
Guideline 2.6

2.6.1 belongs in the list of what goes in 2.X.E

resolved: 2.6.1 is deleted.

resolved: 2.6.2 is deleted.

Normative inclusions and exclusions note:

KF: #1 is an example of when making things clean, sometimes detail issues have to be included.

<Jan> 2.X.E If any the following properties are supported by the accessibility platform architecture, they must be made available via the architecture:

<Jan> (a) the bounding dimensions and coordinates of rendered graphical objects

<Jan> (b) font family of text

<Jan> (c) font size of text

<Jan> (d) foreground color of text

<Jan> (e) background color of text.

<Jan> (f) change value notifications

Normative inclusions and exclusions note: continued discussion

<scribe> scribe:Kford

JAllan: Concerns that today AT are not getting updates about DOM changes.

JR: The DOM does get notified.

MH: Typically JAWS has to reread the full DOM>

<jeanne2> meeting: Meeting: UAWG F2F Day 2

<jallan> KF: is this technique level discussion, or success criteria.

<Jan> 2.X.E If any the following properties are supported by the accessibility platform architecture, they must be made available via the architecture:

<Jan> (a) the bounding dimensions and coordinates of rendered graphical objects

<Jan> (b) font family of text

<Jan> (c) font size of text

JAllan: Jan has convinced me that this is covered with our DOM guideline.

<Jan> (d) foreground color of text

<Jan> (e) background color of text.

<Jan> (f) change state/value notifications @@(e.g. of DOMs)

group agrees that this is now covered.

<jeanne2> Topic 2.7 Keyboard APIs

JR: Do we already cover this in other areas?

JAllan: do we need this?

JR: No, let it go.

MH: Thinkiing of browsers that are done in languages where they did their own keyboard handling.

<jeanne2> issue: In Guideline 2.7 the closing Note discusses Japanese and Chinese. This may need to be preserved in Techniques.

<trackbot> Created ISSUE-22 - In Guideline 2.7 the closing Note discusses Japanese and Chinese. This may need to be preserved in Techniques. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/22/edit .

Group going to get more info from subject matter experts on 2.7.
Guideline 2.8 API character encodings [Techniques]@@6.8 NEEDS WORK@@

<jeanne2> ACTION: JA to contact the i18n (Keiko) and PF to see if there are specific needs we to specify for Issue-22 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action07]

<trackbot> Created ACTION-53 - Contact the i18n (Keiko) and PF to see if there are specific needs we to specify for Issue-22 [on Jim Allan - due 2008-10-28].

<jeanne2> Topic 2.8 API character encoding

JAllan: Do we need this?

<jallan> JR: no

JR: No, we need oxygen in the air too but this is obvious.

MH: This should be covered by other areas already.

Group marking 2.8 as technique.
<scribe> Topic: Guideline 2.9 DOM access to CSS

JAllan: Have we covered this with our multiple dom item.

Group agrees we have. 2.9 getting marked as technique.

2.9.2 getting marked as techniques.
Guideline 2.10 Timely exchanges through APIs

<jallan> KF: perhaps keep it at level 2. A danger, if people don't pay attention, then performance of the UA gets slow, and degrade accessibility

<jeanne2> KF: we may want to make a level AA for this, because unless people pay attention to it, the performance of the browser can get really slow.

MH: I see this kind of related to ARIA politeness.
... This should be level A.

Group looks at techniques and finds none beyond what's in guidelines.

JAllan: gives example of situation where it took five seconds for result of tab being communicated.

JR: Looking in appendix and finds some examples around this.

<jeanne2> issue: draft a proposal for a rewording of 2.10 Timely Exchanges through APIs to make it more clear.

<trackbot> Created ISSUE-23 - Draft a proposal for a rewording of 2.10 Timely Exchanges through APIs to make it more clear. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/23/edit .

<jeanne2> ACTION: JA to contact PF for assistance with Issue-23 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action08]

<trackbot> Created ACTION-54 - Contact PF for assistance with Issue-23 [on Jim Allan - due 2008-10-28].

JAllan: in the last 2.5 hours we've gone from 10 guidelines to 5 success criteria. I think it is clean sharp and good.

<jeanne2> ACTION: JR to clean up Principle 2, putting it in the proper format so it can be shared with other groups for comment. [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action09]

<trackbot> Created ACTION-55 - Clean up Principle 2, putting it in the proper format so it can be shared with other groups for comment. [on Jan Richards - due 2008-10-28].
Scheduling of future issues and action items

<jeanne2> http://www.w3.org/WAI/UA/tracker/

<jeanne2> Open actions link http://www.w3.org/WAI/UA/tracker/actions/open

<Jan> JS: First 6 items done

<Jan> JA: Action 29 is now action 30

<Jan> JA: Action 34..."device independence"

<Jan> JS: SUggests rewrite of Introduction to do first

<Jan> JA: And defintion

<Jan> JA: Due for Oct 30th...#34, #36

<Jan> JA: Intro on Oct 30 and Nov 5

<Jan> JA: Principle 1: Nov 13 - action #37

<Jan> JA: Principle 4: Finish on Nov 13.

<Jan> JR: Regrets for Oct 30th

<Jan> KF: Maybe regrets for Nov 20th

<jeanne2> http://www.w3.org/2002/09/wbs/36791/UAWG20080822/results

<Jan> JA: Dec 4, 11, 18

<jeanne2> s/ http://www.w3.org/2002/09/wbs/36791/UAWG20080822/results /http://www.w3.org/2002/09/wbs/36791/UAWG20080822/

<Jan> JA: Nov 20 - Printing #40,#41

<Jan> JA: Nov 20 - Instyead...Principle 3...issues 42 through 49

<Jan> JA: Dec 4 - printing issues 40 and 41

<Jan> KF: What about charter publication schedule?

<jallan> ACTION: JR to review glossary [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action10]

<trackbot> Created ACTION-56 - Review glossary [on Jan Richards - due 2008-10-28].

<jeanne2> ACTION: JA: To write status section for Introduction due 30/10/2008 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action11]

<trackbot> Created ACTION-57 - Write status section for Introduction due 30/10/2008 [on Jim Allan - due 2008-10-28].

<jallan> http://www.w3.org/WAI/UA/tracker/issues/open

<jeanne2> Heartbeat publication right after we finalize the Introduction. It takes 2 weeks to publish after we finalize. Tentative schedule for Heartbeat publication on November 20.

<Jan> JA: Thanks to all for joining by phone etc.

<jallan> schedule for next 7 meetings

<jallan> ... no meeting Oct 23

<jallan> ... Oct 30 Work on introduction, definition, status - action items 34, 36, 52

<jallan> ... Nov 6 Work on introduction, definition, status - action items 34, 36, 52

<jallan> ... freeze changes on Nov 6 for heartbeat publication (tentative) by Nov 24

<jallan> ... Nov 13 Principle 1 and 4.Issues 1 - 7, Action items 31 - 33

<jallan> ... Nov 20 Guideline 4.9 (old 3.3) time-based media, issues 16 & 18, action items 42 -49

<jallan> ... Nov 27 no meeting

<jallan> ... Dec 4 Guideline 4.9 (old 3.3) time-based media, issues 16 & 18, action items 42 -49

<jallan> ... Dec 11 Printing issue 40 & 41
Summary of Action Items
[NEW] ACTION: JA to contact PF for assistance with Issue-23 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action08]
[NEW] ACTION: JA to contact the i18n (Keiko) and PF to see if there are specific needs we to specify for Issue-22 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action07]
[NEW] ACTION: JA: To write status section for Introduction due 30/10/2008 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action11]
[NEW] ACTION: JR to clean up Principle 2, putting it in the proper format so it can be shared with other groups for comment. [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action09]
[NEW] ACTION: JR to review glossary [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action10]
[NEW] ACTION: JS to draft a guideline for Principle 5 understanding that covers the points in Issue-19 [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action05]
[NEW] ACTION: JS to draft a new guideline on the ease of options and configuration of options [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action04]
[NEW] ACTION: JS to write a addition to the conceptual overview to state that UAAG addresses the needs of the ageing population in addition to the disability population. [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action06]
[NEW] ACTION: JS to write a proposal for 3.2.2 breaking it down into more granular [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action03]
[NEW] ACTION: KF to KF and JS to write proposal for Guideline 3.1 improving perceivability of user interface and passive status. [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action02]
[NEW] ACTION: kford jeanne to add guideline in 3.1 around improving perceivability [recorded in http://www.w3.org/2008/10/21-ua-minutes.html#action01]
 
[End of minutes]