Issue summary- "Baseline" sort term

“Baseline” Sort Item
* Alex Li prepared a review of Baseline sort items in August:
http://lists.w3.org/Archives/Public/public-wcag-teama/2006Aug/0017.html

Unfortuneately, the set of items under this sort term has changed since then, but there is substantial overlap. Please review his comments and suggestions.
* Cynthia Shelley proposed criteria for choosing baseline technologies:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JulSep/0219.html

* Gregg Vanderheiden started several threads on the baseline concept:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JulSep/0186.html

http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JulSep/0185.html


Summary of Issues:
1. The concept of baseline can be misused by people who aren’t concerned about the accessibility of the technologies that they want to use. By ignoring the user agent support for technologies, sites can claim WCAG2 conformance when they are inaccessible to people with disabilities.
2. Interaction with 4.1: 
a. How can a technology, and especially a version of a technology, be specified in a baseline claim if validity is not required.
b. How can a baseline permit the use of deprecated features of a technology.
c. How can a baseline permit use of technology features that aren’t supported by user agents and/or AT.
3. Misunderstandings about the use of technologies outside the baseline
4. It is very difficult to specify effective baselines; authors won’t know the capabilities of different versions of different user agents and assistive technology. Given the expertise required, who chooses baselines? 
5. Misunderstanding: commenter thought that when choosing inappropriate technologies for the baseline, any SC not supported by the technology could be ignored.
6. Misunderstanding: baselines consist of user agents or browsers, not technologies.
7. All baselines should require at least HTML. (e.g. TEXT + AVI should not be permitted)
8. Baselines should require that there be UAAG-compliant user agents available
9. Baseline is hard to understand; need detailed guidance on how to decide which technologies to include in a baseline, and why; need concrete, realistic examples to help people understand the utility of the concept. 
************************************************************
Comment LC-513
Sort Terms: 4.1.1 & Baseline
Document: WCAG 2.0 Guidelines
Submitter: Jason White <jasonw@ariel.its.unimelb.edu.au>
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (Including rationale for any proposed change): 

This guideline doesn't require the use of technologies, for example markup languages, in accordance with the semantics defined in specifications. Assistive technologies such as braille translators, as well as content transformation tools, rely upon the assumption that elements and attributes of markup languages are used to convey the meanings prescribed in specifications. To the extent that content departs from this requirement, programmatic determination of structural and other aspects of content is precluded, being reduced instead to a probabilistic matter requiring heuristics to be introduced by the software developer. Although the definition of "programmatically determined" refers to support by user agents, it doesn't explicitly refer to standards governing the technologies used in the content. 

Proposed Change: 

Add a requirement under this guideline to the effect that, for each technology in the baseline that is defined in a specification, every feature of the technology is used in conformity with the meaning and purpose prescribed in the specification. Even better, require it to be used in accordance with the meaning, purpose and syntax prescribed in the specification. Alternatively, if the above is too strong a requirement, restrict it at level 1 to every feature used to enable the structure, purpose or meaning of the content to be programmatically determined. That is, if the feature is used to enable programmatic determination for purposes of meeting the guidelines, then it must be used in accordance with the syntax and semantics defined in the specification governing the technology. This falls short of a requirement of full syntactic and semantic correctness, but the stronger requirement could be added at level 2 or level 3.
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Discussed in the 16 May 2006 Team A call, propsal sent to list: 
<http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0187.html> <http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0187.html%3E> ; 

(do not accept) 


CURRENT WORDING UNDER REVIEW - ===================== 

The group looked at this topic carefully over an extended period of time. In the end, the group concluded that although strictly adhering to specifications had many benefits, it also has limitations. It is one reason why all the technical specifications are voluntary and why companies often vary from them. 

With regard to WCAG, the working group tried to restrict itself to its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" do relate to accessibility. However, others did not. So requiring this went beyond accessibility. Regarding the second suggestion above, "features used to enable the structure, purpose or meaning of the content to be programmatically determined," are all required already by 1.3.1 so there would not be a need to add a new SC in 4.1. 

Comment LC-530
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Item Number: Technology assumptions and the 
Part of Item: 
Comment Type: GE 
Comment (Including rationale for any proposed change): 

The introduction of the “baseline” could result in some web content providers believing that it is acceptable to provide content that will be inaccessible to some people with disabilities. It appears that under WCAG 2.0, a site developer or some higher authority (eg Government regulator) can set a baseline using W3C and non-W3C technologies so long as there are “assumed” accessible user agents that support them. 

WCAG 2.0 allows develops to "assume" a technology will be supported and provides no guidance on what this assumption should be based on. In addition, there is no definition of what constitutes an "accessible user agent". Are the early versions of PDF and Flash plug-ins accessible user agents? Or, only more recent versions? And, who decides whether a current or future user agent is accessible or not? 

The guidelines provide examples of assistive technologies, but there appears to be no requirement for a nominated baseline technology to be supported by a significant proportion of assistive technologies that are in current use. 

With WCAG 2.0 it appears that it will be up to the person with a disability to obtain (purchase) the technology, which the site proprietor deems appropriate, in order to access a site, rather than the responsibility of the site proprietor to ensure their content is accessible to users of a wide range of assistive technologies. Such a requirement is unreasonable, especially given the high unemployment rate among people with disabilities, and it is also not in accord with "beneficial" approaches to disability such as those adopted in disability discrimination legislation. Such approaches recognise that everyone has a responsibility to make society more universally accessible. 

Finally, I am concerned the introduction of the proposed "baseline" concept will place a greater burden on organizations who are responsible for promoting and ensuring best practice in the area of website accessibility, in many different countries. 

Proposed Change: 

In my view the whole baseline concept needs to be revisited. However, since this is unlikely I would like to suggest the Working Group considers the following. 

1. Avoid the use of the words "assume" and "assumed". If they are used, provide a clear indication of what can and cannot be assumed. 

2. Define what is meant by an accessible user agent (as distinct from a user agent). 

3. Include a requirement for all technologies used on a site to be supported by a wide range of assistive devices that are at least one generation older than the version in current release. (Clearly there will be a need to indicate what is a "wide range" and the number is likely to be different for different technologies - eg for screen readers perhaps it might be four programs whereas for magnifiers it might just be two.)
Status: open
Working Group Notes: [TEAMA] 
[HOLD] ALL BASELINE ITEMS FOR REWORK OF BASELINE DOC]

Comment LC-531
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Greg Gay <g.gay@utoronto.ca>     Affiliation: ATRC UofT
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  (About Baselines and WCAG 2.0)
Comment:
Item Number: (none selected) 
Part of Item: 
Comment Type: TE 
Comment (Including rationale for any proposed change): 
There doesn't seem to be a place to comment on the Baseline Document, so I'll post it here: 

http://www.w3.org/WAI/WCAG20/baseline/ 

The potential for many baselines is possible, and each baseline will have an overall level of accessibility associated with it. For example, a baseline that includes only HTML 4, is going to be more universally accessible than a baseline that includes HTML 4, Flash, Java, and Javascript. For clients or developers using the latter baseline, we would essentially tell them that if their content made full use of the Flash, Java, and Javascript accessibility features, they can comply at Level 2 (hypothetically speaking). But, for a client who creates the same site that uses the first baseline (HTML 4 only), and has gone to the trouble of creating alternatives for their Flash, Java, and Javascript content, will have created a more accessible site than the site that uses second baseline and does not have any alternative formats. What motivation would there be for the developer of the site using the first baseline, if they can just place all the technologies in the baseline, and forget about creating more accessible alternative content. 

Proposed Change: 

The solution to this may be associating some base accessibility value with a variety of standard baselines, baselines which remain non-normative, and evolve as technologies evolve.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
Submitted by TEAM A 5/23/06 

Close with the following comment: 
{Partially Accept} 
"The path the Working Group is pursuing is close to what you propose. The Working Group does not want to specify particular baselines in the guidelines nor put "accessibility ratings" on them. But it is assuming that standard baselines will evolve and change over time as you suggest. We expect that over time, realistic baselines will be proposed for use and possibly required for use by customers or goverment agencies if they are not adopted voluntarily. The Working Group will be developing non-normative documentation on how to create baselines." 

@@ work on HOW TO CREATE BASE doc 

5/25/06 WG Teleconf Call 
http://www.w3.org/2006/05/25-wai-wcag-minutes.html 
keep LC-531 open,<put on> hold for more comments 

ACTION: David, Michael, Bruce, Loretta, Cynthia to look at alternate formations for level 3 conformance due close of comments [recorded in http://www.w3.org/2006/05/25-wai-wcag-minutes.html#action03 <http://www.w3.org/2006/05/25-wai-wcag-minutes.html> ]

Comment LC-565
Sort Terms: 4.1.1 and BASELine related --- NewSC for 4.1 deprecated features
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: ensure-compat <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

Guideline 4.1 is concerned with ensuring compatibility with current and future user agents including assistive technologies. However, within WCAG 2.0 there does not appear to be any requirement to avoid the use of deprecated W3C technologies. Also there is no explicit indication that layout tables should not use structural markup for the purpose of visual formatting. It appears that many of the issues relating to the use of tables are intended to be covered by SC 1.3.1, however the HTML techniques relating to this SC in the \"Understanding WCAG 2.0\" document make no reference to the inappropriate use of table markup. 

Proposed Change: 

I suggest Guideline 4.1 contain a Level 1 Success Criteria which reads, \"When a table is used for layout, it does not use structural markup for the purpose of visual formatting.\" 

I suggest Guideline 4.1 contain a Level 2 Success Criteria which reads, \"Deprecated features of W3C technologies are not used.\"
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Submitted by Team A 5/23/06 

Put on hold, 5/25/06 telecomm 

{Partial Accept} 
The Working Group agrees that this should be a Failure. However 1.3.1 is the proper place for this and this is covered by two HTML failures under 1.3.1 titled "Failure of SC 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables" and "Failure of SC 1.3.1 due to using structural markup in a way that does not represent relationships in the content". 

RE Deprecated W3C technologies: [The Working Group assumes this refers to deprecated features rather than deprecated technologies.] Not all deprecated features are accessibility issues or problems for AT. A blanket prohibition is therefore not felt to be appropriate. Are there particular deprecated features that you know to be a problem for AT that are not covered elsewhere in the guidelines." 

5/25/06 WG Teleconf Call 
http://www.w3.org/2006/05/25-wai-wcag-minutes.html 
PUT ON HOLD 

Survey comments: http://www.w3.org/2002/09/wbs/35422/TEAMaMAY25/results#xLC565 <http://www.w3.org/2002/09/wbs/35422/TEAMaMAY25/results>  

Comment LC-588
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Martin Stehle <pewtah@snafu.de>
Comment Type: general comment
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Choosing baseline technologies)
Comment:
Comment (including rationale for any proposed change): 

The concept of baselines is misleading. One could define "AVI, TXT" as a valid baseline to tell his/her video collection "conform to WCAG 2.0" and can communicate the site as "accessible". To me this is senseless. 

Proposed Change: 

If there is a baseline, there should be a minimal requirement, at least for "HTML".
Status: open
Working Group Notes: [TEAMA] [HOLD] Hold this til all the Baseline comments come in and deal with them all together.

Comment LC-638
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: accessible-alternatives-plugins <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for proposed change): 

Maybe the user needs to know what the baseline is. Then if they really need this content they can find a user agent that can supply it. 

Proposed Change: 

Add at level one 
The user can access what technologies are included in the baseline, even without using baseline technologies
Status: open
Working Group Notes: [TEAMA] [HOLD] 

This information would need to be in a conformance statement. And it would have to use content in some baseline, almost by definition.

Comment LC-643
Sort Terms: not-in-baseline, baseline
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: accessible-alternatives-all-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for proposed change): 

quote " At Levels 1 and 2, WCAG conformance is only required for technologies inside the baseline. Technologies outside the baseline need not conform," ah.. and then it is clarified 

I do no think that is what you mean but people will misquote that to think that if they set a baseline of html, then there site is conforment because everything is in flash which is outside baseline. 

Proposed Change: 

change 4.2 wording 

