Held after the CSUN conference in Los Angeles, CA USA. Agenda
This document contains notes that were taken during two days of face-to-face meetings. They are not a complete record of everything said during the discussion. In addition to these notes, two summaries have been sent to the WCAG WG mailing list:
Thanks to Andi Snow-Weaver, Becky Gibson, and Loretta Guarino Reid for minuting.
GV Reviewed the agenda for the day:
GV reviewed how we would organize the baseline discussion: two rounds of going around the table asking people to comment on the following questions (in a couple sentences or less):
GV clarified recent changes in process and how they relate to people attending today's meeting. 11 March 2005 was a cut-off for people to rejoin the working group. 25 April 2005 is the deadline for people to exclude patents (per the W3C patent policy). Some people were unable to join us today because they are still reviewing patents. Until they rejoin they are unable to attend face-to-face meetings and teleconferences.
js: talking about baseline in order to narrow the scope of our guidelines and distinguish from UAAG and ATAG. Doesn't solve what specific technologies are assumed or not assumed
bc: what technologies can authors use to conform to WCAG 2.0 without having to provide alternatives? scripts on/off, plug-ins, etc.
db: helps give us more clarified position and direction in terms of where we're going to go.
bg: agree with BC. Immediate concern is JavaScript and CSS. Doesn't help us at all with scoping.
ev: pass
mc: guideline dependence on user agent support. find ourselves tempted to write guidelines around what user agents can do. don't want to tie ourselves to UA support in 2005. may also tie us to current "spec" support. baseline allows us to not ask that question when we write our guidelines. we answer it some other way.
wc: looking at the shelf life of WCAG. baseline allows us to document our assumptions about UA support.
as: want to make sure that going forward, as technology, AT, and architectures improve, not locked in to requirements in WCAG that are not necessary anymore.
mb: seen divergent interpretations of what baseline means.
tw: baseline is a goal. reality is UA support. don't want to require unnecessary burden on authors. separate guideline from techniques. techniques would provide techniques to overcome UA support
makoto: some screen readers only available in Japan. some differences between English and Japanese version even if it is the same version of the same product. have to test things to make sure they work.
masahiro: Japanese issues of Web content.
seki: no comment
lg: help us decide what technologies can be used by an author. helps us distinguish between what belongs in UAAG and what belongs in WCAG. don't think it will solve the problem of upgrading computers and how far people have to go in terms of backward compatibility.
dm: without a baseline, condemned to text only. If going to be progressive set of guidelines attractive to industry, have to look forward as much as possible without losing sight of accessibility itself. Have to allow people to make things look and sound good. Will also separate out the burden of what is within the scope of our responsibilities and out of our responsibilities. Won't solve the problem of people who choose to lie.
de: pass
gv: solves what authors can assume about what users have. Need to have a means for the baseline to move over time. UAAG doesn't answer key questions about what we can assume the user will have. May have to include financial and language considerations or we may end up with a baseline that can only be met by the most popularly supported AT.
gv: clarification on Mike's comment about different interpretations of baseline. have you seen anything that is in conflict with what we have been saying today
mb: comments on list about baseline being and "until user agents" umbrella vs. writing down a litany of technologies we assume to be true. thinks that WCAG defining "baseline" is a slippery slope. baseline could be left up to the claimant. conformance "claim" could define whether or not the accessibility is solved by technology or by the content.
gv: baseline assumes technology but we don't know if it is turned on or not. users may be required to have technology turned on or off because of their particular disability.
de: pass
dm: adopt UAAG, adopt subset of UAAG leaving out things that are difficult but not show stoppers
ja, lg, seki, masahiro, makoto, tw: pass
mb: if we define what people can assume, we are acting in the role of government. believe we should leave it up to the author. have to trust that they know their audience.
as: agree with mb.
wc: UAAG doesn't provide the full picture of what we need. Also need assistive technology AG. Until we know what we want ATs to do, we can't assume what they will do.
mc: refers to post of a week and a half ago. considering WCAG as content authoring guidelines alone, have to assume support of user agents and specifications. don't think it really means "UAAG as baseline". if we rely on techniques to bridge the gap, then techniques are not in support of WCAG 2.0 success criteria. alternative is to have section in techniques that deals with "broken stuff". thinks that what MB says about leaving baseline up to the claimant is a natural consequence. we could provide some guidelines on what is reasonable to assume as a baseline.
ev: pass
bg: scoping is potential solution. allow the author to specify
db: pass
bc: leaving baseline up to the author is interesting approach. leave judgement about legality to policy makers but concern that this requires policy makers to have high degree of technical knowledge about what ATs can and can't do.
js: organizations already provide policy guidelines about what technologies to test with. Maybe we can provide some guidance on including AT in those test suites. if we go that route, it has to move up higher in conformance levels than it is now.
gv: talked about not allowing horizontal scoping. sounds like the scoping we are talking about is horizontal scoping; e.g. my site conforms except for all the images. looking to UAAG but don't "base" on it, have to be more specific. Have to say something about scripting. already assume baseline all over our guidelines. answer might be: in the guidelines (what to do) we don't make assumptions but in techniques (how to do it) we do make assumptions. authors don't have to do what is in the techniques docs but if they do, they have a "sort of" safe harbor if challenged. if they don't use the techniques, then have to prove on their own that they have met it.
dm: would like to see authors saying what their target audience is and what their assumptions are about their target audience
mb: are we output focused (end goal we are shooting to achieve) or are we writing guidelines about content (technology focused). we should be output focused.
gv: baseline discussion came up not for the guidelines but in the techniques
lg: would the techniques then talk about specific user agents? does that make the techniques work really huge?
lg: end users are concerned that authors will make bad or selfish decisions. authors are concerned that they will have to know so much about at support, etc.
as: refers to gv comments - if techniques are to be "safe harbor", it is important that all versions of techniques documents be archived so that if people need them for legal defense, they are available.
mc: find that baseline does affect guidelines, not just techniques. choosing your baseline smartly does involve knowing your target audience
gv: target audience usually means 80% of their audience which leaves out people with disabilities.
mc: choosing target audience poorly is the same as lying about conformance claim.
dm: Rich Schwerdtfeger comments about target browser, not target audience.
mb: must clarify - if we have a baseline, which docs does it apply to.
js: fundamental assumption we are asking authors to make about their target audience is that it includes people with disabilities
gv: if leave it up to authors concern is that they don't care at all or that they do care but they don't know what to do
mb: great suggestion about including AT in testing standards but where does it fit in the documents? might be WAI white paper.
wc: Judy mentioned this in yesterday's IG meeting was that some countries are looking at process guidelines, not just content guidelines.
mb: if you fix the process, the content gets fixed.
someone will always be excluded if we define any baseline - for example, a text only browser is not accessible to people with certain kinds of learning disabilities
there is a document about how a browser should behave - WCAG should update and contribute to that document as a sort of "ideal" baseline
moving towards the author being able to select the baseline but we need to make sure they don't make stupid decisions author will need to document the baseline in their conformance claim
talked about different profiles - WCAG 2 applications (content management applications that are a combination of WCAG and ATAG), WCAG 2 basic, etc.
talked about shelf life assumptions and implications - where do we think the technology is going to go? how can we adjust the guidelines for that?
Summarization of problems:
How do we solve this problem?
1. don't specify a baseline
2. specify a baseline
mc comment: baseline means that GLs eventually become obsolete
gv: if this were done, it would allow WAI, or a company, or a government to define what to do if a particular technology is not supported or turned on or to say "follow WCAG assuming no scripts", etc. Frees us from making those decisions in the techniques.
wc: if we don't provide a baseline, we can just leave that to policy
gv: if one of the questions is what technologies authors can use
wc: can we, as a group, create a pro/con for each proposal?
<get from flip charts>
wc: have to provide a text alternative for images because there aren't any tools that can analyze an image and create a text alternative
wc: the way the GL are currently written, there is an assumption that the author has to provide a text alternative
gv: could make changes to the guidelines and move more things into the techniques
mb: guidelines as written are not end result focused. they are author focused
bc: how much more techniques work would Group 3 proposal require?
gv: both group 2 proposals require putting UAAG assumptions into the guidelines
yh: how do we indicate that if you use new technologies, you have to do it in an accessible way
gv: gv, js, and wc will get together tonight to try to digest all this and come back with recommendation tomorrow. anyone else can help as well or make an attempt to create another proposal or a hybrid proposal
js: all proposals have implications on structure
presentation by Rix Centre regarding needs of people with intellectual disabilities
need for images, multimedia, animated content
for questions or follow up - simon.evans@rixcentre.org
scribe: Becky
John: use same procedure as this morning by apply to structure of documents; relationship of GL to Techs docs. Have been number of proposals on the list in the last few weeks. Michael's framework proposal and Gregg's as well. Ben's recent posts of the checklists. First, go around room and harvest ideas about what problems we are trying to solve and then about what solutions.
Keep comments brief; no responses just capture at first.
Ben: pass
Doyle: pass
Becky: pass
Michael: techs need to be granular desc. of what to do technologically within a technology; index by elements for HTML or what is relevant for technology; techs must relate to SC - how is still open; must be a reason for tech to exist; don't care where reason is as long as someone says "how do I conform" they can find a tech of what to do; also need to learn why; putting education elsewhere makes techs only usable by devs; mixing tech and educational in one place confuse readers looking for one or the other. and/or is also a big issue - if I follow this tech. do I conform to x SC or do I need another tech. too or are there others that I can use; what to do when I have two techs that work together (HTML/CSS) keeping them separate hasn't been working but putting them together has issues as well.
Wendy: good job Michael; give people enough info to make choices and how to apply in different technologies; not sure we have a good consensus on who is the audience; very focused on docs and the prototypes that we have done are more app like than documents; we have a database of techs that are very granular; need to clearly understand our purpose and audience; help test the viability of GL and SC.
Andi: techs and test cases together will define how eval tools will define conformance; today have different tools that will give different answers for conformance - need to solve that problem or diminish;
Mike: pass
TW: problem with the volume of the documents; how easily an author can use the doc; when I want to know about CSS I use a handbook with an index and I can easily find what I need; we need a good navigation mechanism, too
Makoto: contents should be understandable; there are many non professionals who create web pages so we need simple info and easy to use structure
Masahiro: techs depend upon specific UA but also on AT so for example one Japanese screen reader can not deal with alternate text is image is very small; Japanese screen reader company is very small and can't always address issues; how can we describe these types on issues in the document;
Loretta: how to make it clear what is req. to satisfy the GL but leave ourselves enough flexibility to grow the GL. Like the idea of making SC be the checklists. But need to understand the implications to the techs doc. Worry that SC list is complete
Jenae: pass
David: in real world authors won't read the GL just the techs. Just want a code snippet to tell them what to do. We aren't going to make them compassionate - we have to accept that reality; Policy people will read the GL and not care about techs. So, need to separate the two. Don't bruise the egos of the Policy people and tech people won't compromise integrity by being compassionate. Navigation is important - I intro'ed traffic cop awhile ago. Our focus is to get it written but as a group we need to hold ourselves responsible for making it navigable. at some point would like to resurrect traffic cop or some other web app. or whatever based graphical solution. If we fail on the navigation people are going to throw up their hands and we will end up with more derivations (like in Europe). Likes the current structure.
Don: pass
Gregg: goal is to not have docs with conflicting req. In the end we have to make sure we give the same information from the docs. Will help the GL work longer; GL say what to do and the techs tell you how to do it or ways of doing it. Techs also have things that go beyond what is req. need clear delineation when have gone from one to another. Don't want techs mixed in with other things. Mike said tests are not conformance tests but are an example of how to achieve a method of achieving the GL
John: implicit in what everyone has said is that we have to find a structure that presents the info to the identified audience in the way that is most useful to them. Req. doc identifies a number of audiences and we need to provide a way to provide the info w/o requiring too much digging and it must be useful once they reach/ struct must support alt. navigation mechanisms; must support continued growth and addn techs as tech. involves without rewriting everything. May also need to find a way to make older techs avail. on an ongoing basis for those who need them. multiple audiences and flexibility.
Those proposed to list and others then we will break out into groups.
Gregg: SC as our checklist is key - has seemed to resonate as we have looked more; techs provide example ways to conform (not necessarily THE way). Not too much work to turn SC into checklist; Techs show how to solve SC. Within techs need a mechanism to write down other things that might be done that go beyond but need to make it clear what goes beyond and what is minimum;
Don: pass
David: traffic cop or some derivative is way to insure people can easily get to material they want and to tie SC with technical documents. Will help how docs are perceived
Jenae: pass
Loretta: want organization to be something I can integrate PDF techs into; don't want to excluded linking external tech in
Masahiro:pass
Makoto: techs should say how to do and why need to do; techs tend to focus on technique but it doesn't always make sense - example alt text for image but that doesn't always say why that needs to be done
TW: authors read techs but don't read the GL
Mike: GL are normative; techs show how one might implement the GL; and tests verify that tech does implement the GL; if techs and tests and checklist were a collection of inter-aware XML docs - you could easily add another set of techs into the document structure; within techs docs there are examples of conformance techs that relate to a SC in some technology; there are also informative and repair techs for known issues and how to work around; here is an example of how to implement something that degrades gracefully; here is an example that is above and beyond but it is a best practice in some situations; conformance tech; work around tech; and goes beyond tech; when write tech or test need to put into it that it reuses the who benefits section or at least include why it is relevant; Need a doc that organizes techs based on benefit of using;
Andi: pass
Wendy: need to be clear on how techs are beneficial; John, Ben and Wendy have played around with having one document that has everything you want to know about one particular SC; why it was written; who benefits; how to implement; Currently it is not clear which examples in GL apply to which SC; From one point can find out everything you need to know about a particular SC; Many of these ideas have already been prototyped that we need to go back to and look at;
there is application of techs and understanding of techs; right now techs are more of a database; need a topic index to techniques
Michael: important to focus on authoring - see that as our mission; at least two proposals from me - WCAG as GL do define what has to be done but must have authoring GL; group has been about Web content but I think about web authoring GL (probably because I work on techs). General techs are non-normative explanation of the GL - provide generic authoring advice; tech specific techniques show how to do using a particular technology. should be granular and short; separate each technology as much as possible; HTML would not be polluted with CSS - could say here is where you need to apply a CSS tech and here is a link to it . And with XML can combine them in some doc. if we want; need educational materials; meta data -why, which GL and which SC; in terms of defining authoring practices short granular techs are the
Eric: pass
Becky: pass
Doyle: pass
Ben: 1st priority is to move discussions in to tech specific; until we know what we want to say we don't have way to clean up navigation; need to get to decisions about how to sort; which are req.; optional; go beyond; still concerned about SC as checklists idea - need more annotation of techs; somewhere in all of the links in the complex checklist is the info we need - just now sure where.
John: solution is to explore the solutions proposed. some are quite different and have different implications. look at them and see what problems are solved and what implications; do some solutions solve more of problems than others? our lunchtime guests reminded us that we need to keep the users of these documents in mind and try to anticipate those problems and issues. it isn't our needs - we are writing these for other people who haven't had the pleasure of participating in these discussions :-) any clarifying questions?
Andi: David can you explain the idea of the traffic cop;
David: during a discussion one day about all the documents the idea of a British traffic cop arose. Provide directions of where you want to go to get what you need; start with a simple table, SC on left hand side, middle col. had all different techs and right had side have all techs that apply to that SC. Simple way to get to tech you want to use to get solve a particular SC. No additional info on the page, just SC, Tech and list of techniques.
Gregg: someone said that authors only look at techs - but thinking about what Wendy said about all you need to know; need how to but heard that also need why to; that makes very little in GL that won't eventually end up in techs.
Wendy: FYI just looked at international pages on the USB key and some stuff seems to be missing
Andi: people comment about keeping user in mind; we know our users but we haven't done any task analysis on what they want to do; be good to do user testing
Wendy: WAI site task force has done task analysis
Andi: we need to look at that analysis and persona that task force has done as well as redesign proposal
Gregg: look at min. set of documents that wee need to capture all info; we may add addn views and treatments; shouldn't worry about multiple views until we at least understand the minimal view; Once we get all the work done it will be easier to see how to make it all fit
David: SC as checklists (input from the list - Alistair has concerns that SC as checklists aren't detailed enough. He wants very specific checklists to test to conformance;
Gregg: we have techs doc - is it accurate to say that you can conform to the GL without doing each one of the techs - techs are examples of solutions; it is okay to say "I did something else" - how to check these - don't want a "something else" check on the checklists
Michael: if there is no other reason to have a checklist then it falls into the domain of the tool writers. I understood GL wanted to have own checklist as a way to understand the GL
Gregg: need checklists so know how to pass.
Mike: these are the GL and these are the SC
John: each group should summarize what we have heard is the desc. of the problem and what solutions we have heard. Look at set of docs that Wendy has provided that represent current proposals and review those against the problems that have been articulated today. Take one of the solutions and try to push it further or find a way to break it
Gregg: or hybridize the proposals - pull the best out of various ones
summary: usability
need to do role analysis
are checklists
needed?
based on GL
accessible
usable
Guidelines include
topical checklist - summary of verification of GL
related to technology cloud - which includes techniques document (what does it look like to successfully implement in one particular tech) and document that explains what does it look like to validate
general techs that better explain
Role analysis:
decision maker - policy maker - looking at why we should do this? why spend money - why require
implementers and verifiers - technology specific documents
checklist - all audiences; need report format - not a verification tool but a reporting tool
Addenda = General techniques; used mostly by policy/decision makers but not being "sanitized" for policy use also applicable to implementers but they probably won't come here first
more analysis and benefits
user scenarios
examples
deeper exploration of terms
decision heuristics
when to apply SC
what type of content affected
deeper explanation of benefits
(does this mean we strip examples out of Guidelines and put here?)
helps to know when to apply a particular GL - for example: how do I know when my alt text is good
Summary:
techs indexable by element and by component
tech indexable by SC
need the everything you need to know to be somewhere - but where
techs must be able to grow over time
authors can end up with consistent results from eval tools
diff between req. and advisory
what tasks map to what docs
ease of use for collection of docs as a whole
concern that don't have too many docs
Solution:
GL doc
Checklist that include only SC
info needed to understand SC
techs that satisfy a given SC - list of tech specific techs and combination
have section of advisory techs organized similarly
take techs and list as individual page -
programmers /application dev guide - organized by tasks that author wants / forms/tables, etc - index plus introductory info
sort of like chapters in a book
annotated checklists.......
how to distill info from techs and tests to distill what conformance is
treat General, HTML and CSS docs as similar in structure
Addenda doc:
how to get the right information "above the fold" (like a newspaper) - take a mini table of contents on the page with links further down the page but right up front list of links to techs.
comments: addendum format is similar in both groups
What we heard:
continuing to evolve techs
including beyond W3C technologies
author be able to use information to decide if has satisfied requirements as unambiguously as possible
techs must be granular and separate
must understand audience and scope
how do techs relate back to GL an SC [just principle; back to GL only; back to SC; or some other standard]
not many people are going to read the GL but they must be there.
Solutions:
we didn't focus on relationship and layout of documents - just stated requirements - because most people will come in with a problem -looking for very specific info
many people don't understand the problem - so must have way to get more detail from the specific solution
index - will vary by technology; must include concepts - set of concept index terms
navigation mechanisms - that include a hierarchy;
granular techs
techs tied to SC (even if in another doc. can't include tech if it doesn't tie to something)
create new SC under 4 that is "deal with broken stuff" and repair techs point back to that
like Ben's second checklist idea as a TOC / traffic cop
format should be officially public so other technologies can use it
Wendy: questions that no one will read the documents - many people have read WCAG 1.0 but haven't found the techs
Mike: agree with Wendy will read GL and some will read the techs
Loretta: when I point out a doc is inaccessible - the dev wants to know how to fix it so will go directly to techs
Wendy: designers need higher level
Andi: but designers expect the technical people to help during the entire process
Becky: but designers have no idea how to relate that to a technology
John: there are very different people who are going to read the GL - whether they get read or not they need to be there. there is still other stuff we need to do to achieve the checklist after going thru agony of creating all the other docs
Gregg: whether one gets used more than other is a moot point - both (gl and techs) are req. we must do a good job on them all but can't assume all will be read so each must do good job of explaining
heard the we could pull examples out if they were causing confusion and put them somewhere else. Sort of which is more important the mom or the dad?
andi: depends upon which part of the process :-)
John: need to review what we did today and pull out the common points and that are agreed upon and what are the points of contention. Need volunteers to work on that this evening.
Gregg: while listening to all 3 proposals the requirements seemed to be very similar. Does anyone see anything they saw in another group's presentation that was out of sync with their own group's proposal? Do people agree that this is the correct direction for structure?
Mike: what we have today is what we need but not sure everyone has the same conceptualization of what we have today; one group had new docs that might be useful but out of scope with what we are doing today. Annotated checklist is an additional document as is topical. Need to review and agree with what we have today: Have today: GL, checklists; general techs (Addenda) - this is clarification of GL; technologies docs are secondary supporting information; So, don't think we are coming up with anything new - just firming up what we already have
John: our group talked about existing techs documents being adequate - we believe yes, with some tweaks
Gregg: techs are not organized by SC which is what you would need if you are trying to explain the GL
Mike: only need that SC organization in the General techniques; is collection of addenda that explain what we are talking about in GL; as distinct from techs which is implementation based
John: if we are agreed we have the structure but still need the navigation
Michael: organizing by SC is easy to do; Mike was asking do we need techniques documents for recommendation; Maybe not for W3C policy we don't but I believe we must have them
Mike: don't think we need them for rec.
Wendy: it is in our charter to deliver them so we have no choice but to deliver them. we don't need entire set but need at least some of them
Mike: what is the minimum set to get to rec.
Wendy: charter shows what is needed for rec. and what is ultimately required over time; doesn't believe it is up for debate that we do techs docs
Gregg: what is sense of group for techs - separate docs vs combined what does group thing
Wendy - (review proposal on flip chart)
first page is topic index
example: how to make an accessible form (this example:comes up in task force redesign usability testing)
for Level 1 list SC and techs that apply: you need tech x, y and z
for level 2 here are SC and you need a, b,c
follow x,y,z and a,b,c, actually link to specific techs in the HTML tech docs
perhaps too much granularity in some of our tech docs
Gregg: but this makes it seem like these techniques are required to meet SC
Wendy: no, these are techniques that are sufficient to meet SC
Ben: i18n have both topics and techs index - techs are not integrated into GL
Wendy: EO is already doing overview of WCAG
Gregg: we have the addenda (general techs) document and we have techs - our group envisioned techs as modular and separate; other groups expect them in documents by technology? Can techs be collected together and still be granular
Mike: is there a functional reason we can't have multiple presentations?
Wendy: what is all collected together? what do you mean all techs collected together
Gregg: do we see html techs as several separate files or one document with each tech as a separate part of the larger doc
Wendy: would like at least one view that is acceptable to everyone so we can at least get to rec.; would like to have multiple views but need to focus on what we need to make sure we can get to rec.
Ben: we can slice and dice the documents anyway we want; what info needs to be included and what pieces do we expect to be presented together
David: Shawn mentioned people being confused by being dropped into the middle of the doc and need to fix that
Wendy: Shawn was very serious about that problem being fixed
David: because many people just want to print
Andi: our task is to review the entire document set - "real" users don't necessarily need to print or read the entire doc
Gregg: put them all in one document for now and in order to go to rec. but could reorganize later
Wendy: but need the navigation mechanisms. Right now all W3C rec. are docs - there are not any other recs that have multiple navigation mechanisms; do we really want to be the first?
Gregg: we need to decide if it is one big doc or several little ones
Mike: having docs to go to rec. is traditional; don't want to be first to push the envelope; there are known techs for improving the navigation when we role out the EO redesign site. Will save us time if we work with single docs
Gregg: But we said that Shawn was serious about not being in one doc; is Addenda one doc?
Mike: yes but doesn't have to be - can
Gregg: can have a relative link in the GL which will go thru robot to go thru a doc and serve up just a piece of it. Like idea of not having 2000 docs.
Wendy: site redesign is just trying to steer people away from TR docs because they have determined that TR docs are very unusable; in testing of redesign the places where the redesign got lower marks was when it linked into the middle of a TR doc.
Gregg : tomorrow we need to make some hard decisions - people need to be thinking about the right things overnight. Made good progress together; structure is coming together; need to review baseline again;
Meeting officially adjourned. Any one can stay and discuss tomorrow's agenda.
Monday, March 21
Present: Ben Caldwell, Doyle Burnett, Becky Gibson, Michael Cooper, Andi Snow-Weaver, Wendy Chisholm, Mike Barta, Jenae Andershonis, David MacDonald, Makoto Ueki, Takayuki Watanabe, Loretta Guarino Reid, Don Evans, Greg Vanderheiden, John Slatin
In 2003, several projects from EU filed for funding, 3 were funded, but because of overlap, EU commissioned them to work together which resulted in the creation and funding of the WabCluster. The 3 projects are:
In addition to working with WAI, have a mandate to work with CEN/ISSS.- Holding a CEN workshop in Brussels, April 14, to come up with an agreement on the methodology.
WabCluster is part of all 3 projects. 36 month schedule to come up with a unified web evaluation methodology. Plan started in October 2003. First part of project uses WCAG1. They have written a clarification of WCAG1 based on WCAG2 work, and are developing methodology. In the next 6 months, they will do user testing and build benchmarking tools, and the evaluation methodology will be tested. They will feed back user experience to WAI. Then they shift to WCAG2 in Sept 2005.
They try to do their work within the WAI working groups. Alistair has participated in the WCAG techniques subgroup. Want to use WCAG2, rather than write separate European guidelines.
Then another 30 months of users testing, etc.
Eric is now a WCAG participant. He will ask the Norwegian members to participate in the technical work.
Looking at European legislation which is based on WCAG1, and analyzing what problems might arise in moving to WCAG2. They expect to begin working on WCAG 2.0 evaluation methodologies September 2005.
Gregg's summary of yesterday's baseline proposals.
John Slatin - no strong support for including UAAG; introduced for WAI support. General perception is that UAAG doesn't solve our problem.
Ben - thought we were converging on "no baseline", but need to understand implications for conformance
Doyle - dynamic baseline consensus?
Becky - make sure guidelines are output focused rather than action focused. Similarities are that authors can specify baseline.
Michael - author choosing baseline is a commonality in 1 and 2;
Wendy - all 3 require author to make good decision about baseline; role of UAAG reduced; heard that author must assume that audience includes people with disabilities; baseline is not static; even if baseline is text-only, it will exclude people, so it can't be viewed as lowest common denominator.
Mike - difference is whether baseline is explicated; version 1 doesn't require claim to list technologies; policy issues are outside WCAG; WCAG will not resolve disputes about conformance claims
David - "if user agents" may be an difference between proposal 1 and others; commonality is frustration over mismatch between UAAG and WCAG needs.
Makoto - UA support must be different for different countries or languages; do we need a different baseline for different countries and languages? for Japan, need to check Japanese UA support against UAAG
Takayuki - common is that baseline is different among countries; we need a concept of baseline;
Loretta - moving baseline out of WCAG has serious consequence on conformance statements
Companies will never make a public claim unless required by law, for legal liability reasons.
assumption
Starting investigating Sheet 2 for GL 4.2
How to specify the list of technologies used?
Assumptions implicit in existing GL/SC/Techs
In the spectrum between Ideal Tomorrow and Broken Reality today, where do we fall? where do we aim for?
What is broken today and what are the chances it will be fixed in the next 5 years?
WCAG as a roadmap? Policy vs effect?
Conclusion: we don't have a decision, but we need to make one SOON
Mike B comments that Sheet 1 doesn't require all possible techniques; recommends extremely basic assumptions; can't specify a baseline that is appropriate for all users in all circumstances
Moving Baseline out of WCAG
GL 1.1
GL 1.3
GL 2.4
GL 3.1
GL 4.2
scripts
Flash
Baseline setter hierarchy - author, manager, company, customer, government (highest one that asserts itself)
if gov is the ultimate baseline setter, breaks harmonization
should WAI make recommendations on what the baseline should be? important that govs be free to set the baseline
in setting baseline, govs should apply pressure to both authors and AT vendors. Set baseline above what AT is currently providing, puts pressure on AT vendors to increase support. gov can help AT to increase support.
Document outside WCAG guidelines that provides guidance on baselines
describe the fact that baselines will vary by language and geography
variations should be proper subsets of each other
implications of lack of user agent support within language/country
John Slatin - currently GL 4.2 level 3 requires a list of technologies; perhaps instead should ask for a list of UA, including AT, against which the content has been tested
Mike - Dispute that because gov is ultimate baseline setter, it breaks harmonization; guidelines don't change; you can implement to the strictest standard. Concerns about having a list of technologies, UA, etc, because the list just tells them they can't access the content. Other level 3 guideline is that you should provide fallback to the "baseline"; there is a class of applications that isn't able to be accessible in a given baseline.
Gregg - "if user agent" == "until user agent" claim; should say "if XXX is in the user agent baseline, then these techniques apply; else YYY ". This would enable someone to baseline it in or out, and let them understand the full implications.
Home Page Reader analysis
UAAG implementation report for HTML 4.01
Summarized in Key results and recommendations from Face to Face
Before 24 March telecon
At 24 March 24 telecon
By March 28
At 31 March telecon
By 4 April
At 7 April telecon
April 11 - publish proposal for revised document structure: John [Wendy, Gregg, Ben, Michael, Becky, David]
April 14 telecon - discuss proposal
Addenda (== Guide Doc) looks like an addenda for each technology.
Wendy envisioned it as about success criteria, not topics (e.g. Forms and labels topic probably belongs in EO).
Should techniques only address accessibility issues? Are educational resouces only related to accessibility, or do they address more general coding issues? Michael thought more the former than the latter.
Gregg's summary of what yesterday's discussions proposed:
Open issue: Are the general techniques separate from the Guide Doc?
Ben presented his summary of the similarities and differences between yesterday's document structure proposals.
$Date: 2005/03/29 23:25:21 $ WCAG WG