See also: IRC log
<scribe> scribe: Ben
mc: agenda for today:
... re: test files - need to follow up with people on assignments and make new assignments
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
... 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)
... 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.
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
... 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
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,
... 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
... 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
... 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
... 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?
---- 5 minute break ----
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> i.e 6 with AT
<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
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
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.[End of scribe.perl diagnostic output]