Content implemented using technologies outside of the chosen baseline satisfies all Level 1 and Level 2 requirements supported by the technologies even when accessible alternatives using technologies inside the baseline are provided.
Status: open
Working Group Notes: [TEAMB] [HOLD] Action Item undertaken by Gez on this issue. 
Note - this may not be possible for technologies outside the baseline (which may be why they are outside the baseline). 
[SM] Perhaps a compromise would be "Content implemented using technologies outside of the chosen baseline satisfies all Level 1 and Level 2 requirements where supported by/where possible to implement using those technologies. 
[AL] if all content uses technology outside of the baseline, then no content can possibly meet WCAG because nothing is within the baseline. There is no compromise needed because this is about proper understand of how to use baseline. A good understanding baseline document will do the trick.
Resolution Working Notes - Unapproved:
Action Item undertaken by Gez on this issue. 
Note - this may not be possible for technologies outside the baseline (which may be why they are outside the baseline). 

Comment LC-646
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Matthew Magain <matt@opinios.com>     Affiliation: none
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

I disagree strongly with the concept of having a baseline. By NOT specifying a minimum technology set of HTML, then site owners are essentially given free range over choosing to only support the technology that they want, regardless of whether any accessible user agent for rendering that technology is in existence. This goes against the grain of the W3C\'s underlying philosophy of making Web content available to anyone. If the W3C want WCAG to be future-proofed, it should encompass existing technologies, and evolve with version 3.0 when new technologies become in use, not pre-empt them through by being ambiguous. 

Proposed Change: 

That WCAG 2.0 specify HTML as a minimum technology for making information accessible. That existing technologies be incorporated into WCAG using specific guidelines for current user agents.
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-648
Sort Terms: baseline 4.1.1
Document: WCAG 2.0 Guidelines
Submitter: Andrew Harris <andrew@woowoowoo.com>
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

Thoroughly disappointed and disillusioned with WCAG 2. 

I had hoped all the \'problems\' would be ironed out by this stage, but it seems that they have just become more ingrained. 

To be fair, I can see where you\'re heading - that being specific about things like current technologies runs the risk of being outdated in the near future. I can see why you are using abstracted terms like \'Baseline\' and not further emphasising Validation, but in practice it is not going to work. 

Why? 

One of the biggest problems I had with WCAG 1 was the non-measurable stuff. You could run your page through a software checker and it would return some results, but others you had to \'interpret\'. It took a lot of training and practice to get people to understand what these guidelines meant. Most found it too hard. Consequently, the vast majority of people/companies think accessibility is simply \'alt\' text for images. 

What the accessibility world is really crying out for is a measurable, detectable, practical standard. One that can be used in day to day work without a great deal of knowledge or training. 

WCAG 2 seems to have gone in the other direction. Introducing more jargon, less certainty, more difficulty... it is not going to work. 

Baseline 

As an example, the idea of a Baseline has merit. In a perfect world, it would probably work, technologies would be designed up to acceptable standards and companies would work to improve those standards. In reality, this is rubbish. Without a hurdle, no-one will spend money to achieve a reasonable level of accessibility unless they are forced to do it. You cannot leave the \'stating of baselines\' totally in the hands of the provider, or there will be no incentive to improve. Quite apart from that, setting a baseline will require a level of expertise that most providers simply do not have and probably do not wish to acquire. 

If you are wedded to the idea of baselines, then the only way it will work in the \'real\' world is if you set \'minimum baselines\' in those media and channels for which there are w3 or other accessible standards. This would ensure that there is always a point of reference to turn to. These \'minimums\' might be documents separate from WCAG, so needn\'t compromise its longevity, but could be easier to update as technologies change - in fact, improving the relevance of WCAG 2 over time. 

Validity 

As a trainer and advocate in my workplace for webstandards and accessibility, one of the most effective tools in aiding understanding is the online validator. The W3 HTML validator or accessibility \'checkers\' like Bobby or \"Cynthia Says\"... it doesn\'t matter, the user checks their page and gets some feedback about obvious problems. Of course if a page is not valid code, it often can\'t be checked, so one of the most valuable and visible checks on a page is rendered useless. 

As I understand it, Valid Code is not recieving the emphasis I believe it should. There are provisions for validating \'Web Units\', but some uncertainty about whether these will be regarded as \'essential\' to any overall level of success. 

I always tell people that a valid page is a big first step towards an accessible page, in fact, I think it is essential and should definitely be right up there as a priority 1 checkpoint - or whatever they\'re called now ;-) Validity is measurable, and helps create semantic, well structured data. Make it a minimum! 

Proposed Change: 

1) Consider publishing accompanying baseline documents to ensure there is a clear, measureable expectation for levels of conformance. 

2) Increase the emphasis of validation to published/accepted/measurable standards
Status: open
Working Group Notes: [TEAMA]baseline 
[HOLD]

Comment LC-649
Sort Terms: baseline scoping
Document: WCAG 2.0 Guidelines
Submitter: Geoff Freed <geoff_freed@wgbh.org>     Affiliation: WGBH National Center for Accessible Media
Comment Type: substantive
Location: conformance-claims <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 


Regarding baseline: I\'ve read and re-read all the documentation about baseline and I just don\'t understand it. It seems like baseline is a great way to blame the victim: an author can claim that a user\'s accessibility problems are, in fact, strictly his or her problems. The answer to any complaint is, \"That\'s not in my baseline, so I didn\'t test for it.\" The only way it might be useful is in a closed environment, such as an Intranet, where authors really do know what technologies users have. And the fact that baseline requires an entirely separate explanatory document indicates to me that it is *far* too complex to be useful. 

Regarding scoping: \"Scoping\" of a conformance claim introduces a perfect loophole for anyone who simply doesn\'t want to do the work required to make things accessible. Take Example 2: \"A site has a collection of videos for which it is not required to and does not want to claim accessibility.\" \"Not required?\" But aren\'t captions required by SC 1.2? Is \"I don\'t want to\" now a valid excuse? Further, Example 2 states that a scoped conformance claim of \"I don\'t want to caption/describe the videos\" is valid as long as the videos are played only in a standalone player. But if the videos are embedded in a Web page, suddenly they *must* be made accessible...? I don\'t see the distinction. Video is video. If I\'ve created an on-line physics curriculum that uses a standalone player to show an entire semester of lectures, you\'re saying that these videos do *not* have to be accessible if I \"scope\" my conformance claim to exclude these materials? 


Proposed Change: 


1. Delete baseline. 
2. Delete scoping.
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-652
Sort Terms: baseline cognitive LevelAAA
Document: WCAG 2.0 Guidelines
Submitter: Lars Ballieu Christensen <lbc@sensus.dk>     Affiliation: Sensus ApS - European Accessibility Consultants
Comment Type: substantive
Location: 0Free(none selected) <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

As a practitioner with 10 years experince in advising site owners and developers on how to develop web sites that are accessible to the widest range of users using the widest range of technilogies, I find the following the following issues in WCAG2 highly problematic: 

The introduction of a technology baseline; the concept of a baseline is in my opinion in itself in direct conflict with the idea of creating inclusive solutions; I fear that the baseline will be used widely to formally pass accessbility tests by omitting all potentially tricky technologies from the baseline. In my opinion, the baseline is a mistake that should be removed from the document. If the aim is to promote an inclusive envisonment, the whole notion of accepting lower standards in, say, private intranets is absurd as it will preent people with special needs to work in these environments. 

The document is still heavily biased towards the visually impaired. By and large, other groups of people with special needs are in practice omitted from the substance of the guidelines. These include, but are not limited to, the deaf, dyslexic, people with reading difficulties, and the cognitively disabled. The standard remedy of demanding that all non-textual information also be represented as textual information is simply not enough. 

The idea of granting triple-A conformance status to a web site if it passes half (randomly selected?) the level 3 success criteria does not make sense. It suggests either that the level 3 success criteria are irrelevant to the general accessibilily or that it is more important to be able to pass the test than to comply with the level 3 success criteria. 

Proposed Change: 

1. Omit the concept of a baseline from the document. 

2. Accommodate other - and in many cases much larger - user groups than merely the visually disabled. Complement the text alternative requirement with requirements for other alternatives including simplified text and sign language. 

3. Decide whether and which of the level 3 success criteria are important. Leave out the unimportant and make the rest mandatory for gaining triple-A conformance status.
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-737
Sort Terms: Simpler WCAG, Baseline, Scoping, levels , accum
Document: WCAG 2.0 Guidelines
Submitter: Rick Hill <<rrhill@ucdavis.edu>>
Comment Type: general comment
Location: 0Free(none selected) <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

I for one do not have the time to read all of the WCAG 2 documents in 
the 30-day review time-frame that has been provided. Having read Joe 
Clark\'s comments at http://www.alistapart.com/articles/ 
tohellwithwcag2 and http://joeclark.org/access/webaccess/WCAG/ as 
well as postings at http://technorati.com/tag/WCAG2. If only 10% of 
the issues that are identified on these sites are true, then WCAG 2 
is NOT ready for prime time. If it is true that web pages that meet 
WCAG 2 need not be valid HTML/XHTML then that is utterly contrary to 
the concept of web standards and is a HUGE step in the wrong 
direction. I would hope that the WCAG 2 standards build on and 
enhance the standards of WCAG 1 that many of us have worked hard to 
promote in our work places. Other comments: 


1. The provision to define a technology as a “baseline,” is not 
useful unless there is either some way to make sure that the 
technology is inherently accessible and/or that there are provisions 
to provide alternate technologies to provide accessible versions of 
the content where the baseline technology fails. 

2. Being able to define entire directories of your site as off-limits 
to accessibility should only be allowed when the content cannot be 
made accessible. 

3. The compliance \"levels\" do not seem to have become simpler. 
Perhaps more cryptic. And I would like to see a move toward 
enforcible standrads rather than merely guidelines (as in what was 
attempted with the language of 508). 

4. You can’t use offscreen positioning to add labels (e.g., to forms) 
that only some people, like users of assistive technology, can 
perceive. Everybody has to see them. 

5. Source order must match presentation order even at the lowest 
level ... why? 

6. It would seem that WCAG 2 proposes maintaining separate accessible 
and inaccessible versions of the same pages. 

Again, I wish I had the time to drop my day-to-day tasks, stop 
pushing for web standard design in our environment (including 
accessible design) and devote my time to being able to read an 
comment on the final WCAG 2 draft. However, the comments from folks 
in the know and in the filed have not been encouraging. So, I 
decided to drop a line and express my concerns and fears. SInce it 
took years for the committee to reach this point, it would seem a 
slightly longer review period to allow comment is in order. And one 
would hope, if the public (those folks working to promote accessible 
design) have real concerns about the standard, then the committee 
needs to regroup and address those concerns, not publish a set of 
guidelines that will not be accepted or used in practice ... 

Proposed Change:
Status: open
Working Group Notes: [EDITORZ] [HOLD] 

The numbered items in this comment were broken out into separate items. (LC-829 through LC-834).
Resolution Working Notes - Unapproved:
Related Issues: 
829, <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=829,>  
thru, <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=thru,>  
834 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=834> 


Comment LC-750
Sort Terms: BASELINE not-in-baseline, conformance
Document: WCAG 2.0 Guidelines
Submitter: Eric Hansen <ehansen@ets.org>     Affiliation: Educational Testing Service
Comment Type: substantive
Location: accessible-alternatives-plugins <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: 

This presumably applies to technologies even beyond those explicitly listed as being used, right.? Needs to be clarified 

Proposed Change:
Status: open
Working Group Notes: [TEAMA] [HOLD] 
Does anyone have any suggestions for making this clearer in the success criterion? 

