ATAG Review archive 2013-Nov-08

Nav: EOWG wiki main page

This is an old archive of the ATAG Review wiki page

ATAG 2.0

ATAG 2.0 Last Call Working Draft
Note: It's ready for Candidate Recommendation so hopefully any suggestions are non-substantial copy edits.

[initials: response] comment {name}
[JS: This restriction to the user interface was necessary to avoid conflict with WCAG. That was not necessary in Part B.]Not sure why all the Part A Guidelines include " (For the authoring tool user interface)" but the Part B Guidelines don't specifically mention 'content production' or similar {Andrew, 2/Aug}
- [new comment] Can you move it to the end of the clause? Having it at the beginning of each SC decreases usability, including general readability skimming the TOC and especially for screen reader users. {Shawn}
The text generally seems tighter (at least the leading) than in WCAG 2.0 making it a little harder to read {Andrew, 2/Aug}
Viewing in Chrome 28 the 'implementing' boxes are overlaping the following Success Criteria {Andrew, 2/Aug}
[JS: Done. Changed inline numbering to (Part A) and (Part B) to set context for the reader.] Drop the inline list from the opening Abstract para - change to "This specification provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities and designed to enable, support, and promote the production of more accessible web content by all authors." {Andrew, 2/Aug}
[JS: Approved by AUWG #EO2] consider changing from "XYZ must ABC" to "XYZ are ABC", for example: from "Editing-views must be perceivable" to "Editing-views are perceivable" {Shawn}
[JS: done]Change PRINCIPLE to Principle, and PART to Part {Shawn}
[slh: no change] Introduction is very good. The description of overlapping user groups is effective. { Paul 7/30 }
[JS: done]Introduction, Notes, item 2: use of parens around "...and related terms, such as..." is awkward. Suggest removing them. { Paul 7/30 }
[JS: done]Introduction, Notes, item 2: "content that would conform to WCAG 2.0..." is missing close quote. { Paul 7/30 }
Introduction, Notes, item 4: Link to Components page appears incorrect, it leads to a manual redirect to http://www.w3.org/WAI/intro/components.php. Maybe need to add the .php to the link? {Suzette 8/2}
[JS: This was a difficult term that took many proposals to reach consensus. We define it normatively. ]A.3.7.1 (a) the term "in-market" is understandable, but seems slightly jargony and possibly misleading. In-market might be assumed to mean "commonly used" or "current" user agents. Many people use much older user agents that would not fit into the "in-market" classification. { Paul 8/2 }
- [new comment] At least link to the definition. {Shawn}
[slh: no change]Thrilled to see A.4.2. Documentation typically gets short shrift. { Paul 8/2 }
Spacing for div class "implementing-link" (the boxes with blue backgrounds that contain "Implementing X.1.2.3" links) overlap or crowd text that follows on the next line. I see this when viewing with Chrome v28, Firefox 22, and Safari 6 on a Mac. Also see this behavior on Windows 7 with IE9, IE8, IE7, Firefox 22, and Chrome 28. See it also on Windows 8 with IE10, Firefox 22, Chrome 28. Maybe add padding or margin? { Paul 8/2 }
[JS: done] Typo in conformance section: The first is "[i]f accessibility support (brackets around "i") { Paul 8/2 }
[JS: done] Typo in conformance section: The second is "[c]onformance to WCAG 2.0 (brackets around "c") { Paul 8/2 }
[JS: done] Typo in conformance section: "This conformance option may be selected when an authoring tools..." tool should be singular { Paul 8/2 }
[JS: done]In the intro, a sentence reads "For example, when a user ...they frequently..." The tense does not agree. Change to plural "users" or singular "he (or she) frequently."{Sharron 8/6 }
[JS: done] Guideline A.3.1 Rationale: Change from: "...are not able to use a mouse" to "...do not use a mouse" {Sharron 8/6 }
[JS: done] Guideline A.3.1.2 No Keyboard Traps: Is there a reason not to make two sentences of this one long sentence that seems to be about two separate things? {Sharron 8/6 }
Guideline A.3.7 Agree with previous comment about the use of "in-market" {Sharron 8/6 }
[JS: Approved AUWG #EO3] Guideline B.3.1.2 I don't understand this "instructions are provided from the check" - this phrase needs clarification. {Sharron 8/6 }
[JS: done] B.3.2 "Rationale: When repair as an integral part..." Does it mean to say "...repair [is] an integral part...?"{Sharron 8/6 }

[JS: the gray is an artifact of the editors draft. It will be removed from the WD. ] Some text is gray. (I assume you see that as well; however, if not, let me know and I'll help figure it out.) {Shawn}
Appendix B: How to refer to ATAG 2.0 from other documents -- you might be able to delete this section all together and instead point to Referencing and Linking to WAI Guidelines and Technical Documents {Shawn}
Suggest limiting use of italics. unitalicize glossary terms. (I also didn't like the <h5s italicized, but didn't quickly come up with a good solution for distinguishing them otherwise.) {Shawn}
"Guidelines title, version and URI "Authoring Tool Accessibility Guidelines 2.0 at @@" -- the @@ looks like an error to most people not familiar with our use of that as a placeholder. {Shawn}
[more than editorial] Suggest changing "but" in "an explanation is optional, but strongly recommended." Maybe "an explanation is optional, yet strongly recommended." or "an explanation is strongly recommended, yet not required." {Shawn}
"Conformance
This section is normative.
...
Conformance Requirements
This section is normative."
Since you have normative under the <h2, you don't also need it under the <h3 {Shawn}
[more than editorial] "5. Accessibility of features provided to meet Part B: The Part A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation)." I wonder if this would fit better in the Part A section? {Shawn}
[substantial] fyi, I don't at all understand 6. Unrecognizable content:... {Shawn}
Suggest limiting use of abbreviations given the international audience. "e.g." -> "for example", "i.e."-> "that is", etc. (pun intended ;) {Shawn}
Add comma before conjunction ("and" etc.) in "success criterion, examples and links to related resources" and throughout. (It is in some places but not others.) {Shawn}
[substantial] "Each guideline includes a brief rationale for why the guideline was included." Sorry I missed that in previous drafts. We talked WCAG into putting that in Understanding for several reasons -- primarily because it can be updated much more easily since it's a Note. I would encourage you to move those into Implementing ATAG or other — but maybe too late now :( {Shawn}
"within that part (refer to Part A Conformance Applicability Notes and Part B Conformance Applicability Notes)" ->"within that part: Part A Conformance Applicability Notes and Part B Conformance Applicability Notes)" {Shawn}
"In order to meet the varying needs of this audience" -> "In order to meet the varying needs of these audiences" {Shawn}
throughout: "refer to..." I suggest simpler "see..." {Shawn}
Delete "i.e., " in: "...highest level of WCAG 2.0 (i.e., Level AAA) may not..." {Shawn}
Delete comma in "It is important to note that, while the requirements for meeting these two sets of user" {Shawn}
"Accessibility, from an authoring tool perspective, includes addressing the needs of two overlapping user groups with disabilities:" -> "Authoring tool accessibility addresses the needs of two overlapping user groups with disabilities:" {Shawn}
[more than editorial] Intro says: "accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and others." Consider using our latest wording: "accessible to people with disabilities, including auditory, cognitive, neurological, physical, speech, and visual disabilities." {Shawn}
[SC edit] All the SC are imperative except one: "Editing-view presentation can be programmatically determined" I suggest editing it to be imperative for flow. {Shawn}
missing hyphen: "B.1.1. Ensure automatically specified content is accessible" ->"B.1.1. Ensure automatically-specified content is accessible" and probably "that" ->"B.1.1. Ensure that automatically-specified content is accessible"{Shawn}
- [SC edit] Some SC that start with "Ensure" have "that" and others don't. I think it reads better with "that" and suggest including "that" to all "Ensure" SC. Although i don't feel strongly about that. :-) However, I do think it would e good to be consistent.
missing comma: "A.4.2. (For the authoring tool user interface) Document the user interface including all accessibility features" -> "A.4.2. (For the authoring tool user interface) Document the user interface, including all accessibility features"{Shawn}
delete comma in: "A user agent, that can be procured by members of the public (free or otherwise)"{Shawn}
Add a link to the ATAG Overview near the top of the Introduction, and probably at the end of the Abstract.
I think you can delete from the abstract "The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI)." {Shawn}
Abstract starts out: "This specification provides..." At some point Michael said he wasn't comfortable calling WCAG a specification, and I think that would apply to ATAG. How about changing it to "This standard provides..." {/me reads WCAG abstract...} Actually, probably best to change "This" so it reads: "Authoring Tool Accessibility Guidelines (ATAG) 2.0 provides..." or "The ATAG 2.0 standard provides ..." {Shawn}
[just fyi, don't think it's worth spending time on] "Neither W3C, WAI, nor AUWG..." stopped me. I'm not sure that's correct usage with 3 things. It might be better "Neither W3C, nor WAI, nor AUWG" But I didn't take enough time to get a definitive answer. {Shawn}
I ran out of steam and didn't look at the Glossary or the Guidelines themselves — but I expect any changes on those would risk being more than editorial, so I will probably just skip those sections. {Shawn 8 August}

ATAG Overview

Docs:

Comments on Sept 2013 update

maybe add something about the motivation for ATAG -- the elevator pitch -- e.g., when tools help with accessibility, it saves millions of developers work {Shawn}
comment {name}

Comments on old version

[done] Introduction says:
ATAG is part of a series of accessibility guidelines, including the Web Content Accessibility Guidelines (WCAG WG) and the User Agent Accessibility Guidelines (UAAG)."
Delete WG from the WCAG acronym, or add it to UAAG and explain what WG means for new readers.
For conssistency, it would be useful to link to WCAG as the doc links to UAAG. {Sylvie, 2 August}
[done] Change "What is in ATAG 1.0" to "What is in ATAG 2.0" and point to new ATAG at a Glance {Shawn}
I concur - seems confusing to first point to old version {Howard, 1 August}
Agreed, I was indeed confused, time for the new version to be promoted and this section to be updated{Suzette August 5th}
[done] Add info about Implementing ATAG doc {Shawn/Jeanne}
[done] Intro - second paragraph - bullet out 2 parts, eg: (ATAG) 2.0 provides guidelines for designing web content authoring tools that are both:
- more accessible to authors with disabilities and
- designed to enable, support, and promote the production of more accessible web content by all authors.{Shawn/Jeanne}
[done] Add something like: ATAG 2.0 is organized into layers:
- Parts: Part A provides a more accessible tool and Part B produces more accessible content
- Principles: high level Principles that organize the guidelines
- Guidelines: basic goals that developers should follow
- Success criteria: testable statements that the authoring tool meets {Shawn/Jeanne}
[above] Agree with Shawn and Jeanne that the layering / hand-in-hand nature of parts A and B is important to point out. { Paul 8/2 }
[done] In "Who is it for" good to see mention of CMS - given it is such a prevalent way of working on big commercial/government websites I would like to see that item near the top of the list.{Suzette, 2nd August}
[done] Typo in "Who ATAG is for" content managements systems should be content management systems (remove s from management) { Paul 8/2 }
[done] First section link is not connecting, message states: for "Essential Components of Web Accessibility" is: www.w3.org/WAI/intro/components.php {Suzette, 5th August}
[done (back when we did usability testing, this was a significant issue] Not sure of the purpose of "Technical document format" section in this Overview. Is it needed or could it be omitted? {Sharron, 8/6}
[above] Agree with suggestions to lead with ATAG 2.0 rather than ATAG 1.0 and to reference the layers of organization{Sharron, 8/6}

ATAG at a Glance

Docs:

Comments after 9 Sept

comment {name}

Comments before 9 Sept

[done] Next to last bullet item under "Editing-views must be operable" needs rewording. "Manage preference settings" should be something like "Allow author to manage preference settings" or "Allow keyboard access to preference settings"{Howard, 1 August}
It looks like the same wording is in the ATAG 2.0, the context there seems to indicate the intention is "Allow authors to manage own preference settings." {Suzette, 5th August}
[done linked to editing-view & got rid of in-market] link to glossary for "Editing-Views" and "in-market user agents" would be helpful{Howard, 1 August}
[done. added the number and linked that -- see Suzette's comment below about liking that there are *not more links ;-] When reviewing this I wished I could link from bullet items to more information. What about linking bullet points to appropriate place in ATAG 2.0?{Howard, 1 August}
I agree. {Shawn}
[above] Agree with Howard's comment above about "in-market user agents." I mentioned this above in the ATAG 2.0 comments: the term "in-market" is understandable, but seems slightly jargony and possibly misleading. In-market might be assumed to mean "commonly used" or "current" user agents. Many people use much older user agents that would not fit into the "in-market" classification. { Paul 8/2 }
[above] Agree{Sharron 8/6}
[no change] This document is about as tersified as it can be! It's very concise. { Paul 8/2 }
[wording matches latest version (not sure which was changed ;-] Part B heading "Part B: Produces Accessible Content" is inconsistent in its 'voice' from Part A and is different from ATAG which has "PART B: Support the production of accessible content". Personally, I prefer the original. Also, there is inconsistent use of capitals between Part A and B titles{Suzette, 5th August}
[above] Agree {Sharron 8/6}
[no change] At a Glance is a good and useful summary of the main elements of ATAG. I like it being link free - it is so much easier to read (at a glance) especially for the easily distracted (like me), and if you want the whole thing, then there is just one link at the top.{Suzette, 5th August}

Implementing ATAG

Implementing ATAG 2.0 Working Draft

Intent includes implementations notes — It looks like some of the "Intent" sections combine two things: 1. Why this is important for accessibility, 2. info on implementation, conformance, and/or the requirement. (for example: A212)
It would be good to separate these into at least 2 separate sections.{Shawn}

Appendix B: Levels of Checking Automation - my first impression is that quite a lot rests on encouraging or facilitating authors to check their progress, and that in any case, feedback is an integral part of any design or development activity. This Appendix with its discussion of automated and manual checking has an important role in understanding how to implement ATAG 2.0 but I feel the title is underselling the content. I would propose that 'Automatic and Manual checking' is the start of the title, and if necessary the concept of levels is a subhead, or sub clause. Is there a list which analyses which or how many success criteria can be evaluated automatically? {Suzette 8/2 or Aug 2nd}
It says that "The Working Group seeks feedback on the following points for this draft:
- Is the overall document a useful resource for implementers to apply ATAG 2.0 to your product? {SR comment: yes there are very useful pieces of information within this document. However, it is probably less useful than it might be because of the need to follow the Guidelines format. This results in a narrative that is excessively wordy and hard to follow. I am not sure that software developers - toolmakers - would wade through all of the extraneous verbiage to get to the kernel of actionable information and implementation guidance. Other than a less wordy Quick Guide, I am not sure what to suggest.}
- Are the sections describing the intent of each success criteria clear? {SR comment: Overall, yes the intent sections are generally quite good. Once question about the use of the term "More accessible,"used in A.1.2.1 and A.1.2.2. Why say "more accessible" rather than simply "accessible?".}
- Do you have any suggestions for examples that should be added, modified or removed? {SR comment: Yes, I would like to see more examples from courseware, from teaching and learning tools used by both students and teachers.}