See also: IRC log
<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
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.
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> 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.
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.
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.
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.
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.
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.
<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
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.
<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.
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.
<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].
<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
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) WARNING: Bad s/// command: s/+1 to not SC 3.2.1 having particularly poor clarity Succeeded: s/overal/overall/ Succeeded: s/unqiue/unique/ Succeeded: s/discusson/discussion/ FAILED: s/rrs agent// Succeeded: s/in formation/information/ Succeeded: s/rrsagnet, make minutes// Succeeded: s/JAn/Jan/ Succeeded: s/Topic: Guideline 2.9 DOM access to CSS style sheets [Techniques] @@6.9 NEEDS WORK@@/Topic: Guideline 2.9 DOM access to CSS/ Succeeded: s/Topic: Guideline 2.10 Timely exchanges through APIs [Techniques] @@6.10 NEEDS WORK@@/Topic: Guideline 2.10 Timely exchanges through APIs/ Succeeded: s/sitution/situation/ WARNING: Bad s/// command: s/ http://www.w3.org/2002/09/wbs/36791/UAWG20080822/results /http://www.w3.org/2002/09/wbs/36791/UAWG20080822/ Succeeded: s/ ... freeze changes for heartbeat publication (perhaps) by Nov 24/ ... freeze changes on Nov 6 for heartbeat publication (tentative) by Nov 24/ Succeeded: s/... Nov 13 Guideline 1 and 4. /... Nov 13 Principle 1 and 4./ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** WARNING: Bad s/// command: s/+1 to not SC 3.2.1 having particularly poor clarity FAILED: s/rrs agent// WARNING: Bad s/// command: s/ http://www.w3.org/2002/09/wbs/36791/UAWG20080822/results /http://www.w3.org/2002/09/wbs/36791/UAWG20080822/ Found Scribe: kford Inferring ScribeNick: KFord WARNING: No scribe lines found matching previous ScribeNick pattern: <jeanne2> ... Found Scribe: Jan Inferring ScribeNick: Jan Found Scribe: jeanne Inferring ScribeNick: jeanne Found ScribeNick: jeanne2 Found Scribe: Kford Inferring ScribeNick: KFord Scribes: kford, Jan, jeanne ScribeNicks: jeanne2, KFord, Jan, jeanne WARNING: Replacing list of attendees. Old list: kford Jan jeanne jallan MarkH judy New list: kford markH jeanne jallan az Default Present: kford, markH, jeanne, jallan, az Present: Jim_Allan Jan_Richards Jeanne_Spellman Kelly_Ford Mark_Hakkinen Anna_Zhueng(observer) Judy_Brewer Agenda: http://www.w3.org/WAI/UA/2008/10f2f Found Date: 21 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/21-ua-minutes.html People with action items: ja jeanne jr js kf kford WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]