Discussed at Team B meeting on 6-27-2006. Decide to incorporate comments from Team B Survey results of June 22 (http://www.w3.org/2002/09/wbs/35422/teamb062206/results) into the database. 

Because of Michael Cooper and Becky Gibson concernes and comments decided to add keyword "not_in_baseline" so it might be reviewed as such. 

OUTCOME from July 29 Full WCAG Discussion: Resolution: 750 put on hold under not in baseline 
(http://www.w3.org/2006/06/29-wai-wcag-minutes.html)
Resolution Working Notes - Unapproved:
@@ partial accept 

@@Response to Commenter: 

This success criterion applies to any use of technology that is not in the chosen baseline. The list of the technologies that are "used but not relied upon" is an optional component of a conformance claim, and this success criterion is not limited to technologies that appear in a conformance claim. 

Comment LC-751
Sort Terms: CONFORMANCE & BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Eric Hansen <ehansen@ets.org>     Affiliation: Educational Testing Service
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

Complete revision of conformance section proposed at 
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/att-0042/S3-conformance-EGH-05Jun2006-01.doc 

Proposed Change:
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-807
Sort Terms: baseline not well explained
Document: WCAG 2.0 Guidelines
Submitter: Robert Whittaker <robert.whittaker@gmail.com>
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

The baseline concept is not wery well explained in the guidelines, and is never really defined properly. External docuemnts should not be relied upon to define key conepts. 

Also, the descriptive use of \"technologies\" without further explanation is not good when you\'re really refering to data formats, markup and scripting languages (rather than software). 

Proposed Change: 

Provide a clearer definition / explanation of the baseline concept in the guidelines themselves. 

Provide at least one example of a baseline specification (perhaps with the examples under the \"Who sets baselines?\" heading).
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-809
Sort Terms: 4.1.1 (parsed unambiguosly) ALSO BASELINE IMPLICATIONS
Document: WCAG 2.0 Guidelines
Submitter: Robert Whittaker <robert.whittaker@gmail.com>
Comment Type: substantive
Location: ensure-compat-parses <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

The definition of "parsed unambiguously" is rather ambiguous, and the gudelines themselves don't explain what is required. Does this mean a particular UA must have the same structure on each parsing of the same page (which only requires that UA behave deterministically) or that *all* UAs get the same structure (which is impossible without having all UAs store their data in the same way)? 

For accessibility, it is vital that data be presented in a manner that complies with a published standard - otherwise how do UA-makers, or people who want/need to write their own parsing tools know what to expect and how to handle the data. With a multiplicity of UAs, the only sensible interpretation of "parsed unambiguously" is that the data stream complies with a published standard. That being the case, the guidelines should state this. 

Proposed Change: 

Simplify and strengthen the guidelines by removing the concept of "parsed unambiguously", and replace it with a guideline that says that data formats used must comply with a published specification (to be referenced in the baseline). 

(Of course this may be an author-published one - though authors should be discouraged from doing so.)
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-812
Sort Terms: Baseline conformance
Document: WCAG 2.0 Guidelines
Submitter: Sailesh Panchang <sailesh.panchang@deque.com>     Affiliation: Deque Systems Inc
Comment Type: substantive
Location: conformance-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

Conformance and Definition of L1, L2 and L3 for success criteria 
For L1 and L2, the chief distinction is between ‘minimum level’ and ‘enhanced level’ of accessibility as the second factor (reasonably applies to all Web content) is common. 
I contend that the terms ‘minimum’ and enhanced’ cannot be viewed in a vacuum without a context. For a user with particular kind of vision impairment (VI), ability to manipulate background / foreground colors may provide minimum accessibility and ability to manipulate text size may provide enhanced level of accessibility. For another person with VI, both or just the second one may be needed to provide minimum accessibility. 
Question: So in what context is the level determined? 


Proposed Change: 

Integrate the baseline into the definition of L1, L2 etc. This will mean that SC at L1 exploit all accessibility features available in the baseline technology and this provides the necessary context. 
In doing so the WG will be able to justify its statement: ‘WG believes that all success criteria of WCAG 2.0 are essential for some people’ and yet not say that one checkpoint is more important than another like in WCAG 1.0. 

At present obviously an SC at L1 is more important than one at L2 because the former is supposed to provide ‘minimum accessibility’ and a developer will be encouraged to implement these first.
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-880
Sort Terms: BASELINE RELATED BUT ACTUALLY CONFORMANCE
Document: WCAG 2.0 Guidelines
Submitter: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>     Affiliation: DocArch - K.U.Leuven
Comment Type: substantive
Location: conformance-claims <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: substantive 
Comment (including rationale for proposed change): 

Item 2 of optional components of a conformance claim appears to add little useful information to a conformance claim because it is a subset of the baseline information (item 5 of required components of a conformance claim). It seems more useful to me to state which technologies in the baseline are not used or relied upon. 

Proposed Change: 

Remove item 2 of optional components of a conformance claim or replace it with a list of technologies that are in the baseline but not relied upon.
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-889
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Monica Løland, The Danish Council of Organisations of Disabled People (DSI) <mol@handicap.dk>     Affiliation: The Danish Council of Organisations of Disabled People (DSI)
Comment Type: general comment
Location: conformance <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: general comment
Comment (including rationale for proposed change):

WCAG 2.0 introduces the new term baseline in the conformance section which is difficult to understand. 

Proposed Change:

The introduction of the conformance section in WCAG 2.0 should be provided with a clear explanation of what a baseline is and how it should be used. If the term baseline is not understood it might be misused.
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-902
Sort Terms: BASELINE User Agent
Document: WCAG 2.0 Guidelines
Submitter: Giorgio Brajnik <giorgio@dimi.uniud.it>     Affiliation: University of Udine, Italy
Comment Type: substantive
Location: conformance <http://www.w3.org/TR/WCAG20/complete.html>  (Technical Assumptions)
Comment:
the def of user agents include assistive tech, and that is clear. But what do you mean with “... as long as accessible user agents support the technology”? that a website useing a tech. not supported by any accessible user agent could never be claimed to be wcag20 conformant? also the clause “...user agents including AT” is confusing. If AT is already a user agent (or part of it), then the clause is not needed. But if you want to say that the technology should be supported by at least an accessible user agent that is compatible with at least one AT, you should say it clearly.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] The commenter points out that we should a have clearer line of thinking about user agent and baseline. There needs to be a clean decision if the author is responsible for determining if an “accessible user agent” exists for the baseline content or just to fulfill the sc of the baseline and not worry about user agent(s), particularly AT. Current language is unclear. Propose to remove language of "accessible user agent". It is a loaded term and highly contextual. Issue may be closed upon available of better baseline document.

Comment LC-908
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Giorgio Brajnik <giorgio@dimi.uniud.it>     Affiliation: University of Udine, Italy
Comment Type: substantive
Location: glossary <http://www.w3.org/TR/WCAG20/complete.html>  (Baselines)
Comment:
the problem is that in the conformance statement one needs to refer to a baseline, but wcag20 does not prescribe how a baseline is defined and what kind of mechanisms it should include. Could a conformance statement be referring to a baseline defined solely as “netscape 4 on windows 95”? would this be a valid conformance claim?
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] Propse answer: "Browsers or user agents are not proper elements in the baseline statement." But we should hold until better baseline documentation is available

Comment LC-951
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca>     Affiliation: Government of Canada
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
The baseline concept is still difficult to comprehend in real-world terms, in spite of progressive reworkings of the baseline explanation in "About Baselines and WCAG 2.0" and the less comprehensible "Conformance" section in W2.
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-953
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca>     Affiliation: Government of Canada
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  (Quick Reference)
Comment:
Unfortunately, the selection form requires (or presupposes) a firmer grasp of the baseline concept than many of us have yet been able to achieve. The resulting view if a technology is used but in or not it the baseline is not as clear as we think it ought to be. 

Proposed Change: 

If feasible, it would be nice if any set of selections also generated a corresponding example of a conformance statement (metadata ready) and a verbal example of what that baseline means and how to interpret it (similar to the examples in "About Baselines and WCAG 2.0").
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-997
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Judy Brewer <jbrewer@w3.org>     Affiliation: W3C/WAI, on behalf of the Education and Outreach Working Group
Comment Type: editorial
Location: conformance-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: editorial
Comment (including rationale for proposed change):

Each time EOWG discusses the baseline concept, there are a number of concerns raised about potential mis-uses of baseline, and people can think of a number of scenarios of potential abuse. 


Proposed Change:

EOWG recommends adding a much clearer statement of the intent of baseline into the WCAG 2.0 TR document, so that this can be referenced in any debates about potential mis-uses or abuses of baseline. EOWG would be happy to give feedback on draft explanations of the intent. 
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-998
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Judy Brewer <jbrewer@w3.org>     Affiliation: W3C/WAI, on behalf of the Education and Outreach Working Group
Comment Type: editorial
Location: conformance-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: editorial
Comment (including rationale for proposed change):

In the discussion of baseline and conformance, it seems that there is potential for misuse of baseline (e.g. authors might be able to just declare their own level of technology). The actual/potential audience, not just perceived/target audience or what developers wish they could reply on, should define baseline. 


Proposed Change:

EOWG recommends that the WCAG WG re-consider the following strategies: to give guidance on what is a realistic baseline for most Web sites today, W3C should publish a \'reasonable/realistic\' baseline recommended for a general audience, outside of the WCAG 2.0 normative document, with an explanation about why the particular baseline is recommended; and it should update this recommended baseline annually or periodically. 
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] The quick reference partly addressed this issue. Propose to close with partial accept upon publication of improved baseline document.

Comment LC-1007
Sort Terms: REORGANIZE - MOVE OUT OF WCAG, BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Judy Brewer <jbrewer@w3.org>     Affiliation: W3C/WAI, on behalf of the Education and Outreach Working Group
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: general comment 
Comment (including rationale for proposed change): 

EOWG approved the following comments prepared by Shawn Henry. Background first, on distribution of material among WCAG 2.0 and supporting documents: 

1. WCAG 2.0: Purpose is a stable reference for policies, etc. Keep it as simple and succinct as possible. Clearly point to other documents for important information, such as more info on baseline (which is done in current draft). Leave out any historical info and such (take out some of what is there now). 

2. Checklist: Purpose is quick list for people who already know WCAG 2.0 and just need to check off that they’re remembering everything when doing an evaluation, for example. [Other common uses?] (Note that it’s *not* useful as an overview for newbies.) 

3. “Understanding” [or other title]: Purpose is *the* document that most people will use most of the time. Note that since all the guidelines and success criteria are in here I think few people will even look at /TR/WCAG20. [Do you agree?] 
* @@ 

4. Techniques: Purpose is details for implementing. Assume developers are the only target audience. [correct?] 

5. Overview (w3.org/WAI/intro/wcag20): Purpose is simple, friendly, directive front door to WCAG 2.0 docs. I think almost all references to WCAG 2.0 (for example, links in other WAI Resources, slides, and such) should point to this overview. 

6. [About Baselines]: Eliminate this document. Put the pertinent information about baselines in “Understanding”, as there’s no reason to send people to yet another document for this information. The non-pertinent info that’s there now could go in 7 below. 
7. [something like Background, or WG Notes, or History, or QA or”¦]: Purpose is to communicate reasons why things were done, address some concerns or issues, and such. For example, move to here most of the “Background” section from About Baselines, “Why wasn't UAAG used as baseline?”, and why 2.0 Levels different from 1.0 Priorities (currently in WCAG20 Conformance). 

8. [Application Notes] Purpose is to help developers working on a specific thing, such as images, links, forms, data tables. (Brief description is under http://www.w3.org/WAI/intro/wcag20.php#related <http://www.w3.org/WAI/intro/wcag20.php> ) Note that I think these should cover just the basics, and point back to "Understanding" & "Techniques" for the more complex issues. 

9. [Plain-Language Version WCAG 2.0 "101" WCAG 2.0 "for Dummies" WCAG 2.0 Intent] Purpose is for the average person to be able to understand the basics of WCAG 2.0. I imagine taking each guideline and success criteria and providing it in an understandable way. Perhaps this is mostly pulling out the information from the “Intent” section of "Understanding". Note that this is problematic as it would have to be carefully and clearly positioned, since it would *not* cover all the issues. 

10. [Quick Tips] Purpose is something short that touches on the basics to help people get started on accessibility " to fit on a business-card-sized handout. 

Proposed Change: 
The main change from what is in the current WCAG 2.0 documents and above is moving out of the main /TR/WCAG20 document Comparison with WCAG 1.0, explanatory examples, and other details. In addition to simplifying the normative doc, this puts the explanatory information where it can be updated to reflect changes over time as necessary. It also limits the need for repetition across documents (e.g., now some information in /TR/WCAG20 Conformance is repeated in About Baselines, and not at all in Understanding). I think it also would ensure that people don’t miss important information. (Since it becomes clear that the /TR/WCAG20 only contains the standards, and all other info is in Understanding.) 

Based on above, I propose moving the following sections out of /TR/WCAG20 Conformance: 

I. Move into a new "Baselines" section of "Understanding": 
a. Under Who sets baselines?: 
" 
... 
There are several reasons for this. First, what is appropriate in a baseline may differ for different environments. For example, in the case of content that will be viewed only by employees of a particular company, it may be possible to assume that user agents support more advanced technologies if the company provides the necessary user agents (including assistive technology) to all employees. For public Websites, however, a more conservative level of technology may be all that can be reasonably assumed. Baselines may also vary by jurisdiction. Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time. 

Some examples of baselines: 

Example 1: A government site that provides information to the public. A government agency publishes information intended for the general public. The specified baseline includes only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release. The government periodically changes the baseline it requires for developers of public sites to reflect the increasing ability of affordable user agents (including assistive technology) to work with newer technologies. 

Example 2: A particular government provides high level accessible user agents to all citizens who need them. A government provides all citizens with user agents that support newer technologies. The government is thus able to specify a baseline that includes these newer technologies for all of its Websites for its citizens since the government can assume its citizens' user agents can handle the technologies. 

Example 3: A private intranet. An organization (public or private) provides its employees with the information technology tools they need to do their jobs. The baseline for intranet sites used only by employees includes newer technologies that are supported only by the user agent that the organization provides for its employees. Because the company controls the user agents that will view its internal content, the author has a very accurate knowledge of the technologies that those user agents (including assistive technologies) support. 

Note: In the examples above, the baseline is not specified in terms of specific user agents but rather in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies). 
" 

