<David> test

<scribe> scribe: Ben

mc: agenda for today:
... re: test files - need to follow up with people on assignments and make new assignments

Impact of externalized baseline on Techniques

message summarizing topic: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0010.html

mc: three generic baselines proposed, a modern-day mainstream baseline and a future/perfect world baseline
... then looked at how each technique applies to these baselines - conclusion was that things don't really break across baselines (it is possible to follow techniques to meet needs of both basic and mainstream)
... big hole is that techniques for scripting currently assume need for alternatives

tb: what's relationship between 3 hypothetical baselines?

mc: one assumes you support HTML with caveats for things like accesskey (support HTML, but provide fallbacks for everythine else)
... mainstream was that you support HTML, CSS, Javascript and accessibility features of plugins
... didn't break it down into particular versions of the technologies
... future was that whatever tech you're using, features are supported by user agents world-wide.
... in general, a lot of techniques become optional the further forward we go, but the further backward we go, the more techniques are in the category of "repair"

tb: in terms of testing, is there widespread coverage of techniques that are sufficient?

mc: didn't analyze that out fullly - think that if we accept baseline, we'll need to look for holes in techniques

bc: sense is that we don't have real good coverage of sufficient techniques

tb: so should those guidelines/sc be included if we dont' have sufficient techniques?

bc: think it's more that we still need to write sufficient techniques

mc: graceful degredation (last paragraph of summary) - there are some examples where if technology is not supported (ex. CSS is off) do we then make up for that in the baseline supported technology (fallbacks that recommend table layouts or font tags)??
... if we recommend using CSS to expose semantic structure or make things more understandable, some of the understandability goes away if CSS if not enabled.

dm: slippery slope to make old technology that has been deprecated make up for this.

mc: also breaks the idea that we could have a union set of techniques that addresses multiple baselines

bc: in CSS, design principle is that this can be turned off, so recc. that we not create HTML-only techniques around table-layout or font elements.

mc: what about scripts? would we care about scripts failing gracefully in a graphical browser baseline?

bg: to me that's why you have that baseline, assume your audience supports it and go from there

dm: degrade gracefully came up with 4.2 discussions, but it started to fall apart in some ways.

bg: in today's world, if you know your audience, you should be able to use javascript without creating an alternative (given that you're targeting a US audience...)

mc: are we willing to make a recomendation that the concept of degrading gracefully disappears?

bg: in certain baselines, yes

dm: instead of saying degrade gracefully, we talked about technologies above your baseline and that content would still be accessible without the tech above the baseline

mc: do we need to define "degrade gracefully"?

bc: what was it in WCAG 1.0?

mc: was "transform gracefully" in WCAG 1.0

dm: need to define it in a testable way
... if you use something beyond your baseline, you'll be able to access content even if you don't have access to that tech. beyond baseline

mc: most general technique is either transform gracfully or provide a fallback

bc: consistent with conformance summary wendy and I did (required technolgoies vs. used technologies)

