| Guideline |
Success Criteria |
Comments |
AUWG Responses |
|---|
| General |
|
- WCAGWG: Consolidate WCAG 2.0 related SC: A number of the guidelines include SC that reference conformance to WCAG 2.0 at various conformance levels. Consider combining these to reduce the overall number of success criteria and to minimize repetition and cross-references in the implementation guide. For example, combining the three SC listed in A.1.1 might look like: A.1.1.1 Web-Based Accessible (WCAG Conformance): Web-based authoring tool user interfaces conform to WCAG 2.0 at one of the following conformance levels.
* Level A: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A)
* Level AA: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA)
* Level AAA: For Level A conformance, web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA) A similar approach should be considered for the B.1.1.x, B.1.3.x, B.2.2.x, B.2.3.x, B.2.5.x, etc.
- JM: I do suggest that it make clear that an authoring tool should produce accessible content with its default settings. Currently, I interpret the guidelines as recommending that such settings be as prominent as other configuration choices. I think it is important, however, that an author has to make a conscious decision to depart from a mode in which accessible content is the result. In this way, accessible content is the norm for developers who do not think about accessibility and use the authoring tool as is, without customizing its settings. I also suggest that the guidelines incorporate more explicit references to web 2.0-type web pages that create value from user-generated content. On such a page, the reader is often an author as well. The user agent, e.g., web browser, is an authoring tool, too. The user may enter text, upload audiovisual media, or simply express preferences -- e.g., rating an article. This combining of reading and writing capabilities blurs distinctions between audiences of the Authoring Tool Accessibility Guidelines and the User Agent Accessibility Guidelines. Spontaneous, user-generated content makes it more important than ever that accessible content is produced via default settings of both live user agents and offline authoring tools.
- AC: I think it is relevant to explain to readers why the two seemingly independent requirements, of (1) access to authoring tools and (2) production of accessible content, are covered in the same document. I remember once someone from WAI (Judy or Shawn?) explain something along the line that only when people with disabilities can create Web content in equal conditions will web accessibility become a reality. ATAG 1.0 contains a partial explanation, "Since the Web is both a means of receiving information and communicating information, it is important that both the Web content produced and the authoring tool itself be accessible." With the current trend toward user-produced content this is now even more true than when ATAG 1.0 was published (see Jamal's comment [1] about Web 2.0 content). This idea of a two-way process is the clearly (to me) the reasoning for including both requirements in the same recommendation, but an explanation seems to be needed.
|
- @JR: We should consider this.
- @JR: A possibility would be to add more text to the Implementing doc explaining how it is important to see auto-generated content and suggestions to users in the context of later accessibility checking. Users will be very annoyed if things done by the tool or suggested by the tool later throw errors. That's a good point that we've tried to work in. Some things that are necessary in a tool like Dreamweaver wouldn't be in a tool that let's you choose a rating-level and write a short text review. We hope we've achieved a good balance (e.g., the wording of B.2.2.1 Check Accessibility (WCAG Level A):)
- @JR: I think we can address why the two parts are in the same document by modifying this part of the Introduction: Accessibility, from an authoring tool perspective, includes addressing the needs of two overlapping user groups with disabilities: * authors of web content, whose needs are met by ensuring that the authoring tool user interface itself is accessible (addressed by Part A of the guidelines), and * end users of web content, whose needs are met by ensuring that all authors are enabled, supported, and guided towards producing accessible web content (addressed by Part B of the guidelines). It is important to note that, while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that in reality they are deeply inter-connected. For example, when a user participates in an online forum they frequently author web content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the web content produced by the other forum users would reduce the overall accessibility of the forum.
|
| Conformance |
|
- WCAGWG: Required Components of an ATAG 2.0 Conformance Claim #5 (Authoring tool information): Consider adding information about the role and requirements for information about extensions, plugins or modules that may have modified or extended the authoring tool to meet a requirement.
- WCAGWG: Required Components of an ATAG 2.0 Conformance Claim #6 (Web content technologies produced): Consider dropping the requirement for a list of technologies not included as this can be derived from the list of technologies that the tool is capable of producing when compared to the list of technologies included in the claim.
- WCAGWG: Required Components of an ATAG 2.0 Conformance Claim #7 (Declarations) and Checklist: This requirement implies that each claim would have to list each SC that is met. It should be possible to declare a range of SC that have been met. (ex. All Level A). Additionally, inviting claimants to declare success criteria that are not applicable may be a slippery slope and often leads to inaccurate claims. Instead, suggest including a statement that says that where an authoring tool does not include a feature that is relevant to a given SC, then that SC is automatically satisfied.
- WCAGWG: Waiving of WCAG 2.0's conformance requirement #4: Only Accessibility-Supported Ways of Using Technologies. Many of ATAG's success criteria rely on conformance with WCAG 2.0 but allow for information or functionality provided in a way that is not accessibility supported. This is potentially quite a loophole and can easily mislead (intentional or not) the intended audience regarding the production of content that conforms to WCAG 2.0.
- GG: Conformance claims: Is there going to be a Conformance Claim program to validate claims made by developers, and by others representing authoring tools? ATAG differs from WCAG in claims made in that WCAG is easily checked with a variety of tools to confirm conformance claims. Such a tool does not exist to confirm ATAG conformance claims. Experience with the claims process for another standards organization I'm involved with, raises questions about the "honesty" of claimants, or perhaps the "scope" of a particular claim that omits points of failure. Self-claims are easy to make, but they don't hold much clout, and they can easily deceive or mislead potential users. As a purchaser of an ATAG conformant authoring tool, I'd want something more than a self-claim. A dishonest developer could potentially have a competitive advantage over an honest one. Perhaps there should be a distinction between self-reported compliance, and W3C (or another granting body) endorsed compliance. Or, perhaps setup something that legally binds a claimant, such as submitting a claim through a central, perhaps W3C, claims site, where they must agree to a legal statement before making a claim. This would discourage invalid claims, and potentially provide recourse in the event that a fraudulent (or less than complete) claim is made to the detriment of other developers or users of an authoring tool.
- MS: The biggest concern for ATAG 2.0 is that it is never clear if ATAG is for a single tool or a collection of tools. It is trying to be both. This leads to a great deal of structural problems. If it is for a single tool, then the SCs are too far reaching and the conformance requirement does not make room for a simple specialized tool to conform. How does ATAG 2.0 conformance work for something like a web accessibility toolbar, photo editor, FTP client, or a social networking site? You need to allow tool makers to say their tool does not provide certain function and it is not intended to do so, but the tool conforms where it is applicable. On the other hand, how would conformance work for a collection of tools where some criteria are met via a portion of the tools? Would one have to specify which tool(s) is used to conform to any given criterion? If the collection of tools include tool(s) in which the conformance claimer has no Intellectual property ownership, would the claimer then be held responsible for the accuracy of the claim of such tool? What if is there is discrepancy between the tool manufacturer and claimers? What if the collection is still not applicable to ATAG in full—for example, only relevant to part A? Is the collection deemed incomplete? Additionally, where does the value chain of the authoring process end? Without knowing the scope, then ATAG 2.0 may require consideration of software such as scanner application, a database, a web service, or enterprise backend systems. Does a mail client become a “web authoring tool” only when it sends a message to somebody who access their email via the web? How is one supposed to know if the mail recipient uses a web client? These are extremely difficult questions. But if left unanswered, ATAG 2.0 will not be viable in practice. The conformance section requires fundamental revision to be viable. Please revise accordingly.
- Conformance Condition 1 WCAG 2.0 does not require conformance claim be made in the web or not. This condition is unnecessary. Please remove condition.
- Conformance Condition 6 This is an “encouragement”. Thus, it does not belong to the normative part of the ATAG 2.0. Please move condition 6 to non-normative part of ATAG 2.0
|
- @JR: I think the note covers it, but we could try to be more clear. (change request is not substantive)
- @@JR: Sometimes tools "Save As" some formats and "Export" to others etc. It would be easier for the reader of a conformance claim to know what the Claimant thought they were. (change request may not be substantive)
- @@JR: Personally, I think it is more clear to have to address each SC individually. In addition, I think "automatically satisfied" is more "slippery" because it leads provides less information as to the thinking of the Claimant. (change request is substantive)
- @@@JR: I understand the concern, but the cross-cutting nature of authoring tools makes it very difficult. Not sure how we can handle this. Maybe a separate link from all instances of "conform" to a clarifying note? Maybe expanding the explanatory text in the relevant section "Note on 'accessibility-supported ways of using technologies'"? (change request is likely substantive)
- @JR: I agree it's an issue, but out of scope.
- @@@JR: Needs lots of discussion. (Suggestion is a substantive change)
- @@ JR: Conformance claims are optional.
- @@JR: Could be moved to a note.
|
| Glossary |
|
- WCAGWG: Many of the defined terms in ATAG 2.0 differ from those in WCAG 2.0 and/or make notes and examples from the WCAG 2.0 definitions a part of the definition itself in ATAG 2.0 . We found the resulting definitions confusing. We suggest synchronizing and formatting these definitions so that they are consistent across the WAI guidelines. Examples include "keyboard interface," "label," "non-text content" etc. There were only three terms that were different enough to warrant a review. We are concerned that it may not be clear to readers that these definitions are intended to be the same. We would encourage you to use the WCAG definitions as closely as possible, augmented by additional information needed to address ATAG-specific considerations:
- WCAGWG: assistive technology...
- WCAGWG: programmatically determined...
- WCAGWG: non-text content ...
|
- @@JR: Need to discuss. The WG felt that changing the phrase+notes structure of WCAG's definitions to sentences was more clear. Maybe we should put in a general note that we didn't intend to change the sense of definitions unless noted (and then note the exceptions).
- @JR: I think I'm ok with this. Needs discussion.
- @JR: I think I'm ok with this. Needs discussion.
- @JR: I think I'm ok with this. Needs discussion.
|
| A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible. |
|
- GG: Guideline A.1.1 et al "[For authoring tool user interface]" the square brackets could potentially create confusion, given ATAG is aimed primarily at a developer audience. For developers the square brackets [] generally represent optional values. Parentheses would be less likely to be confused.
|
- @JR: Maybe "()" instead? Although it contributes to wordiness, I support keeping the " the authoring tool user interface" clause in the guidelines (perhaps using "()") to keep it as clear as possible what part of the document the reader is in.
|
| A.1.2 [For the authoring tool user interface] Ensure that non-web-based functionality is accessible. |
|
- WCAGWG: A.1.2.1 While we agree with the approach and the rationale cited in the implementation guide, this SC, specifically "...and/or platform conventions..." may not be testable. How does an authoring tool developer determine whether they have followed enough platform conventions to pass? Suggest revising this SC to make it more testable and adding additional detail to the implementation guide to clarify what would be required.
|
- @@JR: Obviously it's not a "number" issue. If we say "At least one" it would be testable and we could back it with more explanation. (change request is substantive, my suggestion would not be)
|
| A.2.1 [For the authoring tool user interface] Make alternative content available to the author. |
|
- UAWG: (and other SC) this and other success criteria were at time very hard to understand (for us it depended on the line breaks). suggest changing 'editing view' to 'editing-view'. it may help the reader understand the content rendering and alternative content are in the editing-view. We believe the clearest wording for the SC would be "is available when rendering content in editing views", if you can adopt the phrase "rendering content" as equivalent to "content rendering".
- MS: A.2.1.1 The success criterion needs to have simplified languages. We cannot determine its meaning without reading through the implementation guide. Rewrite the success criterion to make it more comprehensible.
|
- @JR: Ah yes...it's a view for editing, not someone editing the view. I'm ok with "editing-view". I'm also ok with the suggested re-wording. (not substantive change)
- @JR: Following UAWG comments, perhaps: "Recognized alternative content is available when rendering content in editing-views." (Suggestion is not a substantive change)
|
| A.2.2 [For the authoring tool user interface] Editing view presentation can be programmatically determined. |
|
- WCAGWG: A.2.2.2: Consider adding background color to the list of minimum presentation properties for text.
- MS: A.2.2.1: “Additional information” is undefined. In order to determine what is considered additional information, one must know what is considered baseline information. We realize that AUWG considers underlining of misspelled words to be a piece of “additional information”, but there is no way to tell what is it that makes such information qualified as being “additional”. This will make it impossible to determine if the criterion is met.. We can at best project the concept into the similar scenarios for grammatical errors and coding errors—purely because it is an educated guess. Define “additional information” to make it objectively testable or revise the success criterion.
|
- @@@JR: (change request is substantive)
- @JR: Perhaps: If an editing-view modifies the presentation of web content to provide additional information to authors, then that additional information can be programmatically determined. (Suggestion is not a substantive change)
|
| A.2.3: Ensure the independence of the authors' display preferences. |
|
- JC: This statement seems contradictory. A personalized view for the authoring tool that displays content differently from the the view to be published, by definition, CANNOT be considered WYSIWYG. I also believe this requirement puts undue burden on the user interface design of the authoring tool, because it's difficult for a simple, usable UI to accurately convey that this-is-your-own-view-of-the-content-but-its-not-the-same-as-what-will-be-published… WYSINRWYG: What you see is not really what you get. I don't agree that this is necessary, and I'd recommend downgrading this from a Level A requirement to a Level AAA suggestion. Perhaps this could be changed to remove the confusing reference to WYSIWYG: "Authors can set their own display settings for alternate editing views without affecting the web content to be published." If that change were made, I could accept this as a Level A requirement.
- MS: A.2.3.1 This criterion should be consolidated to A.3.6. Move A.2.3.1 to A.3.6
|
- @@JR: I agree that "(including WYSIWYG views)" might be confusing (and could be removed). Perhaps instead we discuss the situation in the Implementing 2.0 doc. Essentially, WYSIWYG is a bit of a misnomer because the end-user can quite often modify what they get. We just want to say that the author should similarly be able to modify what THEY get as they author the content.
- @JR: Agreed. (Suggestion is not a substantive change)
|
| A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features. |
- A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface, except where editing web content properties that encode continuous input.
Note 1: This exception relates to the nature of web content, not the usual input technique. For example, setting the path of a freehand curve is exempt, while setting the endpoints of a straight line is not.
Note 2: This should not be interpreted as discouraging mouse input or other input methods in addition to the keyboard interface.
- A.3.1.2 No Content Keyboard Traps: Keyboard traps are prevented as follows:
(a) In the Authoring Tool User Interface: If keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard keyboard navigation commands (e.g., TAB key); and
(b) In Editing Views that Render Web Content: If an editing view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus).
|
- JC: re: A.3.1.1 Please change "Keyboard Access" to "Keyboard Equivalent Access" and change "keyboard interface" to "keyboard equivalent interface."For example, all functionality of iOS and accessible iOS applications is available through a keyboard equivalent and is accessible through multi-sensory output (sight and sound, and touch if using a external braille display), and does not require a standard keyboard interface to be accessible. Example: See Victor Tsaran's demo of iPhone4/iOS4 with an external braille display. http://www.youtube.com/watch?
v=6_TFHqIHBqM
- MS: A.3.1 There should be exception and consideration for authoring environment/OS where there is no keyboard.Either add a condition for environment/OS with keyboard or add an exception.
- MS: A.3.1.1 Why does the language differ from WCAG “except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints” Either reconcile the difference or provide rationale for the difference.
- MS: A.3.1.2 Why does the language differ from WCAG “...if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away." Either reconcile the difference or provide rationale for the difference.
|
- @@JR: I agree and this probably deserves an example in the Implementing ATAG 2.0 doc.
- @@JR: Even platforms with no physical keyboard have keyboard interfaces. (Suggestion is a substantive change)
- @@JR: Rationale: The ATAG version takes into account that it is not simply the path that might be continuously sampled. A stylus might also continuously sample the force, angle and speed of the input device. (Suggestion may be a substantive change)
- @@JR: We could use the WCAG 2.0 language for (a). The rationale for (b) is that the content being rendered might include keyboard traps. (Suggestion may be a substantive change)
|
| A.3.2 [For the authoring tool user interface] Provide authors with enough time. |
- A.3.2.1 Data Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool saves all submitted content edits made by authors.
- A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one of the following is true:
(a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or
(b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
(c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and authors are allowed to extend the time limit at least ten times; or
(d) Real-time Exception: The time limit is a required part of a real-time event (e.g., a collaborative authoring system), and no alternative to the time limit is possible; or
(e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or
(f) 20 Hour Exception: The time limit is longer than 20 hours.
- A.3.2.3 Static Pointer Targets: User interface components that accept pointer input are either stationary or authors can pause the movement.
|
- JC: re: A.3.2.2(F): Minor: I'm pretty sure the 508 refresh requires 8 hours for the exception, not 20. If you have a good reason to refute 508, please file a comment on that requirement. Otherwise, I'd suggest remaining consistent and using the 8 hour exception.
- WCAGWG: A.3.2.2 Timing Adjustable: What would be an example of an authoring tool time limit where extending the time limit would invalidate the activity (e)?
|
- @@JR: We're not refuting but rather remaining consistent with WCAG 2.0. Frankly, the number is pretty arbitrary either way. This requires discussion.
- @JR: Authoring something as part of a exam perhaps.
|
| A.3.3 [For the authoring tool user interface] Help authors avoid flashing that could cause seizures. |
- A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in editing views can be turned off.
|
- MS: A.3.3.1 It should be recognized that there is a fundamental conflict between the necessity to view the animation during animation editing process and the need to disable animation to prevent seizure. This cannot be at level A in its current form. Is this applicable to non-visual time based content too? If so, what is the rationale? Move the SC to AA or AAA, explain that there is a potential for fundamental alteration, and to exclude all non-visual time-based content.
|
- @@JR: Agree that it needs to visual-only. The requirement is not meant to rule out animated interfaces. A stop button is sufficient. Perhaps it would be more clear to say that animations shouldn't start to render auomatically (e.g., on loading them and then once the user starts the animation, they should be able to stop it). (Suggestion is a substantive change)
|
| A.3.4 [For the authoring tool user interface] Enhance navigation and editing via content structure. |
|
- MS: A.3.4 Given that the purpose of these success criteria is to “…simplify the task…”, they should not be level A. These are AA or AAA criteria. Move all A.3.4 SCs to AA or AAA.
- MS: A.3.4.1 Most web-based authoring tools (think of social networking sites and blog sites) do not allow users to create or control structures. There should be exemptions for authoring tools that do not allow structural edits. Add exemption for tools that does not allow control of structure or condition for tools that allow so.
- MS: A.3.4 Does this apply to all structures or some structures? There is no indication one way or the other. All structure does not make sense. Clarify that this is not required for all structure.
- MS: A.3.4.1 & A.3.4.2 What does “make use of” means? Please provide definition.
|
- @@JR: Something to discuss, but for some users an ordinate number of keystrokes is a very serious barrier. (Suggestion is a substantive change)
- @JR: It already says editing views for Structured web content. If the web content isn't structured it doesn't apply. We could add further clarification. (Suggestion is not a substantive change)
- @@JR: See above.
- @ JR: This is clarified in the implementing document. (Suggestion is not a substantive change)
|
| A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents. |
- A.3.7.1 Return Mechanism: If a preview is provided, then authors can return from the preview using only keyboard commands.
- A.3.7.2 Preview: If a preview is provided, then at least one of the following is true:
(a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or
(b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].
|
- WCAGWG: A.3.7.2 Preview: As worded, it appears that a UA that utilizes any third-party user agent for preview would automatically meet this SC. Suggest that part (a) be revised to require the use of the author's default user agent, which would avoid a situation where the author is unable to preview content in the UA that best meets their accessibility needs.
- UAWG: Suggest changing (a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or to be (a) Third-Party User Agent: The preview makes use of an existing third-party accessible user agent; We think a clearer, less subjective wording for may also be "The preview makes use of an existing third-party user agent that conforms to the User Agent Accessibility Guidelines Level A; or". However, we should also acknowledge that the authoring tool may allow the user to configure which third-party user agent should be used, and should be able to pick an accessible one but should not be prohibited from choosing an inaccessible one. I haven't had time to draft wording that entirely works.
- MS: A.3.7.1 This criterion is redundant to A.3.1.2. Please remove the criterion.
- MS: A.3.7.2 Please remove the term “third-party” from option A. It is not appropriate. This is saying that Microsoft cannot use IE; Google cannot use Chrome; and Apple cannot use Safari. Please remove the term “third-party” completely.
|
- @@JR: We had wanted to leave this up to developers - e.g. to embed user agents directly into the authoring tool UI (change request is substantive).
- @@JR: Actually the logic is a bit different...it's that previews are meant to show how content will appear to end users in the "real world" - i.e. in an existing user agent where the user agent accessibility is the user agent developer's concern. (a) is the straightforward way to provide this. But if the authoring tool developer wants to depart from existing user agents, then the accessibility of that new user agent becomes THEIR concern and so UAAG would apply.
- @ JR: Agreed. Perhaps with a note in A.3.1.2 mentionning preview. (Suggestion is not a substantive change - since the normative requirement stays the same)
- @@JR: We need a term that distinguishes "user agents" in the marketplace from something developed from scratch. (Suggestion is not a substantive change)
|
| A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes. |
- A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to the authors that the action is irreversible.
Note 1: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action.
Note 2: It is acceptable for certain committing actions (e.g., "save", "publish") to make all previous authoring actions irreversible.
- A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible.
|
- MS: A.4.1.1 How many layers of undo are needed to meet the criterion? Since it is unspecified, we assume one is adequate. Please specify if more than one layer of undo is needed to satisfy the SC.
- MS: A.4.1.1 “Undo” is normally not feasible for many scenarios for basic web form authoring tool or it depends on the browser to carry out the undo. In reality, most actions are reversible without having the “undo” function. If action is reversible, then why impose the specific function of “undo”? Change the SC to read: “Authoring actions are reversible or include warning to authors that the action is irreversible.”
- MS: A.4.1.1 This SC requires a warning every time the user execute a file save or the like. This runs against user expectations and will become a serious annoyance. Please add exception for the like of file save from having to give warning.
- MS: Definition of Authoring Action It is hard to see what an author can do with the tool that is not considered authoring action. Please provide examples of non-authoring actions. Please provide examples of what is not considered authoring action and tighten the definition as necessary.
- MS: A.4.1.1 What is the definition of “committing action”? Please add definition
|
- @JR: One is sufficient, we can work it in. (Suggestion is not a substantive change)
- @JR: Ok to keeping reversible but dropping "undo" by name. (Suggestion may be a substantive change)
- @JR: Needs discussion. (Suggestion is a substantive change)
- @JR: The existing defintion seems ok and includes examples of non-authoring actions: "Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., setting preferences, viewing documentation)." (Suggestion is not a substantive change)
- @ JR: We mention save and publish. Of course certain systems like Wikis keep previous content past "committing actions". Perhaps we just say "Save". (Suggestion is not a substantive change)
|
| A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features. |
- A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are documented.
|
- WCAGWG: A.4.2.1 Document Accessibility Features: Suggest incorporating the accessibility of the documentation in the SC text itself or include the note from the implementation guide, "The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." with the SC.
|
- @JR: Agree with adding note. (change request is not substantive).
|
| B.1.1 Support web content technologies that enable the creation of content that is accessible. |
|
- GG: B1.1.1 (2/3) wording may be too general. E.g. one could use a tool to create WCAG conforming content (if they don't use the table editing features, or don't use the insert Flash feature, for instance). Perhaps add language to include "all" editing functions produce conforming content.
|
- @JR: Wording is meant to be general...the more specific details are dealt with later.
|
| B.1.2 Ensure that the authoring tool preserves accessibility information. |
|
- WCAGWG: B.1.2.2(a): "Option to Save: authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input);" It would be great to add "accessible" to "authors have the option to save the accessibility information in another [accessible] way."
- MS: B.1.2.2 Condition b is absolutely not possible if the output is a third party format. This SC essentially asks authoring tool makers to judge and make claim to users which format is less accessible. It would require constant update to keep such info up-to-date and the potential liability of claiming one format is less accessible than another is not something that any manufacturer can accept, especially when it comes to 3rd party format. Please remove condition b.
|
- @@JR: Need to discuss: Accessible to whom? The author or the user? (change request may be substantive).
- @@@JR: It already says "web content transformation cannot preserve recognized accessibility information". If that info is lost, an accessiblity problem is already present. Maybe we make it even more clear and say where "accessibility information is not included" in the output. (Suggestion is a substantive change)
|
| B.1.3 Ensure that automatically generated content is accessible. |
|
- WCAGWG: Guideline B.1.3 "Ensure that automatically generated content is accessible" and note "See Also: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1." It's not clear how the SC under Guideline B.2.1 help retrieve accessibility information from authors. Guideline B.2.3 seems to be the most relevant for providing assistance, though "repair" may not be fully accurate as it would apply to Guideline B.1.3. However, given that "actions of authors" is exempt and seems to include the provision of accessibility information (faulty or otherwise) then this may be a moot point.
- MS: B.1.3 “…prior to publishing.” Invalidates the SC. If a tool generates content in real time, there is no content to meet WCAG 2.0 prior to publishing. The concept has no meaning. Please remove “prior to publishing.” In B.1.3.1, B.1.3.2, and B.1.3.3.
|
- @JR: That B.2.1 reference is outdated and should be removed (change request not substantive).
- @@JR: Maybe we should move the "prior to publishing to a note" explaining when it does make sense. (Suggestion is not a substantive change)
|
| B.2.1 Guide authors to create accessible content. |
|
- WCAGWG: B 2.1.1 (a) and elsewhere term "accessible content" is used where perhaps "conforming with WCAG 2.0" would be better.
- MS: B.2.1.1 No commercial product, or even most non-commercial one, would take on the liability of claiming accessibility on behalf of a 3rd party technology. This is SC is absolutely not implementable. Please remove B.2.1.1
- MS: B.2.1.2 What happens if there some properties are set via context menu, some are set on the ribbon, and some are set in a separate dialogue? This SC implies the accessibility-related properties need to be in all of them. We believe there is an unstated assumption that all the mechanisms are interchangeable. That is not a valid assumption. Please revise B.2.1.2
- MS: B.2.1.2 “Accessibility-related properties” is undefined. Please define.
- MS: B.2.1.3 If the authoring tool cannot edit, then should the burden of making the association be placed on that tool? We can only see very specific situation where this makes sense (time text file upload or adding alt text). Also, what if the content is read-only due to protection? The proposed text is too sweeping. Insert condition of “if the content supports association of accessibility info.”
|
- @JR: We should do a better job of tying in WCAG 2.0 there (change request not substantive since that's in our definition of "web content, accessible")
- @@ JR: This SC says nothing about accessibility of 3rd party technology. It just asks if there are accessibility supports (e.g., ability to add alt, checking, etc.) in the authoring tool in question for that format. (Suggestion is a substantive change)
- @@JR: This needs discussion. The intent is not to have the accessibility properties off by themselves (or with some obscure properties) where the author won't find them. (Suggestion is a substantive change)
- @@JR: Needs discussion. (Suggestion is not a substantive change)
- @@JR: Agreed. The intent here is for the content that can be edited by the authoring tool to be used as a wrapper for that which can't. (Suggestion may be a substantive change)
|
| B.2.2 Assist authors in checking for accessibility problems. |
- B.2.2.1 Check Accessibility (WCAG Level A): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level A Success Criterion can be violated, then accessibility checking for those success criteria is provided (e.g., an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions).
Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.
- B.2.2.2 Availability: Checking is available prior to publishing in a manner appropriate to the workflow of the authoring tool.
- B.2.2.3 Help Authors Decide: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help the authors decide whether it is correctly identified.
- B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant content is identified (e.g., highlighting the affected content, displaying line numbers, etc.)
|
- MS: B.2.2.2 “Appropriate” is not testable. Revise SC B.2.2.2
- MS: B.2.2.2 What happens when there is no defined workflow? Revise SC B.2.2.2
- MS: B.2.2.2 The concept of “prior to publishing” is not applicable to real time info. How is checking done on an online banking scenario? Revise SC B.2.2.2
- MS: B.2.2.3 This is an AA level SC because B.2.2.1 already provides adequate guidance at A level. Move to AA.
- MS: B.2.2.3 AUWG needs to specify which WCAG 2.0 SCs require author judgment. Add a normative note of which SCs in WCAG 2.0 require author judgment.
- MS: B.2.2.4 This SC is AA or AAA. How is a tool supposed to help locate relevant content to meet WCAG 2.0 3.3.2 or 1.3.3, for example? This SC demands far too much intelligence from the tool to be level A. Move SC to AA or AAA.
|
- @@JR: I can see dropping "in a manner appropriate to the workflow of the authoring tool". (Suggestion may be a substantive change)
- @@JR: See above.
- @@@ JR: We should directly address live authoring (where the first submit to the authoring tool also make it live). BTW: Online banking doesn't tend to author content for other people to consume so it's not an authoring tool by ATAG's definition. (Suggestion is a substantive change)
- @@@ JR: In my opinion this is necessary at Level A. (Suggestion is a substantive change)
- @@@JR: It can depend on the implementation of the check. E.g. one tool might detect single-colour images as spacers, another might require user input. (Suggestion is a substantive change)
- @@@JR: Need to clarify, that for certain types of problems, the best help in locating that a tool can provide is instructions. (Suggestion is a substantive change)
|
| B.2.3 Assist authors in repairing accessibility problems. |
|
- WCAGWG: B.2.3.1: Typo refers to Guideline B.2.2 should be, "as required by SC B.2.2.1."
|
- @JR: Agreed - typo (change request not substantive).
|
| B.2.4 Assist authors with managing alternative content for non-text content. |
|
- WCAGWG: B.2.4.1 Editable: "Authors are able to modify...," may be difficult to test and it can be argued that it has been met in situations where it's possible, but more difficult for an author with a disability to make the change. Consider incorporating into the requirement or the implementation guide something about the ease with which an author can make the modification. The "at least as prominent" concept from B.2.5.6 may be a way to address this concern.
- WCAGWG: B.2.4.2 Automated Suggestions: The use of the word "can" makes this SC sound like it's optional. "During the authoring session, the authoring tool can automatically suggest alternative content..." Suggest "can [be configured to] automatically suggest...."
- GG: B2.4.2 Automated Suggestions may be too complex to implement in an authoring tool to be a Level A requirement. I see this more as an advanced feature. In terms of Level A "must does" automated suggestion is nice to have, but not a necessary requirement for creating accessible content. If I were an authoring tool developer, I might see this requirement as too strict. This might be a Level AA requirement. B2.4.2 and B2.4.4 would be implemented together. B2.4.4 would be implemented first, to provide the reusable suggestions that would then provide data for automated suggestions.
- MS: B.2.4.1 Is this meant for audio description as well? If not, then the proposed language is too sweeping. Please clarify and tighten the language as necessary..
- MS: B.2.4.2 This is not a Level A SC. Providing instruction is A. Providing automate suggestion should be AA. Please move SC to AA
- MS: B.2.4.2 “Relevant sources” need testable definition. Please add definition.
|
- @@JR: The point is that all authors need to be able to edit alternative content. (change request may be substantive).
- @JR: It is meant to be optional. Maybe needs more explanation as to why in the "Implementing" doc.
- @JR: ATAG2 is not requiring it. In fact, it's meant to address the opposite problem - over-enthusiastic automated suggestions.
- @@JR: Only if that type of accessibility information is editable using the tool. (Suggestion may be a substantive change)
- @@@ JR: . (Suggestion is a substantive change)
- @@ JR: "Relevant sources" is just the handle. The text is : "The suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description)." (Suggestion may be a substantive change)
|
| B.2.5 Assist authors with accessible templates and other pre-authored content. |
- B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level A when used.
Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly.
- B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for a range of template uses.
|
- WCAGWG: B.2.5.2 Provide Accessible Templates: Suggest incorporating a requirement to clearly identify accessible template options. (ex. "If the authoring tool provides templates, then there are accessible template options for a range of template uses [and accessible templates are clearly identified as such]." Another approach would be to require that they be "at least as prominent as other templates.
- UAWG: B.2.5.2: How does this differ from just making any templates accessible? One would assume all templates offered should have equal accessibility. What happens if the end user selects a template with less accessibility? It sounds like you're proposing a requirement that if the user selects an inaccessible template, the authoring tool at least provides an accessible mechanism to exit the mode where they're using that template. Also minor, but it might clarify that we're talking about templates that are accessible to the author while creating or editing content, not templates that are designed to produce content accessible to the end-user. Is the latter also addressed somewhere?
- MS: B.2.5.1, B2.5.3, B.2.5.9 How can “…used properly” ever be testable? The note is a necessary component of the SC since most templates cannot meet WCAG 2.0 in their initial state. But adding the note makes the SC not testable.
|
- @JR: That's in B.2.5.4.
- @@JR: We're not saying that every template needs to be accessible. But rather, that at least some of the templates need to be accessible (a common sense definition of range is probably >1). Re: Accessible to whom...since this is Part B, B.2.5.2 relates to the production of accessible content for end-users BUT at the top of Part B is this normative note: "Features for meeting Part B must be accessible:..." so it is covered. I think we do need to clarify that we are talking about developer-provided templates, not user-submitted ones over which developers don't have control.
- @@@JR: Discussion needed. (Suggestion is a substantive change)
|
| B.3.1 Ensure that accessible authoring actions are given prominence. |
|
|
|
| B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available. |
|
- WCAGWG: B.3.2.1 Active by Default: Consider softening this requirement to include a subset of support features (ex. those that relate to WCAG Level A). Alternatively, consider changing the level of this SC. The concern here is that automatic tests, especially at Levels AA and AAA, often lead to repetitive and erroneous error and warning messages, which could result in authors being motivated to turn off accessible content support features altogether.
- MS: B.3.2.1, B.3.2.2, B.3.2.3 The SC assumes that there is some feature to be “turned on” which is an invalid assumption. Please add condition of “If there is a changeable on/off status for such features.”
- MS: B.3.2.2 Does the term “always” add anything to the criteria? It can be a loaded word to imply that one must be able to turn the feature from any dialogue. Obviously, that’s not possible. Please remove the term “always” form the SC.
|
- @JR: Hard to control bad UI design. But if they start off they may NEVER get turned on. I suggest adding more Implementing guidance on this point instead. (change request may be substantive)
- @@JR: ok (Suggestion may be a substantive change)
- @JR: ok (Suggestion is not a substantive change)
|
| B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are documented. |
|
|
|
| B.3.4
Ensure that any authoring practices demonstrated in documentation are accessible. |
|
- WCAGWG: B.3.4.1, B.3.4.2, B.3.4.3: Consider adding a requirement to these SC that the accessible examples be clearly identified and at least as prominent as other examples in the documentation.
|
- @JR: The idea is that they don't need to be clearly identified - they are simply worked into the routine documentation. (change request is substantive)
|