b. All of Examples of conformance claims: 
" 
Examples of conformance claims 

Example 1: On 23 March 2005, http://www.wondercall.example.com conforms to W3C's WCAG 2.0, Conformance Level A. The baseline for this claim is XHTML 1.0. The specification that this content "relies upon" is: HTML 4.01. The specifications that this content "uses but does not rely on" are: CSS2, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4. 

Example 2: On 5 May 2006, "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to W3C's WCAG 2.0. Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/Baseline#1-2006.html <http://UDLabs.org/Baseline> . The specification that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video. The specifications that this content "uses but does not rely on" are: JavaScript 1.2, CSS2. 

Example 3: On 21 June 2007, http://example.com/nav and http://example.com/docs conform to W3C's WCAG 2.0, Conformance Triple-A. The baseline is ISA-Baseline#2-2007 at http://ISA.example.gov/Baselines/BL2-2007. The specifications that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpeg, png. " The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html. 

" 
c. All of Content that conforms to WCAG 1.0: 

" 
Content that conforms to WCAG 1.0 

This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999. 

The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to the (draft) Mapping between WCAG 1.0 and the WCAG 2.0 Working Draft. 

Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0." 

" 
II. Move to Document #7 [Background, or WG Notes, or History, or Q&A] above: 

"This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria under Levels 1, 2, and 3 as described above. Note that even conformance to all three levels will not make Web content accessible to all people."
Status: open
Working Group Notes: [EDITORZ] [HOLD] 

Refer to Clarifications note from Shawn: 
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0270.html


Comment LC-1014
Sort Terms: BASELINE REORGANIZE
Document: WCAG 2.0 Guidelines
Submitter: Shawn Henry <shawn@w3.org>     Affiliation: W3C WAI
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: general comment 
Comment (including rationale for proposed change): 

Suggest re-focusing documents 

Proposed Change: 


Rough thoughts on content and positioning of the different WCAG 2.0 documents and change suggestions below (revised somewhat since < http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0091.html> <http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0091.html%3E> ;). 
Note: Some of the changes below have already been discussed within the WCAG WG and are planned, and some are my own ideas that have not yet been discussed and are likely to continue to evolve. 
High level summary: 
- Take all but the minimum out of the /TR/WCAG20 pages, especially moving out a lot of the text from Introduction and Conformance, and moving Checklist and Comparison (“mapping”) Appendices 
- Make /TR/WCAG20 the formal reference only, and direct all informative pointers to the Overview doc, and from there to the UI (next point) 
- Create a user interface (UI) to access the “atoms” of Understanding and Techniques as needed, rather than the primary interaction being through /TR/WCAG20 to the middle of a large docs 
Details: 
1. /TR/WCAG20: Purpose is formal Technical Specification/W3C Recommendation/Standard that is stable and referenceable. Keep it as simple and succinct as possible. Include only the minimum needed for the actual technical specification. Clearly point to other documents for important information, such as more info on baseline. 
Note: Encourage all general references to WCAG to go to the Overview doc <www.w3.org/WAI/intro/wcag20>, and only formal references in policies and such to point to /TR/WCAG20 (and there to also point to the Overview doc as informative). 
Changes & Rationale: 

The main change I suggest is moving out of the main /TR/WCAG20 Introduction and Conformance pages the Comparison with WCAG 1.0, explanatory examples, and other details. In addition to simplifying the normative doc, this puts the explanatory information where it can be updated to reflect changes over time as necessary. It also limits the need for repetition across documents (e.g., now some information in /TR/WCAG20 Conformance is repeated in About Baselines). I think it also would ensure that people don’t miss important information (since it becomes clear that the /TR/WCAG20 only contains the standards, and all other info is in Understanding). 

* Move all information explanatory information not necessary for the technical specification, such as what is listed under “Based on above, I propose moving the following sections out of /TR/WCAG20 Conformance:” in http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0091.html 

* Move “Appendix B: Checklist”. Now that the guidelines are so nicely free of extraneous information (i.e., moved extra information that was within the guidelines themselves in WCAG 1.0 to “Understanding 2.0”), this checklist is not needed as part of /TR/WCAG20. Now http://www.w3.org/TR/WCAG20/appendixB.html pretty much equals http://www.w3.org/TR/WCAG20/guidelines.html and is therefore redundant. (See more with #@@ below) 

* Move “Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0” from the formal /TR/WCAG20 doc and make it a supporting doc. (See above for rationale, including that it can be more easily edited if outside of the /TR/WCAG20 Recommendation.) 

2. Overview </WAI/intro/wcag20>: Purpose is clear, friendly, directive intro and map to WCAG 2.0 docs. 

Note: Encourage all general references to WCAG to point to the Overview doc www.w3.org/WAI/intro/wcag20 (and only formal references in policies and such to point to /TR/WCAG20). 

Changes: 

* Edit to be more effective in this purpose. (Action, Shawn) 

3. WCAG 2.0 Quick Reference www.w3.org/WAI/WCAG20/quickref/: List of requirements and techniques, customizable to make as short and focused as needed for specific situations. This may evolve into the primary tool/doc that most people use most of the time as the main page to WCAG 2.0 information. 

Changes: 

* Consider additional customization options, such “[ ] Show Common Failures” to be able to turn them off and shorten the doc. 

* Perhaps design this to also replace the Checklist, e.g. by adding: 

[ ] Show Techniques 

[ ] Include Comment column and checkbox 

* Evaluate usability for possible UI improvements. 

4. [Checklist </TR/WCAG20/appendixB.html>]: Purpose is quick list for people who already know WCAG 2.0 and want a short list to check off that they’re remembering everything when doing an evaluation, for example. [Other common uses?] 

Changes & Rationale: 

See under #1 about it being redundant with http://www.w3.org/TR/WCAG20/guidelines.html. The WCAG 1.0 Checklist was very useful as a quick reference and overview of 1.0 guidelines for newbies. This WCAG 2.0 Checklist is not. We already made a Quick Reference, and we might make something for newbies. 

I wonder if we want to provide this 2.0 Checklist at all? Perhaps the benefit some people will get from it is not worth the complication of having yet another WCAG 2.0 document? If we do keep it, I think it should be carefully positioned for what it is and what it is not, and not detract from the other documents that might meet most needs better. 

5. “Understanding” [or other title]: Purpose is to provide details for people who want to understand the guidelines in depth. 

Changes & Rationale: 

* Consider changing title. (I think others have provided rationale and suggestions.) 

* Move into this document details on Conformance and Baseline. 

* Add brief explanations of the Principles. 

* Add pointer to Overview doc near front. 

* Develop UI that lets people easily get the “atoms” of info that they want at a time, and navigate between atoms here, from Techniques, and other related documents as appropriate. 

6. Techniques: Purpose is details for implementing. Developers are the main target audience. 

Changes: 

* Develop UI that lets people easily get the “atoms” of info that they want at a time, and navigate between atoms here, from Understanding, and other related documents as appropriate. 



7. [Application Notes] Purpose is to help developers working on a specific thing, such as images, links, forms, data tables. (Brief description is under http://www.w3.org/WAI/intro/wcag20.php#related <http://www.w3.org/WAI/intro/wcag20.php> ) Note that I think these should cover just the basics, and point back to “Understanding” & “Techniques” for the more complex issues. 



8. [Web Accessibility Basics] (document not yet defined) Purpose would be for the average Web developer to be able to understand the basics of Web accessibility under WCAG 2.0. An easy-to-understand list of what one needs to do for a simple site with HTML and CSS. 

(Acknowledge that this would have to be very carefully and clearly positioned, since it would not cover all the issues.) 

9. [Quick Tips] Purpose is something short that touches on the basics to help people get started on accessibility – to fit on a business-card-sized handout. 

10. [About Baselines]: Eliminate this document. Put the pertinent information about baselines in “Understanding”, as there’s no reason to send people to yet another document for this information. The non-pertinent info that’s there now could go in 11 below. 

11. [something like Background, or WG Notes, or History, or FAQ, or…]: Purpose is to communicate reasons why things were done, address some concerns or issues, and such. For example, from About Baselines move to here most of the “Background” section and “Why wasn\'t UAAG used as baseline?”. 

12. [Transition from WCAG 1.0 to WCAG 2.0] (document not yet defined) Not sure if a single document, or series of documents? 

Changes: 

* Move “Comparison of WCAG 1.0 checkpoints to WCAG 2.0” from /TR/WCAG20 appendix to here 

* Move why 2.0 Levels different from 1.0 Priorities (currently in WCAG20 Conformance) to here
Status: open
Working Group Notes: [EDITORZ][HOLD] 

Comment LC-1028
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - From reading the Baseline documents, it appears that if a baseline technology does not have particular functionality (for example, the ability to navigate using only the keyboard), then the site can still be compliant with WCAG2 (but obviously not accessible). I think it is reprehensible that the main body advocating accessibility is about to release a set of guidelines that patently allow inaccessible web sites. 

Proposed Change: 

Remove the baseline theory, or allow only UAAG compliant programs in baseline.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
BASICALLY THE SAME AS 1029 BUT 1029 IS LONGER COMMENT. 
[AL] Commenter does not understand baseline. Propose to reject upon publication of better baseline document.
Resolution Working Notes - Unapproved:
Related Issues: 
LC-1092 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-1092> 


Comment LC-1029
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - From reading the Baseline documents, it appears that if a baseline technology does not have particular functionality (for example, the ability to navigate using only the keyboard), then the site can still be compliant with WCAG2 (but obviously not accessible). This acts as a disincentive for big corporations to develop accessibility features. Developers want things to be easy - it's a lot easier to click "Print to PDF" in a Word document than it is to tag a PDF. So what is to stop Adobe (sorry Loretta!) superceding their PDF technology with a new "SDF" technology that has no accessibility features? In that case it would be a lot easier for a person to create a WCAG2 compliant SDF document than it would be to create a WCAG2 compliant PDF document. In another example, if someone had CSS in their baseline then it would be WCAG2 compliant to use CSS markup to highlight a specific word without having an HTML alternative, and which would not be able to be interpreted by a screen reader 

Proposed Change: 

Remove the baseline theory, or allow only UAAG compliant programs in baseline. If I have misinterpreted the baseline theory, then the WG needs to develop a document to be used in conjunction with WCAG2 that lists what baseline technologies must be able to do (similar to UAAG)
Status: open
Working Group Notes: [TEAMA] [HOLD] 
BASICALLY THE SAME AS 1029 BUT 1028 IS SHORTER COMMENT. 
[AL] Commenter does not understand baseline. Propose to close and reject upon publication of better baseline document.
Resolution Working Notes - Unapproved:
Related Issues: 
LC-1028 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-1028> 


Comment LC-1030
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - Baseline needs to be defined, just like all other terms in WCAG2. There is no specific definition 

Proposed Change: 

Provide a definition for baseline
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-1031
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - Under "Examples of People and Places setting baselines" it says baseline includes only technologies supported by "accessible and affordable user agent(s)". What is the definition of "affordable"? I believe this is advocating technology preference. For instance, if Microsoft created a proprietary technology that only worked only on IE, which came bundled with new versions of Windows, then it could be argued that that proprietary technology could be included in a baseline. The W3C should not be in the advocating anything that supports large corporations taking over the web 

Proposed Change: 

Remove the baseline theory, or allow only UAAG compliant programs in baseline.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
BASICALLY THE SAME AS 1028.1029, 1030 
Resolution Working Notes - Unapproved:
Related Issues: 
1028 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1028>  
,1029, <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=,1029,>  
1030 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1030> 


Comment LC-1032
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - All the reasons why the WG left the definition of baseline up to the developers (or governing bodies) could also be used as reasons why the WG have developed an updatable document on technologies with enough accessibility features to be in baseline. The fact that there are no user agents that comply with UAAG is an obvious indication that there are no technologies (yet) that are as accessible as HTML and CSS. I believe it is reckless to leave this decision up to developers or managers whose focus is on the bottom line, not on providing accessible web sites. 

Proposed Change: 

Develop a document, for use with WCAG2, that list suitable technologies for baseline. This document can be updated by the WG or the W3C every year.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] We can close this issue when we close 902 and better baseline documentation.
Resolution Working Notes - Unapproved:
Related Issues: 
902 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=902> 