<scribe> ACTION: michael - define term "tranform gracefully" and put it into context of why we wanted to define it. [recorded in http://www.w3.org/2005/04/06-wai-wcag-minutes.html#action01]

mc: seems that we're going back to the group with a recommendation to continue working with the baseline assumptions we've been headed toward

Impact of externalized baseline on Requirements

mc: Guide document and general techniques

dm: concerns about guide document - people looking for techniques will mostly not be interested in rationale, etc. (thing we're planning for the Guide Document). In gerenal, the guide document seems to be directed at people interested in guidelines (policy and high-level understanding people )

mc: can this be summarized by saying that we still need a traffic cop (independent of the guide document)?

dm: yes, anything that includes techniques needs to include general techniques

mc: not clear if what we've been talking about is including the general techniques in the guide docuemtn or not

dm: we need a way for people who are working on the code to have easy access to general techniques without having it sloshed around in the rationale, etc.
... technical nature of techniques should not put too much cognitive load on the webmaster

bg: probably a way we can pull them out into a separate document.

dm: no problem with that, would like to see them married to techniques vs. guidelines

tb: depends on how content developers will access the WCAG documents

dm: what I'm saying is that technical people will go into techniques themselves

mc: inclined to think each of us has diff. assumptions about how people will use these docs
... at CSUN, someone mentioned that it's possible that few will actually read the guidelines, but it's the framework under which the rest of this exists.

bc: prototypes for what the guide doc might look like coming next week (with content) - might be something to bring up again when we've seen those

mc: let's keep that on the table, are there other impacts on techniques for externalized baseline?
... obvious one is that techs need to indicate whether it's a technique for making a technology accessible or it's a technique for providing a fallback.

bc: challenge for techniques around grouping - think that what we want is to provide info so authors know if a technique applies to the baseline they're using. if they don't have a baseline, then they need to be able to derive a good one from the pro/con info we provide in techniques.
... not sure how it works, seems to be a need to talk about techniques as groups - (ex. if you're using baseline X, look at techniques 1, 3, and 8, if you're using baseline Y, look at 2, 4, etc.)

mc: a number of ways we might deal with this, ex. levels of techniques

bc: seems like an end-to-end type thing - ex. i18n has "pros" "cons" "discussion" in their techniques.

mc: seems like prototyping for a couple technques would be good to get started on.

bg: could each take some techniques and work on them

bc: 2 things (1) what to include in techniques to see what baseline the technique applies to and (2) pros/cons/discussion such that an author can make a baseline decision based on available techniques

<scribe> ACTION: bg, bc, dm, de - take 2 techniques (HTML or CSS) and revise to include baseline info (to list by April 11) [recorded in http://www.w3.org/2005/04/06-wai-wcag-minutes.html#action02]

mc: that action should help us to work on requrements as well - other minor requirements changes needed as well

dm: are we assuming the 3 baselines from summary?

mc: more about covering baseline issues and how does use of a technique relate to an authors baseline?

Need to agree on matrix of UA for which we provide support information

---- 5 minute break ----

<David> quarum

http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/att-0667/draft_test_matrix_v2.html

mc: need to define which UA we want to provide support information for

bg: clarification on priorities?

mc: priorities for us, not related to priorities in guidelines

<David> MC: firefox 1.0 no AT, FF 1.1 with Jaws and/or Window Eyes

<David> lynx

<David> i.e 6 with AT

<David> HPR

<David> HPR 3.04

<David> opera (level 2, firefox level 2)

slightly newer version: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/att-0667/draft_test_matrix_v2.html

<David> AT Jaws, window eyes, daulphin, latest versions

<David> zoomtext

dm: can get some help with testing magnification software
... should we include voice navigation?
... scansoft is about the only one in the mkt. these days

mc: scansoft = dragon

bc: what would we be testing?

mc: ex. form labels - "click first name" could put focus in appropriate field (buttons and hyperlinks primarily)

de: what if someone wants to include a new product or is angry that we haven't included theirs?

mc: could say we chose these tools to get a reasonable sample, if you'd like your sincluded, we're happy to include the results and you'll have to do the testing

bc: do we even have the resources to include the results of their testing?

dm: we'll be more critical of things than a company might.

mc: maybe cross that bridge when we come to it.

bc: might be able to include info on some only for certain techniques (ex. dragon on forms and links, but not other techniques)

mc: good idea to try to scope what we test, especially ATs
... what about linux and mac?

<Michael> o Firefox 1.0

<Michael> o IE 6 plus AT

<Michael> o HPR

<Michael> o Lynx

<Michael> o Firefox 1.1 plus AT if available (p2)

<Michael> o Opera (p2)

<Michael> o ATs:

<Michael> · JAWS

<Michael> · WindowsEyes

<Michael> · ZoomText

<Michael> · Dolphin

<Michael> · Dragon

Test file reviews (if time)

mc: defined batches of 5-10 and assigned action items
... please complete assigned tests by next week
... ready for assignments of second batch?

<scribe> ACTION: michael to assign some additional test reviews [recorded in http://www.w3.org/2005/04/06-wai-wcag-minutes.html#action03]

This is scribe.perl Revision: 1.122  of Date: 2005/03/31 04:43:41  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Ben
Inferring ScribeNick: ben
Default Present: Becky_Gibson, Ben, Michael_Cooper, Don_Evans, [IPcaller], Chris_Ridpath, Dave_MacDonald, Tim_Boland
Present: Becky_Gibson Chris_Ridpath David_MacDonald Don_Evans Michael_ichael_Cooper Ben_Caldwell Tim_Boland
Got date from IRC log name: 6 Apr 2005
Guessing minutes URL: http://www.w3.org/2005/04/06-wai-wcag-minutes.html
People with action items: - 2 bc bg css de dm html michael or revise take techniques

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.