- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Wed, 10 Jun 2009 17:25:44 -0400
- To: WAI-AUWG List <w3c-wai-au@w3.org>
- CC: Loretta Guarino Reid <lorettaguarino@google.com>
- Message-ID: <4A3024D8.6080401@utoronto.ca>
Hi all, I'm going to make the following editorial changes marked JR: EDITORIAL. The rest I've loaded into a comments file (attached) and I will hopefully have proposals for them tomorrow. (ALSO hopefully Jeanne and I will get a fresh Editor's Draft containing the editorial changes out by the end of the week): Cheers, Jan Loretta Guarino Reid wrote: > Note: these are comments from a review that was separate from the WCAG > WG review. Issues that were already covered by the WCAG WG have not > been repeated here. There is a mixture of editorial and substantive > comments, listed in the order they occur in the document. > > * Is it clear how Guideline B.2.4 ("Assist authors with managing > alternative content for non-text content.") would apply to website > authoring tools? Is it clear how it would apply to content management > systems or photo repository sites? > > See comments below on specific issues with some of these SC. The > phrasing of B.2.4.2 leaves things a little vague wrt testing. "can > automatically suggest ... under the following circumstances" sounds > like it is also ok to suggest under different circumstances, or not to > suggest under these circumstances. > > * Does the Glossary definition of "prominence" provide guidance > for objective testing? > > See comment on definition for a problem with the current definition. > > * Do the new examples of authoring tools in the Introduction > sufficiently illustrate and differentiate between web and non-web > functionality? > > The examples are helpful for understanding the wide range of authoring > tools, and where authoring is a small piece of a larger application. > However, as commented below, I think the introduction doesn't clarify > web and non-web functionality, and that an authoring tool may be one > or the other or a mixture. > > * Are there any areas in which the guidelines may be lacking? > > No. > > > * Comment 1 (editorial): > In the "Understanding Levels of Conformance" section, "essential" is > described as > "even the authoring tool user interface cannot make content accessible" > I don't understand what this means, since the UI is not making the > content accessible. Perhaps this should be "the author cannot use the > authoring tool user interface to make content accessible"? JR: EDITORIAL > * Comment 2 (editorial): > Part A. Applicability Notes, item 2 (Reflected Content Accessibility Problems): > I found this paragraph difficult to understand from the wording. I did > finally understand the point, but it took work. Suggest: > "The authoring tool is responsible for ensuring that the content being > edited is accessible to people with disabilities (e.g., ensuring that > an image label in the content is available via the platform). However, > where an authoring tool user interface accessibility problem is caused > directly by a Web content accessibility problem in the content being > edited (e.g., if an image in the content lacks a label), then this > would not be considered a deficiency in the accessibility of the > authoring tool user interface." JR: EDITORIAL > * Comment 3 (editorial): > Guideline A.1.1: > > I can't understand the rationale; there is something odd about the way > the different ideas in the sentence are being related to one another. > Is this trying to point out that Web applications can be authoring > tools, and that they need to conform themselves? Does it only cover > web applications because this is a W3C web accessibility spec? > > * Comment 4 (editorial): > Guideline A.1.1, Applicability Notes: > Guideline A.1.2, Applicability Notes: > > In the applicability notes, perhaps you want to start with something > like "An authoring tool may combine web-based functionality with > non-web-based functionality." Or perhaps this distinction needs to be > introduced earlier. The use of "also" in the applicability note is > confusing, particularly without introducing the concept of > applications that are partly web-based and partly non-web-based/ JR: EDITORIAL > * Comment 5 (editorial): > Guidelines A.1.2: > Suggest dropping "that are not user agents" from the rationale. > Although by the glossary definition, user agents refer to renderers for web > content, I think the distinction between a browser that is displaying > web content and the same browser displaying a local HTML file will be > lost on most readers. JR: EDITORIAL > * Comment 6 (editorial): > Guideline A.2.2: > The rationale is very hard to understand again. "information signified > by presentation added by the authoring tool"? "content rendering > editing views"? > > > * Comment 7 (editorial): > SC A.2.2.3: > It is confusing that one of the examples used (text size) is > already covered by A.2.2.2. You might just omit the examples > completely as part of the success criterion. JR: EDITORIAL > * Comment 8 (editorial): > SC A.2.3.1 > "content rendering editing views" again. Maybe introduce this > concept in the introduction? and maybe use a simpler phrase? JR: EDITORIAL > * Comment 9 (substantive): > SC A 3.2.3: > Why is this limited to components that accept mouse input? > > * Comment 10 (editorial): > SC A.3.5: > It is confusing that the guideline says "for authoring tool user > interface" when the text search appears to address searching the web > content. The guideline seems to imply that users should be able to use > text search to find menu commands, for instance. JR: EDITORIAL > * Comment 11 (editorial): > Guideline A.4.1, Applicability notes: > Typo: "to to" JR: EDITORIAL > * Comment 12 (editorial): > Part B applicability notes #3: > It is very hard to understand the first sentence. > > * Comment 13 (substantive): > SC B.1.1.2: > What does it mean to provide Web content technology options? does > this mean choices of output format? > > * Comment 14 (editorial): > SC B.1.2.2 typo: "output of a the transformation" JR: EDITORIAL > * Comment 15 (substantive): > SC B 1.2.2 (a): > Why "if possible"? does this introduce testability problems? > > * Comment 16 (substantive): > SC B 2.2.1, 2.2.5, 2.2.9: > Do reasonable authoring tool checks exist for all success criteria? > This could introduce a lot of "noisy" checks that just ask authors to > perform a manual check. This tends to clutter up the checking workflow > and encourages authors to ignore it. JR: In the techniques we might want to emphasize that "Manual Checks" should be pushed to the user sparingly. > * Comment 17 (substantive): > SC B 2.2.2: > Is this checking the same checking as in SC 2.2.1? If so, is a > separate guideline needed? > > * Comment 18 (editorial): > Guideline B.2.2 Applicability notes: > I don't understand the comment about manual checking, and how this > relates to 2.2.1, etc. I hope this doesn't require "checks" of the > nature "perform the following manual check". > > * Comment 19 (editorial): > SC B.2.3.3: > What is "repair assistance"? What does it mean to provide it? Does > this just mean that it is possible to repair the error? > > * Comment 20 (editorial): > SC B.2.4.1 typo: This includes types of alternative content that may > not typically <ins>be</ins> displayed on screen by user agents. JR: EDITORIAL > * Comment 21 (editorial): > SC B 2.4.3: > Suggest using "data" or "values" rather than "text content", since the > latter sounds like it is limited to rendered content, while the repair > text is likely to be derived from some sort of metadata. > > * Comment 22 (substantive): > SC B 2.4.4: > Whose recommendations? It is hard to know whether you have met this SC > without knowing that, especially if there are conflicting > recommendations from different sources. > And for the specific example of null alt text, the authoring tool > can't determine whether a null alt is needed or is being used > appropriately. > > * Comment 23 (editorial): > Examples in the success criteria statements (e.g. parentheticals in > the success criteria) nearly always refer to text alternatives for > images. Are there any other > examples that could be used? One comes away with the impression that > authoring for accessibility is all about alt text.... > > * Comment 24 (substantive): > "Partial" conformance: > ATAG's use of the term partial conformance is different from WCAG's > use of the concept, which only applies when a web page contains > content that is > not provided by the author. Partial conformance does not mean that > only some of the SC at a level have been satisfied. Many people > misunderstand WCAG's partial conformance to mean something more like > ATAG's. Would it be possible to use a different term, to minimize that > confusion? > > * Comment 25 (substantive): > Conformance: > I suggest not including status as part of a conformance > claim. people should not be claiming conformance to a working draft. > > * Comment 26 (editorial): > Note on Required Components of an ATAG 2.0 Conformance Claim, item 4: > What is the significance of this note? The burden of what? The > substance was already covered by pointing out that anyone can make a > conformance claim. The note somehow implies that authoring tool > developers shouldn't be asked about their products. JR: EDITORIAL: Note: As stated above, the sole responsibility for the conformance claim is on the conformance claimant. It is not on the developer of any of the software components that make up the authoring tool. > * Comment 27 (editorial): > Required Components of an ATAG 2.0 Conformance Claim, 5(b): > Must a claim cover all the technologies that can be generated by an > authoring tool? can a claim be made for the use of a tool to generate > technology X? - oops, I see this is addressed by 59(d). Can (b) be > worded so it is clearer? Maybe "(b) A list of the Web content > technologies edited/produced by the authoring tool that are covered by > the conformance claim." > > * Comment 28 (editorial): > "Progress Towards Conformance" Statement: > Iit is extremely unlikely that developers will be able to provide > timeline information, even if they have > development plans. "encouraged" is ok, but will still probably be the exception. > > Glossary: > * Comment 29 (editorial): > Accessibility information: > "added to" - the implication being that the > information would not be present except to provide accessibility. Does > adding heading markup or other semantic mark-up count as accessibility > information? JR: EDITORIAL: Any information that Web content is required to contain in order to conform with WCAG 2.0 > * Comment 30 (substantive): > Prominence: > Bullet c) works if you are comparing the prominence of 2 > items, but when there are more than 2 items, it becomes impossible for > more than 2 to have the same prominence. This is a problem. the > definition probably needs to be generalized to groups of items having > the same prominence. > > * Comment 31 (editorial): > Appendix Editors: > Missing close parens: Roberto Scano (IWA/HWG JR: EDITORIAL -- Jan Richards, M.Sc. User Interface Design Lead Adaptive Technology Resource Centre (ATRC) Faculty of Information University of Toronto Email: jan.richards@utoronto.ca Web: http://jan.atrc.utoronto.ca Phone: 416-946-7060 Fax: 416-971-2896
Attachments
- text/html attachment: atag20_pubWD_21may2009_comment_responses.html
Received on Wednesday, 10 June 2009 21:26:34 UTC