Comment LC-1034
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - Has the WG given any thought to people who decide to turn off technologies that could be in a baseline (eg. Javascript, Flash etc) because that is their preferred way of browsing - due to their disability? Has the WG given any thought to people who use assistive technologies that cannot interpret the output of certain technologies (eg. some screen readers cannot use javascript)? 

Proposed Change: 

Remove the baseline theory, or allow only UAAG compliant programs in baseline.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] By definition, all content are as accessible as the collective sc suggest at the corresponding compliance level. People who don’t want to or cannot use the technologies are indeed excluded, but not because of the disabilities covered by the success criteria. 

It is not the responsibility of web developer to make sure that their content would work with outdated assistive technologies. Propose to reject upon publication of baseline document.

Comment LC-1035
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - The theory of baseline will not stop a developer choosing an inappropriate and inaccessible baseline. 

Proposed Change: 

Remove the baseline theory, or allow only UAAG compliant programs in baseline.
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-1037
Sort Terms: BASELINE - DEVELOP YOUR 'GUIDE FOR POLICYMAKERS'
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - I believe it is not possible to fully comment on baseline due to the lack of a definition and the statement "The W3C-WAI may also prepare "A Guide for Policy Makers" to help organizations choose a baseline that will ensure the maximum accessibility for their environments". This policy document is mandatory to fully understand baseline and how it is to be applied. 

Proposed Change: 

Develop "A Guide for Policy Makers" and allow the public to comment prior to releasing WCAG2 as a W3C Recommendation
Status: open
Working Group Notes: [EDITORZ] [HOLD] 
[AL] It is not the responsibility of the WG to make such guide. Propose to reject upon publication of better baseline document.

Comment LC-1041
Sort Terms: BASELINE - Develop GUIDE TO POLICYMAKERS, Define BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - The section "Initial Guidance" is even more confusing than other parts of the documents. There are no definitions or rules for following baseline, just examples in this section. 

Proposed Change: 

Develop "A Guide for Policy Makers" and allow the public to comment prior to releasing WCAG2 as a W3C Recommendation. Develop a document, for use with WCAG2, that list suitable technologies for baseline. This document can be updated by the WG or the W3C every year. Provide a definition for baseline.
Status: open
Working Group Notes: [EDITORZ] [HOLD] 

Comment LC-1088
Sort Terms: baseline
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: time-limits-required-behaviors <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>  (Techniques)
Comment:
Situation A: In this situation clarify whether scripts are part of baseline or not
Status: open
Working Group Notes: [TEAMC] [HOLD] 

baseline is not part of the success criteria but is used in making conformance claims. The HTM documents address different technologies which can be used meet a specific success criterion. 
discussed at team c meeting - decided to mark with baseline catergory and leave on hold
Resolution Working Notes - Unapproved:
{reject} 
A baseline is used when making a conformance claim and is not part of each individual success criterion. The How to Meet documents for each success criterion provide techniques using different technologies which may be used to meet the criterion. The baseline may be set by the Web developer, an employer, governing body, or other entity. Once the baseline is set, an author can select the appropriate techniques. 

Comment LC-1145
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: accessible-alternatives-level1 <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
At least one version of the content meets all level 1 success criteria…: Where does baseline fit in this? 

Proposed Change: 

Clarify baseline requirements
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[Alex Li] Close/answer with the following comment--If only one version of the content meets all of level 1 sc, then all the relevant technologies for this version of content should be identified in the baseline. If more than one version of the content meets all of level 1 sc, then author should, for his self interest and others’ as well, identify all relevant technologies for the versions that meet the sc. But the author should only be obligated to identify the relevant technologies only for one version, not all versions.

Comment LC-1172
Sort Terms: 4.1.1 Public avail spec BASELINE IMPLICATIONS
Document: WCAG 2.0 Guidelines
Submitter: Greg Lowney <gcl-0039@access-research.org>     Affiliation: Lowney Access Research, LLC
Comment Type: substantive
Location: ensure-compat-parses <http://www.w3.org/TR/WCAG20/complete.html>  (Description)
Comment:
4.1.1 requires that Web content to be parsed unambiguously. Does this require the formal specifications be open, so that new user agents can parse the content? For example, suppose the baseline specifies just one Web browser, that implements rules for applying defaults to resolve any potential ambiguities in HTML that might be interpreted differently if another browser were used; is the HTML parsable unambiguously within the scope of the baseline? As another example, suppose a Web uses a proprietary data format that only a single plug-in can render; does it matter if it's parsable unambiguously if there is only one renderer? 

Proposed Change: 

Insert the phrase ", using publicly available specifications", to read "Web units or authored components can be parsed unambiguously, using publicly available specifications, and the relationships in the resulting data structure are also unambiguous.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
Propose to reject with fellowing response. 

To parse the web content unambiguously, it is not necessary to require a public specification. Some web content is proprietary and requires proprietary technology and/or proprietary user agents. This is commonly found in corporate or governmental environments. 

If proprietary data format is used and only a single plug-in can render the format, the content still needs to be parsed unambiguously in order for plug-in to render the content properly. The only difference is that the way to parse the content is not public information. 

Additionally, baseline does not include web browser, or any other user agents. Html, on the other hand, can be part of the baseline. If so, the html needs to be parse unambiguously. 
Resolution Working Notes - Unapproved:
{not accept} 


To parse the web content unambiguously, it is not necessary to require a public specification. Some web content is proprietary and requires proprietary technology and/or proprietary user agents. This is commonly found in corporate or governmental environments. 

If proprietary data format is used and only a single plug-in can render the format, the content still needs to be parsed unambiguously in order for plug-in to render the content properly. The only difference is that the way to parse the content is not public information. 

Additionally, baseline does not include web browser, or any other user agents. Html, on the other hand, can be part of the baseline. If so, the html needs to be parse unambiguously. 


[NEED TO ADD SOMETHING ABOUT = CANT BE IN BASELINE IF PROPRIETARY FORMAT IS NOT SUPPORTED BY THE USER AGENTS INCLUDING AT IN THE COMPANY OR CLOSED SYSTEM THAT WILL BE USING THIS PROPRITARY FORMAT}

Comment LC-1213
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Al Gilman <Alfred.S.Gilman@IEEE.org>
Comment Type: substantive
Location: conformance-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
The wide-open nature of the baseline means that the obvious interpretation of the W3C Candidate Recommendation phase could never be completed because there would be other baseline profiles that remained un-demonstrated. 

Proposed Change: 

Minimum: 
Spell out an explicit experiment plan for Candidate Recommendation. Define the baselines to be used to demonstrate the effectiveness of these guidelines. 

Better: 
Make PR [a.k.a. CR exit] contingent on demonstrating the joint statistical distribution of the proposed testable hypotheses and user success in using live contemporary web content.
Status: open
Working Group Notes: [EDITORZ] [HOLD]

Comment LC-1220
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Masafumi Nakane <max@wide.ad.jp>     Affiliation: Keio University
Comment Type: general comment
Location: conformance-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
The concept of baselines can greatly improve the flexibility of howauthors produce Web content. However, this is true only if appropriateand realistic baselines for the community which the content is targetedcan be specified without much difficulty. While this may not be an issuein countries where population of assistive technology users is not sosmall and there are more than a few accessibility experts, this will bean issue in many places where assistive technologies are not widelydeployed or advanced. Therefore, WAI (or W3C) should do its best toencourage important, and trusted players in various communities, such asdifferent disability communities in different countries, to help buildtypical and reasonable baselines. Otherwise, the baseline concept may bemisunderstood and misused, and many conforming, but inaccessible contentcould be produced.
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-1246
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>     Affiliation: Royal National Institute of the Blind
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: "In choosing Web technologies (HTML, scripting, etc.) that will be used when building content, authors need to know what technologies they can assume will be supported by, and active in, the user agents (including assistive technologies) that people with disabilities will be using. If authors rely on technologies that are not supported, then their content may not be accessible." 

- "assume" seems like a weak word and one that could provide a loophole, get out clause excuse for not making certain technologies accessible. For example a developer could "assume" that all their users have the latest Flash plug-in, screen reader version etc which may support certain technologies better than earlier versions. While I can understand what the concept of baseline is trying to do - give flexibility where it makes sense - it leaves a back door open. Would it not be an idea for WCAG 2 to recommend a minimum baseline (as the Mobile Web Initiative does in their Best Practises document). This can then be updated by WCAG as and when technologies move on. Alternatively some more substantial advice or guidance should be given to help people set sensible baselines and prevent people abusing the baseline. 

- the baseline section explains what it is (although in a slightly difficult to read way) but it gives very scant guidance on setting a baseline. This needs to be substantially developed. 

- The text "authors need to know what technologies they can assume will be supported by, and active in, the user agents" infers that this information is available from the software vendor where in reality it is not readily available. How then is a developer best able to "assume" a baseline without thoroughly investigating all access technologies and their ability to support CSS, HTML, Flash, JavaScript et al. Who is responsible for providing this support? Software developers, Government, advocacy groups?
Status: open

Comment LC-1247
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>     Affiliation: Royal National Institute of the Blind
Comment Type: general comment
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: The paragraphs describing baselines, what's included not included and what you have to confirm to depending on this, is very difficult to read. 

Proposed Change: 

Perhaps a couple of examples can be given explaining in each one what is included, not included and what is expected, some use scenarios i.e. "Is you include X, Y and Z in you baseline then...if U and V are not included then you must....".
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-1248
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>     Affiliation: Royal National Institute of the Blind
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: In reference to the number of baselines given there needs to be more of a focus on non-government/intranet example baselines. Government and Intranet baselines are the less contentious ones to set (at RNIB we have always done this for Intranets for example making adherence to JS less of a priority dependant on the user agents etc used in the organisations). Business websites, corporates, SME's etc are the ones who are going to need more of a steer as they have business needs that may overshadow fair baselines. 

Proposed Change: 

Perhaps another 2 examples of potential baselines for business could be given along with rationale.
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-1270
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Choosing Baseline Technologies)
Comment:
Comment: para 1 - "assume" is dangerous - they need to "know" the technologies "are" supported. 

Proposed Change: 

change sentence from "authors need to know what technologies they can assume will be supported by" to "authors need to know what technologies are supported by"
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-1271
Sort Terms: Baseline
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: editorial
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Choosing Baseline Technologies)
Comment:
Comment: para 2 - "browser" is used - should it be "user agent"? 

Proposed Change: 

consider changing sentence "since some users many have user agents that support them"
Status: open
Working Group Notes: [TEAMA] [HOLD] 

BBC: Removed baseline shortname and changed type to editorial.
Resolution Working Notes - Unapproved:
{accept} 
@@ change last sentence of "choosing baseline technologies" to read, "Both conditions are necessary since some users many have user agents that support them while others may not." 

Respond with. 

Thanks. The sentence has been revised as proposed. 

Comment LC-1273
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Who Sets Baselines)
Comment:
Comment: Examples of scenarios do not seem realistic - what happened to Banks, News sites, Supermarkets, etc providing private services online or selling goods online? 

Proposed Change: 

more examples are needed - or relegate the examples to the "About Baseline" accompanying document
Status: open
Working Group Notes: [TEAMA] [HOLD] 
Resolution Working Notes - Unapproved:

Comment LC-1274
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: In the discussion of baseline and conformance, it seems that there is potential for misuse of baseline [e.g. 
authors might be able to just declare their own level of technology, for instance: "requires CSS2 and JavaScript 1.2." The actual/potential audience, not just perceived/target audience or what developers wish they could reply on, should define baseline. 

W3C/WAI should consider setting realistic excample baslines for 'everyday' websites in developed/LD countries. 

Proposed Change: 

Some possible strategies include: 

a) to give guidance on what is a realistic baseline for most Internet sites 
today, W3C should publish a 'reasonable/realistic' baseline recommended for a general audience; 
b) update this 'recommended' baseline annually; 
c) place the 'recommended' baseline outside of the WCAG 2.0 normative document; 
d) provide an explanation about why the particular baseline is recommended
Status: open
Working Group Notes: [TEAMA] [HOLD]

