Baselines The concept of baselines can greatly improve the flexibility of how authors produce Web content. However, this is true only if appropriate and realistic baselines for the community which the content is targeted can be specified without much difficulty. While this may not be an issue in countries where population of assistive technology users is not so small and there are more than a few accessibility experts, this will be an issue in many places where assistive technologies are not widely deployed or advanced. Therefore, WAI (or W3C) should do its best to encourage important, and trusted players in various communities, such as different disability communities in different countries, to help build typical and reasonable baselines. Otherwise, the baseline concept may be misunderstood and misused, and many conforming, but inaccessible content could be produced. Baselines Specifying baselines in terms of Web technologies in stead of browsers is reasonable and understandable technically, however, is not realistic. When an author specifies HTML 4.01 and CSS Level 2 in the baseline, for example, that could mean the content can include some HTML elements and/or CSS properties that are not supported by any of existing browsers and still being WCAG compliant. There should be a mechanism to specify the baseline in more detailed manner, probably a way to refer to particular set of functionalities of the technologies in question. conformance notes and aggregated content Will these examples conform to WCAG? 1. A perfectly conforming blog site, with comment form, and comments posted by someone breaks the conformance; 2. The page is perfectly conforming, except for a fragment of code which was provided by affiliate program of a shopping site, and the user is not allowed to modify the code. From the current wording of WCAG, these examples look to be not conforming to WCAG. This can limit the creativity and variety in ideas for Web content if authors are keen to meet the WCAG, or let many authors decide not to care too much about the conformance. Limit the responsibility of the content creator to those Web units that are authored by the creators themselves. 1.2.2 This seems to consist of 1.2.3 and 1.2.7. This structure, where meeting one success criterion automatically means meeting another, is rather confusing. 1.2.3 Some multimedia content is accessible even without audio description. They can be understood without any problem from the background sounds, narration, etc. Setting this success criterion to be level 1 or 2 can cause redundancy, and may hinder the accessibility of such simple content. Make this applicable only to those content that cannot be understood without audio description. There may be a discussion how to determine if a piece of content is accessible without audio description, but that should be as easy as determining if added audio description is sufficient to make the content accessible. 1.4.1 Is there any scientific fact that supports luminosity contrast ration of 5:1 is sufficient? Unless this is a scientifically proven ration and is not likely to be changed in future, such a value should not be included in a normative part of the document. 1.4.3 Is there any scientific fact that supports luminosity contrast ration of 10:1 is sufficient? Unless this is a scientifically proven ration and is not likely to be changed in future, such a value should not be included in a normative part of the document. 1.4.3 This structure, where meeting 1.4.3 automatically means meeting 1.4.1 is rather confusing. 1.4.4 Is there any scientific fact that supports 20db is sufficient? Unless this is a scientifically proven value and is not likely to be changed in future, such a value should not be included in a normative part of the document. 2.1.1 Today, there are two levels of "being keyboard operable." One is simply being eable to operated without using a mouse, with simple keystrokes such as the tab and the enter keys. The other, higher level is where author uses extensive client-side scripting to provide keyboard shortcuts. (The user interface of the Gmail is an example.) In the latter case, many of the keystrokes provided by the author may conflict with keyboard commands provided by the UA (including the assistive technology.) Thus, in this case, it would not make much accessibility inprovement especially for those using screen readers and other AT that make extensive use of keyboard. The level in WCAG and explanation in the UW document should be clear about this point. 2.2.1 Is there any scientific fact that supports the figures given in this success criterion (10 times, 20 seconds) are sufficient? Unless these are a scientifically proven values and are not likely to be changed in future, such values should not be included in a normative part of the document. 2.2.2 Is there any scientific fact that supports 3 seconds is sufficient? Unless this is a scientifically proven value and is not likely to be changed in future, such a value should not be included in a normative part of the document. 2.3.2 While 2.3.1 is written using the terms general flash threshold and red flash threshold, this success criterion is written with a specific number. Since the UW document is informative, and those values can be changed if needed, this way of writing could cause future inconsistency. If there is any possibility of these value to be changed in future, the specific value should not be mentioned in a normative part of the document. 4.1.1 When a Web unit is not valid, or not conforming to a specification, how can one be sure if the Web unit is able to be parsed unambiguously?