Comment LC-1311
Sort Terms: BASELINE CONFORMANCE REORGANIZE?
Document: WCAG 2.0 Guidelines
Submitter: David Sloan <dsloan@computing.dundee.ac.uk>     Affiliation: Digital Media Access Group
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Response to WCAG 2.0 

From the following UK organisations: 

* JISC TechDis Service, Higher Education Academy Building, Innovation Way, York, YO10 5BR 
* BECTA (British Educational Communications and Technology Agency), Millburn Hill Road, Science Park, Coventry, CV4 7JJ 
* UKOLN, University of Bath, Bath, BA2 7AY 
* JISC CETIS (Centre For Educational Technology Interoperability Standards), Research Institute for Enhancing Learning, Padarn, School of Education, University of Wales Bangor, Normal Site, Bangor, Gwynedd, LL57 2PZ 
* Scottish Disability Team (SDT), Ewing Annexe, University of Dundee, Dundee, DD1 4HN 
* Digital Media Access Group (DMAG), School of Computing, University of Dundee, Dundee, DD1 4HN 

Contact: David Sloan, Digital Media Access Group (DMAG), School of Computing, University of Dundee, Dundee, DD1 4HN; dsloan @ computing.dundee.ac.uk 

Summary 

The above organisations, all active in the UK education/technology/disability field, broadly support the principles of inclusive Web design as set out by WCAG 2.0. We also have some reservations, many of which have been expressed elsewhere, over the practical application of WCAG 2.0 in its present form. We offer some general recommendations which, if followed, we believe will better serve Web content providers in the community in which we work. 

Background 

The 'Last Call' draft of version 2.0 of the Web Content Accessibility Guidelines (WCAG) has, since publication in April, attracted a significant amount of public comment, much of it of a negative nature. The authors of this response are all organisations heavily involved in promoting the appropriate use of technology to make access to education in the UK by disabled people as easy and effective as possible. We realise the importance of what will be the successor to the current de facto global standard for web accessibility in influencing commissioners and developers of Web content and applications, and all believe that WCAG 2.0 must build on WCAG 1.0 to improve, rather than inhibit levels of accessibility online. 

We do not wish to repeat other detailed responses by providing a line by line critique of the current draft. Instead we present a higher-level view, outlining our concerns and our support where appropriate. 

General 

We note the many other responses that have been submitted to WAI in response to WCAG, and while we share the concerns expressed over the likely difficulty many developers will have in applying WCAG to HTML development, we strongly support the need to present Web accessibility as something more than "just following guidelines". 

We are also conscious of the difficulty of developing accessibility guidelines, while also emphasising that readers must also be familiar with the ways in which disabled people access and use the Web; and the role of authoring and browsing tools - and their limitations - in ensuring an optimally accessible Web. 

Our involvement in education has influenced our belief that Web accessibility should be considered on two levels: 

* Developing Web sites to minimise the chances of excluding access by people with sensory, physical or cognitive impairments. 
* Using the potential of Web resources to improve access to real-world information, experiences and services for disabled people. 

This requires a holistic approach to Web accessibility - where development is driven by enabling the target audience to access and use the site for the intended purpose in the intended environment, whatever that may be [1, 2, 3]. In the UK, the recent emergence of PAS 78 [4] has highlighted the importance of other factors in optimising Web accessibility beyond technical conformance. 

We believe that the principles and guidelines set out in the WCAG 2.0 Last Call draft offer a solid platform on which to build on the two levels above. In particular, the technology-neutral approach adopted by WCAG supports authors in providing the best solution for the resource and audience in mind, whatever that may be. We further believe that the Baseline concept is an important step to enabling a more audience-focused approach to development, by allowing WCAG conformance to be specified in the context of a defined user environment that accurately represents reality. 

We also note the tensions that appear to have emerged between the Web Standards movement and the Web Accessibility movement. We support the principle of open standards adoption, we know of the accessibility benefits that standards-conformance can bring; but we also realise that standards-compliance is not always equivalent to optimal accessibility of experiences, services and information for disabled people. Therefore we appreciate the difficulty that WAI has faced in deciding where and how to include designing to HTML (and other) standards within WCAG 2.0. Standards-conformance should be strongly encouraged; at the same time, considering the relationship between WCAG and disability legislation around the world, the potential situation of a Web site being declared unlawful (or being removed for fear of being unlawful) because it fails to validate to a particular technical standard, despite no evidence to indicate that a specific group of disabled people face undue discrimination, must be avoided. 
Concerns 

As noted, we are concerned at the level of negative reaction to WCAG, much of which has come from prominent individuals in the field of web accessibility, notably [5]. We echo these concerns: 
Extent of supporting documentation and relationship between WCAG 2.0 and Techniques for HTML development 

The amount of documentation supporting the guidelines is immense; increasing complexity of navigation between guidelines and supporting documentation. We have welcomed the appearance in recent months of high-quality supporting material that has appeared on the redesigned WAI web site. However, we fear that the split between general guidelines and non-normative direction for specific technology development may lead to inappropriate solutions being applied. Given that, initially, most users of WCAG 2.0 will be HTML authors, this complexity, and in particular the relationship between WCAG and HTML Techniques needs to be revisited. 

Baseline 

We reject the arguments expressed elsewhere that the Baseline concept promotes a return to browser-specific development. However we recognise that there is scope for authors to abuse the Baseline concept, which therefore needs to be defined more coherently. We would anticipate that in the UK, were a case of alleged discrimination under the DDA to come to court, any court decision should look at the baseline (if specified) and its appropriateness to the target audience, and therefore baseline definition becomes a critical task. 
Support for people with learning difficulties/disabilities 

We share concerns expressed by others over the lack of focus on supporting people with varying cognitive impairments. We would like to see more encouragement given to supporting people who have difficulty reading on-screen text, through for example encouraging appropriate use of multimedia alternatives if they exist or can easily be created, but we also realise that there remains much work to do in this area. Nevertheless we have lent our support to the sentiments expressed in the Formal Objection co-ordinated by Lisa Seeman and Jonathan Chetwynd. 

Conformance 

We feel that the way in which WCAG conformance has been addressed is excessively complex. In the UK, our legal obligations are to ensure that facilities and services are made accessible, and thus concentration should be on making tasks optimally accessible, and reporting on that success. The WCAG however deals with conformance at an artificial level - i.e. "Web unit", introducing as it does a new set of terminology that may confuse many people. We would prefer to see a more task-oriented approach to conformance, whereby lack of conformance requires a responsibility to document alternative routes to achieving task completion - this should be stated explicitly in the guidelines. 

Suggestions 

HTML application of WCAG 

We see the most critical task as redefining the relationship between WCAG 2.0 and the WCAG 2.0 HTML Techniques. There is a need to support the most common WCAG 2.0 use case (those seeking support for HTML/XHTML development) by making it clear to developers what is and is not permitted in WCAG-conformant design. Clarification on the WCAG position on validation of HTML/CSS is also necessary, given the nature of many comments on the current draft and worries that WCAG conformance may promote increased use of invalid HTML. 

NB We note strong support amongst Web developers for focus to move to amending WCAG 1.0 as a matter of urgency; and that development of WCAG 2.0 be continued longer-term in parallel with a redefinition of the role of second-generation Web Content Accessibility Guidelines in a world where there is increasing diversity in the nature and source of Web content (for example podcasts, collaborative online publishing areas, email discussion list archives, to name but a few), but where UAAG support by widely-used user agents is likely to remain disappointing. While we have indicated our support for the 'principles' approach that WCAG 2.0 has taken, we would support the WAI should it decide to refocus efforts in producing a revised WCAG 1.0 as an interim measure. 

Amount of supporting documentation 

There is a need to reduce the perceived amount of reading required. We assume that the errors and logical absurdities pointed out by other commentators will be addressed; however we would also like to see a reduction in the amount of new concepts that must be learned by a reader. Some examples illustrating key concepts within the guidelines would be a very useful aid in this area. 

NB We note the recent appearance of the WCAG 2.0 Quick Reference - which is a major step in this area. 

Conformance 

To ensure a practically useful conformance system, there is a need to shift focus from 'Web units' to user tasks. Defining what can be done in a Web site, and which groups may find these tasks difficult or impossible, is we argue of more relevance that a report of an artificial entity's conformance against a set of checkpoints. WCAG conformance should be seen as a means to achieving accessible experiences, and not an end in its own right. 

Baseline 

Clarification of the concept is necessary so as to limit misinterpretations and potential abuses. If not already happening, there is an urgent need for WAI to work with influential agencies across the globe to ensure that appropriate and reasonable baselines are defined and published for specific sectors. 

Web Standards v Web Accessibility 

The balance between Web Standards and Web Accessibility is altogether more difficult to address. We realise that external developments will be difficult for WAI to control, but we strongly urge WAI to re-establish links with those involved in any rival developments so that we have harmony in the way we all seek to achieve the common goal of an optimally accessible Web. 

References 

1. Kelly, B., Sloan, D., Phipps, L., Petrie, H. and Hamilton, F. (2005) Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World. Proceedings of the 2005 International Cross-Disciplinary Workshop on Web Accessibility (W4A). http://www.ukoln.ac.uk/web-focus/papers/w4a-2005/ 
2. Kelly, B., Phipps, L. and Howell, C. (2005) Implementing A Holistic Approach To E-Learning Accessibility. In: Cook, J. and Whitelock, D. Exploring the frontiers of e-learning: borders, outposts and migration; ALT-C 2005 12th International Conference Research Proceedings, ALT Oxford. http://www.ukoln.ac.uk/web-focus/papers/alt-c-2005/ 
3. Sloan, D., Kelly, B., Heath, A., Petrie, H. Fraser, H. and Phipps, L. (2006) Contextual Web Accessibility - Maximizing the Benefit of Accessibility Guidelines. Proceedings of the 2006 International Cross-Disciplinary Workshop on Web Accessibility (W4A). http://www.ukoln.ac.uk/web-focus/papers/w4a-2006/ 
4. British Standards Institute (2006) Publicly Available Specification PAS 78:2006 Guide to good practice in commissioning accessible web sites. http://www.bsi-global.com/ICT/PAS78/index.xalter 
5. Clark J (2006) To Hell with WCAG 2.0. A List Apart 217. http://www.alistapart.com/articles/tohellwithwcag2

Status: open
Working Group Notes: [EDITORZ] [HOLD] 

Comment LC-1314
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Takayuki Watanabe, Makoto Ueki, and Masahiro Umegaki <nabe@lab.twcu.ac.jp>     Affiliation: JIS WG2
Comment Type: general comment
Location: conformance <http://www.w3.org/TR/WCAG20/complete.html>  (Baseline)
Comment:
Comment: Baseline concept may cause accessibility degeneracy. We may have Web sites that conform to WCAG 2.0 but inaccessible to users. 

Baseline concept separates the responsibility of content from that of user agents, which means content authors do not have to pay attention to what kinds of user agents can access their content but just use some baselines. Content authors can use XHTML 1.0 even if not all major user agents can access the content written in XHTML 1.0. (This is a case in Japan. Major Japanese user agents can not use structure markups of HTML 4.01 and XHTML 1.0.) In WCAG 2.0 this inaccessibility is blamed on user agents. If there are major user agents that cannot access the technology included in the baseline, user cannot use the content even if content is made accessible. 

Proposed Change: 

New subsection "Attention to user agent capabilities" should be included to discuss this issue. Having a good UAAG and public awareness to UAAG is also important.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] Propose to partial accept with comment (pending better baseline document with added emphasize to list tested user agent, if any)--it is true, but user agent compatibility status with various technology changes frequently. WCAG is designed to outlive such status change. It is the responsibility of user agent provider to disclose the compatibility status. On the other hand, it is not possible for an author to claim conformance to a success criterion if no user agent would allow the content to meet the success criterion, assuming such criterion is user-agent-dependent.

Comment LC-1315
Sort Terms: BASELINE RELATED
Document: WCAG 2.0 Guidelines
Submitter: Takayuki Watanabe, Makoto Ueki, and Masahiro Umegaki <nabe@lab.twcu.ac.jp>     Affiliation: JIS WG2
Comment Type: general comment
Location: conformance <http://www.w3.org/TR/WCAG20/complete.html>  (Optional Components of a Conformance Claim)
Comment:
Comment: WCAG 2.0 should put more emphasis on the importance of having a list of user agents that the content has been tested on. As pointed out in the comment #2, knowledge of which user agents can access that content is very important. 

In Japan, our research [1] showed that Japanese major user agents were divided into two groups: JAWS and HPR can use structure markups and other important functions, while 95-Reader and PC-Talker can not. Most Japanese users do not know the benefits of skip navigation, heading navigation, table-structure navigation, or search text in a page because their user agents do not have these capabilities. (X)HTML is the basic technology which must be included in all baselines but major Japanese user agents cannot use some important accessibility functions of (X)HTML. Thus, we can say that baseline concept is too rough to show which technologies are accessible to users. Information of user agents is necessary to show that content is accessible to users. 

In addition to that, user agents might be different among users with various disabilities. It may happen that the same content is accessible to users with cognitive disabilities but not accessible to visual disabilities. 

We think conformance claims that include a list of user agents that have been tested on and a detail list of specific capabilities of those user agents is an ideal but we know it requires too much burden to the authors. Thus, we propose that WCAG 2.0 should put more emphasis on the importance of having a list of user agents that the content has been tested on. 

[1] Watanabe, T. and Umegaki, M. 
"Capability Survey of Japanese User Agents and Its Impact on Web Accessibility", 
Proceedings of W4A 2006. 
http://www.w4a.info/2006/prog/6-watanabe.pdf

Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] Propose to partial accept with comment (pending better baseline document with added emphasize to list tested user agent, if any)--it is true, but user agent compatibility status with various technology changes frequently. WCAG is designed to outlive such status change. It is the responsibility of user agent provider to disclose the compatibility status. On the other hand, it is not possible for an author to claim conformance to a success criterion if no user agent would allow the content to meet the success criterion, assuming such criterion is user-agent-dependent.

Comment LC-1316
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Takayuki Watanabe, Makoto Ueki, and Masahiro Umegaki <nabe@lab.twcu.ac.jp>     Affiliation: JIS WG2
Comment Type: general comment
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: We need more concrete and realistic examples of baseline. For example, the baseline used in public web sites in the US, the baseline used in W3C web sites.
Status: open
Working Group Notes: [TEAMA] [HOLD] 

Comment LC-1370
Sort Terms: INTRODUCTION BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Richard Ishida <ishida@w3.org>     Affiliation: I18N WG
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment from the i18n review of: 
http://www.w3.org/TR/2006/WD-WCAG20-20060427/ 

Comment 1 
At http://www.w3.org/International/reviews/0606-wcag2/ 
Editorial/substantive: E 
Owner: RI 

Location in reviewed document: 
Introduction 

Comment: 
The content of the introduction is long and written in a legalistic style that is hard to get through. I think this can putoff, or at least scare, web designers and content authors. 


I suggest that you provide short summaries of each major section, written in a friendly style, so that people can get thegist of the section. That way the complex normative text can remain, but does not have to be read in detail until needed. 


Also, use more active phrasing. For example, "The set of technologies that an author assumes are supported and turned on inaccessible user agents is called a baseline." could be written "A baseline is what we call the set of technologies that an author assumes aresupported and turned on in accessible user agents." This is easier to read, makes it easier to find the definition of 'baseline', and gives a quickeridea of the content of the paragraph for those who are skimming text.
Status: open
Working Group Notes: [EDITORZ] [HOLD] 

Comment LC-1411
Sort Terms: BASELINE CONFORMANCE
Document: WCAG 2.0 Guidelines
Submitter: David Keech <david.keech@bsi-global.com> <>     Affiliation: British Standards Instution, London, UK
Comment Type: substantive
Location: 0Free <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
7. In the section "Examples of conformance claims", "jpeg" is specified as a requirement of one example (examples use "Real Video" and "png" in a similar manner). These are not testable specifications in the same sense as XHTML 1.0 (Strict) - for example progressive jpeg support was only added to many browsers long after the basic sub-baseline jpeg (actually correctly JPEG) decoding was implemented. IS 10918-1 | T.81 (which presumably is what is intended by JPEG) defines a 'shopping list' of image compression techniques, including a baseline. Actual JPEG implementations excludes many items in the list, and add other items (typically JFIF/EXIF file support), and are, almost without exception, sub-baseline. A claim that an item "relies upon" jpeg (sic) is fairly meaningless, and is dependent on many things other than a correct interpretation of parts of IS 10918-1 (for example bit resolution and colour rendering of the display)
Status: open
Working Group Notes: [TEAMA] [HOLD] 
[AL] Action item --more research is needed. Please assign.
Resolution Working Notes - Unapproved:
Related Issues: 
878 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=878>  
IS <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=IS>  
PARENT <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=PARENT> 


Comment LC-1494
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Eric Hansen <ehansen@ets.org>     Affiliation: Educational Testing Service
Comment Type: substantive
Location: glossary <http://www.w3.org/TR/WCAG20/complete.html>  (def. of baseline)
Comment:
baseline (in this document) 

[Priority a set of technologies that are used as a basis for determining conformance to WCAG 2.0. These technologies may include: markup languages (e.g., XHTML, XML, SMIL, etc.), programming languages (e.g., …), style sheets (e.g., …), data formats (e.g.,,image formats, video formats, audio formats, document formats), and APIs. 

In defining the baseline, it is valuable to consider, among other things, the set of technologies that are expected to be supported by, enabled in user agents by members of the intended audience. [This is obviously not the only consideration… The original definition leans too hard on the assumption (expectation) but is not clear about whose assumption it is…..!] 
[Original : “set of technologies assumed to be supported by, and enabled in, user agents” ] 
Note: For more information on baselines and their use, refer to Technology Assumptions and the "baseline." 
Status: open
Working Group Notes: [TEAMA]


Pending Issues
Comment LC-786
Sort Terms: baseline
Document: Understanding WCAG 2.0
Submitter: Joe Clark <joeclark@joeclark.org>
Comment Type: substantive
Location: text-equiv-all <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>  
Comment:
Comment: 

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html 

Text alternatives 

[INS: [For n] :INS] on-text content that is multimedia... it is important that users know what it is when they encounter it on a page so they can decide what action if any they want to take with it. A text alternative that describes the multimedia and/or gives its title is therefore provided. 

How do I do that with, say, embed, which permits no fallback content? (Of course there's noembed, but, since all graphical browsers understand embed, noembed content will never be displayed. In any event, there is no actual or official specification for embed and especially noembed.) Does this not mean I have to label each video in plain text?
Status: Pending WG review (pending).
Working Group Notes: [TEAMC] [HOLD] 

With <object>, if the browser cannot retreive the requested object and successfully process it, either by executing the applet or by processing the object's data with a plug-in application, the browser will display the contents of the <object> element. 

With <embed>, there is no way to provide alternative content within the element. And the <noembed> element content is only rendered if the browser doesn't support <embed>. I don't know what happens if the browser supports <embed> but something goes wrong with trying to render the content. But Joe is saying that all browsers support <embed> so the <noembed> content will never be rendered and there is no way to provide alternative content. 
Resolution Recommended by Taskforce:
{accept} 

@@ Remove the technique "Using noembed with embed"? 

@@ Create a technique for providing text alternatives for EMBED in same doc (or as 'd-link') 

RESPOND WITH: 

Thank you for your comment. We have removed the technique on using noembed with embed and have created a new technique on providing text alternatives for EMBED.

Comment LC-861
Sort Terms: BASELINE SCOPING
Document: WCAG 2.0 Guidelines
Submitter: Joe Clark <joeclark@joeclark.org>
Comment Type: substantive
Location: conformance <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html 

The concepts of scoping, baseline, and target audience are so misguided as to derail WCAG's entire project. The first two topics were addressed in my A List Apart article. The last one deserves mention here. 

Information about audience assumptions or target audience. This could include language, geographic information, or other pertinent information about the intended audience. The target-audience information CANNOT specify anything related to disability or to physical, sensory or cognitive requirements. [INS: [Overwrought emphasis sic] :INS] 

In other words, even if you extensively test your site and can demonstrate the following is true, you cannot state that your site is accessible to people with disabilities. While the guideline appears to be intended to make it impossible to declare, for example, that a site is not meant to be used by blind people, it also becomes impossible to state that it provably can be used by them.
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] 
[AL] Reject. WCAG does not make gurantee of access based on disabilities. User agents factors into the final accessibility status.

Comment LC-1033
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Baseline - Under "Examples of baselines and what they mean" (example 1) it says "The baseline includes HTML 4.01, in addition to GIF and JPEG images… this extremely limited baseline…". I object to the use of the words "extremely limited" - it is a deliberately pejorative statement 

Proposed Change: 

Remove the words "extremely limited"
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] 
[AL] Propose to reject. The term "extremely limited" is referred to the range of technology referenced in the baseline.

Comment LC-1070
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: mapping <http://www.w3.org/TR/WCAG20/complete.html>  (Checkpoint 6.1)
Comment:
Baseline CSS: This mapping essentially says that if CSS is in the baseline then information can be put into the style sheet and not in the HTML. This appears to allow formatting (ie headings) via CSS and not HTML, important images included in CSS and not HTML, etc. How is someone who uses a screen reader going to interpret this? How are they going to be able to access the information they require? 

Proposed Change: 

Clarify baseline requirements
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] 

We have a problem with newer CSS where you can put information in the style sheet. THe question has come up -- DO WE HAVE TO EITHER we have to 1) never allow those technologies into the baseline OR 2) we need to profile standards saying that only some parts of the technology are in the baseline. This is a VERY BIG ISSUE. 

If CSS is IN the baseline though - we are saying Everyone can use CSS and you can use it to meet WCAG. so that would mean you CAN put content in the style sheet. Which leads to the following conclusion?? If CSS is in the baseline - then if you turn it off or override it you may lose content - but that is ok. CSS is in the baseline so you should be able to handle CSS so just dont turn it off. 

Is that where we want to be? Not clear at all. 

[AL] Yes! If CSS is in your baseline and you turn it off, you should expect a lost of content or failure to meet certain sc that the content otherwise would pass. Propose to reject.

Comment LC-1221
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Masafumi Nakane <max@wide.ad.jp>     Affiliation: Keio University
Comment Type: general comment
Location: conformance-reqs <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Specifying baselines in terms of Web technologies in stead of browsersis reasonable and understandable technically, however, is not realistic.When an author specifies HTML 4.01 and CSS Level 2 in the baseline, forexample, that could mean the content can include some HTML elementsand/or CSS properties that are not supported by any of existing browsersand still being WCAG compliant. There should be a mechanism to specifythe baseline in more detailed manner, probably a way to refer toparticular set of functionalities of the technologies in question.
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] [] 
[AL] Propose to reject. User agent and functionality is beyond the concept of baseline. If appropriate, user can make separate conformance claims in different functionalities or areas.

Comment LC-1269
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Intro Paragraphs)
Comment:
Comment: para 2 - User agents not only "help in retrieving and rendering Web content", but also in interacting with web content 

Proposed Change: 

change sentence to "help in retrieving, rendering and interacting with Web content"
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] [] 
[Alex Li] Propose to accept.

Comment LC-1272
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: editorial
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Who Sets Baselines)
Comment:
Comment: para 1 - I didn't understand "customers" setting baselines - for a large organisation doing it's own development, the concept of its 'customers' setting the basleine is ridiculous 

Proposed Change: 

openiong sentence may need clarification 

Also - 'governmental' does not seem right, should it just be 'government'?
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] [] 
[AL] Propose to partial accept and remove customer from list of entities that can set baseline. It is not necessary to change “governmental bodies” to “government bodies”.

Comment LC-1302
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Charles McCathieNevile <chaals@opera.com>
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  (Choosing Baselines)
Comment:
Technical/substantive issue 

The section currently provides no guidance to actually choosing a baseline 
that can in fact be used accessibly. 

I propose that the availability of a user agent which meets level-A 
conformance to User Agent Accessibility Guidelines 1.0 for the relevant 
technology and language be a minimum criterion for the selection of a 
baseline. 

In this way, selection of a baseline that is not actually accessible 
automatically makes it impossible to claim conformance to the 
accessibility guidelines. This avoids the situation where it is possible 
to construct content that can meet the requirements, but that is not 
actually accessible due to the absence of any means for using the baseline 
set. Otherwise there is a risk that the value of conformance will be 
significantly reduced, since it makes no reliable statement about whether 
the content is in fact accessible to real people. 

This seems a reasonable requirement given that UAAG is a W3C 
recommendation, and does not seem onerous for common web technologies. 

cheers 

Chaals
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] [] 
[AL] Propose to reject with comment that it is possible to use non-UAAG compliant user agents to make WCAG compliant content accessible. If, for example, there is no non-text content within the conformance claim, then it is not necessary to concern about using a user agent that can or cannot interrupt the text alternatives of the non-text content. There is not a full correlation between accessible user agent and baseline.

Comment LC-1307
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Charles McCathieNevile <chaals@opera.com>
Comment Type: substantive
Location: baseline <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Structural/substantive issue 

The specification seems to take no account of situations where in fact all 
user agents relevant to a given baseline offer functionality that the 
guidelines are requiring of authors. 

Where this is the case (for example, SVG user agents generally provide a 
mechanism to pause any animation independently of the content, and in SVG 
tiny it is not possible to provide the functionality in content anyway) 
the guidelines should take it into account. 

I propose that the baseline section be reworked, to incorporate this type 
of situation. Perhaps the most robust way of specifying this would be to 
explicitly relate UAAG requirements to WCAG requirements, and note that 
where there are (some expression for most or all) user agents for the 
baseline which meet a given UAAG requirement the corresponding WCAG 
requirement need not be met. Note that the proportion of user agents for 
which this needs to be true should be at least as high, and probably 
higher than that which is reasonable to justify the use of a particular 
baseline in the first place.
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] [] 
[AL] Propose to reject with comment that if there is no user agent that would allow the content to meet a specific success criterion, then the content would not be able to meet the corresponding compliance level. For example, nobody can claim to meet 2.2.3 unless there is a way to pause the content unless the activity is timing and movement essential. UAAG compliance is not necessary.

Comment LC-1313
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Takayuki Watanabe, Makoto Ueki, and Masahiro Umegaki <nabe@lab.twcu.ac.jp>     Affiliation: JIS WG2
Comment Type: general comment
Location: conformance <http://www.w3.org/TR/WCAG20/complete.html>  (Baseline)
Comment:
Comment: Baseline is a good concept. We support this concept because technologies that are considered to be accessible may differ among countries and among user domains. Baseline concept in principle enables us to adopt WCAG 2.0 in various countries.
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMA] [] 
[AL] Propose to accept and express appreciation.


Closed Issues
Comment LC-483
Sort Terms: BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Jason White <jasonw@ariel.its.unimelb.edu.au>
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (Including rationale for any proposed change): 

The conformance section is not sufficiently precise in stating what must be included in a baseline. Specifically, a baseline must specify a list of technologies, including minimum versions, where applicable, thereof, that are required to be supported in order for the content to be rendered to, and operated by, the user. 

Proposed Change: 

In the "required components of a conformance claim" section, explain clearly that, where applicable (i.e., where there exist multiple versions of a technology), the minimum version required to be supported and enabled in user agents must be stated as part of the baseline. More explicitly, the baseline must name each technology together with the minimum required version, where applicable.
Status: Resolved (resolved_yes).
Response Status: 27
Working Group Notes: [TEAMA] 

Discussed in the 16 May 2006 Team A call, proposal sent to list: 
http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0186.html 

Resolution adopted by working group on 18 May 2006 Teleconference: <http://www.w3.org/WAI/GL/2006/05/18-wai-wcag-minutes.html> <http://www.w3.org/WAI/GL/2006/05/18-wai-wcag-minutes.html%3E> ; 
{accept} 

The following sentence was added to the end of the section titled "Choosing Baseline Technologies" (end of 2nd paragraph) to XML source 14 June 2006. 

"When citing technologies in a baseline, the version(s) must be specified." 
Resolution - Pending Response:
The following sentence was addded to the end of the section titled "Choosing Baseline Technologies" (end of 2nd paragraph): 

"When citing technologies in a baseline, the version(s) must be specified." 

Comment LC-617
Sort Terms: BASELINE RELATED
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: mapping <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for any proposed change): 

from the appendix... 
"If style sheets are in your baseline, WCAG 1.0 checkpoint 6.1 (that the word order of text needs to make sense without css) is not required;" 

I do not understand this example, In fact it seems to highlight the problem of baseline - that an accessibility problem will persist even if a technology is supported by Assistive technology. For example An Assistive technology may be able to work with Aural CSS (if it was not depreciated) display visible, phuedo class etc, and still not be able to work out what the reading order is just based of pixel positioning of test in columns (without more information). 

surely text out of order will not be understandable by assistive technologies even when CSS is supported? 

7, Overall people are struggling understanding the baseline concept. One person, hugely talented and experienced in accessibility thought that if all pages used CSS then 6.1 does not matter any more 

Proposed Change: 

How can we define baseline so that 6.1 is supported in this baseline?
Status: Resolved (resolved_partial).
Response Status: Resolution implemented
Working Group Notes: [TEAMA] 
Even if style sheets are in the baseline, the content must satisfy SC 1.3.3. The Failure "Failure of SC 1.3.3 due to changing the meaning of content by positioning information with CSS." would explicitly prohibit this sort of use of CSS. 


-- 
Discussed on the 22 June 2006 teleconference 
resolution: accept as proposed with addition of action item cited by Christophe 
http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html 

{partial accept} 
DONE change the bullet in Appendix D from "if style sheets are in your baseline, WCAG 1.0 checkpoint 6.1 is not required;" to "if style sheets are in your baseline, WCAG 1.0 checkpoint 6.1 is not required, but the meaning of the content must not depend on CSS positioning (SC 1.3.3);" in order to avoid confusion in the future? 

XML Source updated 07 July 2006.
Resolution - Pending Response:
The working group agrees that the problem you cite should not be allowed. However, that problem is already not allowed with the current guidelines. Even if style sheets are in the baseline, the content must satisfy SC 1.3.3. The Failure "Failure of SC 1.3.3 due to changing the meaning of content by positioning information with CSS." would explicitly prohibit this sort of use of CSS.

Comment LC-660
Sort Terms: BASELINE
Document: Understanding WCAG 2.0
Submitter: Lynn Alford <imla@jcu.edu.au>     Affiliation: James Cook University
Comment Type: substantive
Location: 0Free(none selected) <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>  (Techniques)
Comment:
Part of Item: Techniques 
Comment Type: GE 
Comment (including rationale for proposed change): 

In the document \"About Baseline and WCAG2.0\" it states 

\"They would use the HTML 4.01 techniques described as “sufficient” in Understanding WCAG 2.0. (Authors may further enhance the user experience by also using additional HTML techniques listed as “advisory” (optional) in Understanding WCAG 2.0.)\" 

The sections with advisory techniques are clearly labeled as \"Additional Techniques (Advisory) for x.x.x\" 

The techniques deemed as sufficient requires that you read the paragraph under the title \"Techniques for Addressing Success Criterion x.x.x\" which does says \"Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion x.x.x as long as the technologies used are in the baseline you are using.\" 

Proposed Change: 

Clearly mark the \'sufficient\' techniques in the document to aid understanding both documents.
Status: Resolved (resolved_yes).
Response Status: Resolution implemented
Working Group Notes: [EDITORZ] 

Discussed 06 July 2006 
resolution: accept LC-660 as amended 
http://www.w3.org/2006/07/06-wai-wcag-minutes.html 
DONE update techniques sections of Understanding to match formatting in quick reference.
Resolution - Pending Response:
Yes - we see that problem. Take a look at the QUICK REFRENCE document at http://www.w3.org/WAI/WCAG20/quickref/. We have rearragned the techniques to make them clearer and avoid the problem you cite both here and in Understanding WCAG 2.0.

Comment LC-829
Sort Terms: baseline
Document: WCAG 2.0 Guidelines
Submitter: Rick Hill <rrhill@ucdavis.edu>
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
1. The provision to define a technology as a "baseline" is not 
useful unless there is either some way to make sure that the 
technology is inherently accessible and/or that there are provisions 
to provide alternate technologies to provide accessible versions of the content where the baseline technology fails.
Status: Resolved (resolved_partial).
Working Group Notes: [TEAMA] 

Relates to Issue LC-737 

Discussed 29 June 2006 
resoution: 829, 775, 723 accept because they were unanamous in the surveys 
http://www.w3.org/2006/06/29-wai-wcag-minutes.html

Resolution - Pending Response:
{partial accept} 
There are two ways in which technologies that may not be fully accessible can be used in the baseline. You have identified one such condition in your comment regarding alternative technologies. Guideline 4.2 addresses this area. The less obvious way to which a technology that is not fully accessible can be used is that--the conditions to which the technology become inaccessible do not occur in the content. For example, let's imagine a technology that fully conforms to WCAG 2.0 with the only exception that non-text content cannot be supported with alternative text. You may not logically expect to see this technology used in a WCAG 2.0 compliance site. But the author can use this technology and claim conformance IF there is no non-text content of this technology in the web units. 

Comment LC-837
Sort Terms: BASELINE IMPLICATIONS
Document: WCAG 2.0 Guidelines
Submitter: Kazunori MINATANI <minatani@debian.or.jp>     Affiliation: Science and Technology research Laboratories, Japan Broadcast Corporation
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: substantive 
Comment (including rationale for proposed change): 

Conformance claims are complicated definitions. They are human understandable however user will not make good use of them. And they are not machine understandable because their definition and format are not provided strictly. 

Proposed Change: 

Describing format of Conformance claims should be 
determined strictly. If Conformance claims are understandable for a User Agent 
(whether achieve a baseline or not), it is possible to cope with 
that contents.
Status: Resolved (resolved_no).
Working Group Notes: [TEAMA] 
I've sent an email to Minatini to ask for clarification. Is he suggesting we make the SC 100% machine tesable...if that is what he is saying. then... 

While its true that introducing technology independence into the 2.0 does add a certain amount of complexity, we have done our utmost to make the guidelines as clear as possible and continue to look for improvements to ease of language where it would not comprimize the solution. If I undersand this comment correctly he is suggesting we make the SC semantically machine testable. THe working group makes it clear that accessibility is not something that can be tested only by machines. Propose to reject the comment. 

Minatini responded to my request for clarification. 
He said: 

No. I understood the Success Criteria would not be made to 100% machine testable. 
But if a way of Conformance Claims's description is prescribed strictly(without no arbitrariness), User Agents will be able to parse a Conformance Claims and understand what is problem. 
And they may find a solution in spite of they don't achieve the baseline. 
I focused on this point. 

I asked him if he was talking about metadata... 

> HI Minatani 
> 
> Are you speaking about metadata for conformance claims? 
Yes. 
My proposal will be exactly achieved by metadata. 

Discussed in the 13 July 2006 telecon: 
Accepted by unanimous consent. 
http://www.w3.org/2006/07/13-wai-wcag-minutes.html 
Resolution - Pending Response:
{not accept} Refer to issue 1317 for proposed resolution. 
Related Issues: 
1317 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1317> 


Comment LC-1027
Sort Terms: Definition of Accessibility & LEVELS remove statement that all content cannot be made accessible. and merge levels BASELINE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Definition of accessibility - In the Baseline document (under the heading 'If the WCAG does not set the baseline, then how can we be sure that a site will be accessible?) it says "No site or content is ever completely accessible". In the Conformance document it says "Note that even conformance to all three levels will not make web content accessible to all people." I strongly object to these statements. All content can be made accessible. In some cases, content may not be accessible, but if the problems were identified it could be made accessible. As the main body representing accessibility I think it reprehensible that we have these statements. 

Proposed Change: 

Remove the statements. Merge Level 1 and Level 2 SC into one group called 'Mandatory'. Rename Level 3 to 'Advisory' or 'Optional'
Status: Resolved (resolved_no).
Response Status: Resolution implemented
Working Group Notes: [EDITORZ] 

Discussed in the 21 September 2006 telecon: 
Resolution: accept LC-1027 as amended 
http://www.w3.org/WAI/GL/2006/09/21-wai-wcag-minutes.html 

{reject} 

DONE Replace the sentence, "Note that even conformance to all three levels will not make Web content accessible to all people." with, "Note that even conformance to all three levels of WCAG 2.0 will not make Web content accessible to all people. As was true for WCAG 1.0 even content that is AAA conformant will not overcome the accessibility barriers faced by those with certain combinations of disabilities or with certain types of severe disabilities." (leave original sentence bold and new sentence unbolded) 

Internal WD updated 25 September. 
Resolution - Pending Response:
The statements you refer to are meant to reflect the reality that not all Web content can be made accessible to all people. One of the lessons learned with WCAG 1.0 was that, for some individuals, even content that meets WCAG 1.0 AAA did not overcome the accessibility barriers faced by those with certain combinations of disabilities or with certain types of severe disabilities. 

Regarding the proposal to combine levels one and two as mandatory and rename level 3 to advisory or optional, the working group has received a great deal of feedback on both sides of this issue. We have chosen 3 levels because we feel it provides the best options for the different users of the guidelines.