Guideline

A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.

Success Criteria

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.

Comment

MS39: A.3.1.3 Does a web-based authoring tool need to add short cut keys? That seems rather unnecessary and arbitrary. The value of short cut key is contextual. This proposal is too sweeping. Remove this success criterion.

AUWG Response

AUWG: No (e.g., it could just have skip nav links etc.). This requirement has been clarified as follows: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation. (Level AA) [ADDRESSED]

Summary

Details

Guideline

A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.

Success Criteria

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.

Comment

MS40: Does it meet the success criterion if only two shortcuts are provided since there is no specification? In that case, it would be hard to find any product that would fail this success criterion (file save and quit application are almost always supported)—making this criterion meaningless. Remove this success criterion.

AUWG Response

AUWG: No (e.g., it could just have skip nav links etc.). This requirement has been clarified as follows: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation. (Level AA) [ADDRESSED]

Summary

Details

Guideline

A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.

Success Criteria

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.

Comment

GL23. MEDIUM: Keyboard shortcuts requirement is subjective. Re "A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)" How many keyboard shortcuts? For which functions? I understand the need to be general, but because it is so general it does not seem objectively measurable, despite intention stated in "Understanding Levels of Conformance".

AUWG Response

AUWG: No (e.g., it could just have skip nav links etc.). This requirement has been clarified as follows: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation. (Level AA) [ADDRESSED]

Summary

Details

Guideline

A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.

Success Criteria

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.

Comment

IBM23: A.3.1.3 Keyboard shortcuts: This is an advisory, not a requirement, in WCAG 2.0 because it's just not testable in a useful way. As worded, you would technically pass this SC if you have at least two keyboard shortcuts but whether you have actually provided enough keyboard shortcuts to make something usable is highly subjective or requires extensive user testing. This will be a source of controversy with regards to compliance so it should mirror WCAG 2.0 and have this be an advisory technique for meeting A.3.1.1.

AUWG Response

AUWG: No (e.g., it could just have skip nav links etc.). This requirement has been clarified as follows: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation. (Level AA) [ADDRESSED]

Summary

(1 response didn't contain an answer to this question)

Details

Guideline

A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features.

Success Criteria

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.

Comment

IBM24: A.3.1.3., A.3.1.5 The techniques refer to all mobile devices having keyboard shortcuts. Is that accurate? Appears to be desktop centric, and not supportive current mobile devices.

AUWG Response

AUWG: No (e.g., it could just have skip nav links etc.). This requirement has been clarified as follows: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation. (Level AA) [ADDRESSED]

Summary

Details

Guideline

A.3.5 [For the authoring tool user interface] Provide text search of the content.

Success Criteria

* A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Comment

WCAGWG24: A.3.5.1 (b): To avoid confusion with bi-directional text, consider changing the short name of this item to "Two-way."

AUWG Response

AUWG: This change has been made. [ADDRESSED]

Summary

Details

Guideline

A.3.5 [For the authoring tool user interface] Provide text search of the content.

Success Criteria

* A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Comment

MS41: A.3.5.1 In many cases, this is carried out by the browser or the OS instead of the authoring tool. Does that mean the browsers and OS would be required as part of the conformance? Please explain how reliance on browser and OS are to be handled.

AUWG Response

AUWG: Yes, the browser or OS would be involved. For example, in a wiki an authoring view might occur within a text area. I can use my browser's Edit>Find feature to search for terms inside that text area. If I choose to make conformance claim, the browser I tested with is a Required Component of the claim. [ADDRESSED]

Summary

Details

Guideline

A.3.5 [For the authoring tool user interface] Provide text search of the content.

Success Criteria

* A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Comment

GL4. HIGH: UAAG requirements for text search. "A.3.5.1 Text Search" lacks two search features required by UAAG: (1) "4.6.3 Match Found: When there is a match, the user is alerted and the viewport moves so that the matched text content is at least partially within it. The user can search for the next instance of the text from the location of the match." (2) "4.6.4 Alert on No Match: The user is notified when there is no match or after the last match in content (i.e., prior to starting the search over from the beginning of content). (Level A)"

AUWG Response

AUWG: Alert on no match has been added to A.3.5.1 as "(d) No Match: Authors are informed when no results are found." [ADDRESSED]

Summary

Details

Guideline

A.3.5 [For the authoring tool user interface] Provide text search of the content.

Success Criteria

* A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Comment

OC7: -A.3.5 – It is not clear that this is specifically an accessibility requirement. Furthermore, it is not clear how one could implement this in practice, for example if the target of the search may be rendered in multiple user interfaces including modal dialogs. Lastly, ‘text that the authoring tool can modify' is too broad, because some of that text may only be available at ‘runtime', in which case it would be the responsibility of the user agent to account for this feature. We recommend that this guideline be made advisory

AUWG Response

AUWG: While all users benefit, people who have difficulty using the keyboard benefit more. [ADDRESSED]

Summary

Details

Guideline

A.3.5 [For the authoring tool user interface] Provide text search of the content.

Success Criteria

* A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Comment

IBM30: A.3.5.1: the sub-bullets don't need "and" at the end of each one. And is implied by the wording of the parent provision because it doesn't say "one of the following"

AUWG Response

AUWG: This is the WCAG 2.0 style. See IBM18. [ADDRESSED]

Summary

Details

Guideline

A.3.5 [For the authoring tool user interface] Provide text search of the content.

Success Criteria

* A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Comment

IBM31: A.3.5.1 Most browsers support text search and type ahead capability. Would this satisfy the checkpoint? If so, why is it not in the implementation section? Why do you confine searches to the editing view in this situation? Have you spoken to UAAG about requiring the feature of text searching. This would remove the burden from the author for web content.

AUWG Response

AUWG: Browser features can be used (see MS41). Even if it were added to UAAG, it might not be implemented so it should stay in for now. [ADDRESSED]

Summary

Details

Guideline

A.3.6 [For the authoring tool user interface] Manage preference settings.

Success Criteria

A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings. Note: As per Success Criterion A.2.3.1, the author's display settings must still be independent of the web content being edited.

Comment

UAWG5: A.3.6.2: Broaden this to any settings that impact accessibility? If these definitions of "display settings" and "control settings" seem broad enough to possibly include all input or output preference settings;, it would be nice if one didn't have to take the links to the glossary to figure that out, and it's still somewhat ambiguous: would it include the option to hide or show alternative text? Also, an example of preference settings beyond display and control settings that still affect accessibility would be the option to turn on and off AT compatibility modes such as support for platform accessibility API.

AUWG Response

AUWG: Broadened to: A.3.6.2 Save Settings: Authoring tool display settings and control settings can be saved between authoring sessions. (Level AA) [ADDRESSED]

Summary

Details

Guideline

A.3.6 [For the authoring tool user interface] Manage preference settings.

Success Criteria

A.3.6.1 Save Settings: The authoring tool display settings and control settings are saved between sessions.

Comment

MS42: A.3.6.1 There is some inconsistency here from A.3.1.4 where customization is set at AAA, but saving such setting is AA. Please consider moving this SC to AAA to maintain consistency.

AUWG Response

AUWG: A.3.6.1 applies to more than just keystrokes. e.g., that I had set my default editing zoom to 150%. [ADDRESSED]

Summary

Details

Guideline

A.3.6 [For the authoring tool user interface] Manage preference settings.

Success Criteria

A.3.6.1 Save Settings: The authoring tool display settings and control settings are saved between sessions.

Comment

MS43: A.3.6.1 Change “…are saved…” to “…can be saved…”. The current wording implies that the tool will do so without user control. Please change wording as suggested.

AUWG Response

AUWG: Agree to change. [ADDRESSED]

Summary

Details

Guideline

A.3.6 [For the authoring tool user interface] Manage preference settings.

Success Criteria

A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings. Note: As per Success Criterion A.2.3.1, the author's display settings must still be independent of the web content being edited.

Comment

MS44: A.3.6.2 Please define "respects" or use more precise language. Please define "respects" or use more precise language

AUWG Response

AUWG: "Respect" has been changed to "apply"(new numbering is A.3.6.3). [ADDRESSED]

Summary

Details

Guideline

A.3.6 [For the authoring tool user interface] Manage preference settings.

Success Criteria

A.3.6.1 Save Settings: The authoring tool display settings and control settings are saved between sessions.

Comment

IBM32: A.3.6.1 Saving authoring tool display and keyboard settings. This seems onerous if you are doing rich web applications. It means you need to have some sort of RESTful service to stash this information. Local Data Storage does not show up until HTML 5 for the web. I am not aware of a web email clients (rich text editing capability) that supports this today.

AUWG Response

AUWG: Most web applications with long-term users save any settings that they allow to be changed. e.g. if a theme is set, it is still in use when the user logs back in. [ADDRESSED]

Summary

Details

Guideline

A.3.6 [For the authoring tool user interface] Manage preference settings.

Success Criteria

# A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings.
Note: As per Success Criterion A.2.3.1, the author's display settings must still be independent of the web content being edited.

Comment

BM23: A.3.6.2 Web pages do not have access to keyboard control settings so what happens when you have a web page that acts like an authoring tool? At best you could implement best practices for a given platform but if customization goes on you are out of luck. Browsers have security walls put up to prevent you from asking OS specific information. Is there a plan to address this issue?

AUWG Response

AUWG: A web application could allow the author to specify accesskeys. The success criterion simply requires that if the authoring tool allows the user to set a setting then that setting value should be saved for the next session. [ADDRESSED]

Summary

Details

Guideline

A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes.

Success Criteria

A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s).

Comment

GL17. MEDIUM: Level conflict between Undo and Undo Reversible. "A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent 'undo' action(s). (Level AA)" seems to conflict slightly with A.4.1.1 because the latter requires at Level A that all operations that change content be subject to an "undo" operation, while the former says that providing "undo" for an "undo" operation that changed content is only Level AA. You could fix this by explicitly exempting undo from the undo requirement, or by changing the level of the redo requirement, etc.

AUWG Response

AUWG: This requirement has been combined with the main udo requirement with the addition of this note ("Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g., a "redo" function). ").[ADDRESSED]

Summary

Details

Guideline

A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes.

Success Criteria

A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s).

Comment

GL36. MINOR: AT also introduces errors. In "Implementing Guideline A.4.1: [For the authoring tool user interface] Help authors avoid and correct mistakes", the rationale could include not only people who have difficulty with fine motor control, but also those who rely on assistive technologies such as speech recognition, which introduce errors through misrecognition.

AUWG Response

AUWG: This is a good addition. @@ADD

Summary

Details

Guideline

A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features.

Success Criteria

A.4.2.2 Document All Features: All features of the authoring tool are documented.

Comment

MS45: A.4.2.2 “All features” is too encompassing. Hidden features are common place. Besides, how is non-documented features affecting people with disabilities any more than those without disabilities. This SC is not at all related to accessibility. Please remove A.4.2.2

AUWG Response

AUWG: We mean features the user can use. This is a AA requirement for people with cognitive disabilities, people who have difficulty exploring UIs, etc. [ADDRESSED]

Summary

Details

Guideline

A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features.

Success Criteria

A.4.2.2 Document All Features: All features of the authoring tool are documented.

Comment

IBM37: A.4.2.2 Does this require statements of UAAG conformance?

AUWG Response

AUWG: We do not understand this comment. [ADDRESSED]

Summary

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true:
(a) Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information; or
(b) Notification Option: Authors have the option to receive notification before deletion; or
(c) No Deletion Option: Authors have the option to prevent automatic deletion by the authoring tool.

Comment

WCAGWG25: B.1.2.4(a) "Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information;" This is confusing. The non-accessible part of web content that is associated with the accessibility information should not be deleted.

AUWG Response

AUWG: The preservation requirements have been reorganized. See WCAGWG15. [ADDRESSED]

Summary

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true:
(a) Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information; or
(b) Notification Option: Authors have the option to receive notification before deletion; or
(c) No Deletion Option: Authors have the option to prevent automatic deletion by the authoring tool.

Comment

WCAGWG26: B.1.2.4(b) "Notification Option: Authors have the option to receive notification before deletion;" Add "and are warned that this may result in web content accessibility problems in the output"

AUWG Response

AUWG: The preservation requirements have been reorganized. See WCAGWG15. [ADDRESSED]

Summary

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output.

Comment

MS46: B.1.2.3 We suspect there is an error here where the accessibility information should be up to WCAG 2.0 Level AA, not AAA. There should also be a similar SC for AAA. Please change the SC language from “…WCAG 2.0 Level AAA…” to “…WCAG 2.0 Level AA…” Add a new SC to cover AAA

AUWG Response

AUWG: The preservation requirements have been reorganized (with this multi-level comment worked in). See WCAGWG15. [ADDRESSED]

Summary

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output.

Comment

MS47: B.1.2 How does this apply to something like a copy and paste operation from a rich text editor to a plain text editor where structural info will be lost? Who is supposed to tell the author that the structure is gone? Please explain how the SC applies to copy-and-paste or cut-and-paste operations?

AUWG Response

AUWG: The preservation requirements have been reorganized. See WCAGWG15. [ADDRESSED]

Summary

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true:
(a) Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information; or
(b) Notification Option: Authors have the option to receive notification before deletion; or
(c) No Deletion Option: Authors have the option to prevent automatic deletion by the authoring tool.

Comment

WCAGWG25: B.1.2.4(a) "Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information;" This is confusing. The non-accessible part of web content that is associated with the accessibility information should not be deleted.

AUWG Response

AUWG: The preservation requirements have been reorganized. See WCAGWG15. [ADDRESSED]

Summary

(1 response didn't contain an answer to this question)

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output.

Comment

IBM41: B.1.2.3 - Why is the AA requirement to preserve accessibility information up to WCAG 2.0 Level AAA? It should only be up to Level AA. If Level AAA is required, there should be another provision.

AUWG Response

AUWG: The preservation requirements have been reorganized. See WCAGWG15. [ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.1.2 Ensure that the authoring tool preserves accessibility information.

Success Criteria

B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output.

Comment

IBM43: B.1.2.4 Most if not all information is accessibility information. If I export a file to PDF are you going to interrupt the user ever time it runs into an unsupported feature in the target document format? This seems unrealistic. For example, text is important to accessibility as is alt text. I think accessibility information needs expansion for that reason. Also what about labels and live region support - any accessibility property.

AUWG Response

AUWG: The preservation requirements have been reorganized. See WCAGWG15. [ADDRESSED]

Summary

(1 response didn't contain an answer to this question)

Details

Guideline

B.1.3 Ensure that automatically generated content is accessible

Success Criteria

* B.1.3.2 Accessible Auto-Generated Content (Level AA): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level AA prior to publishing.
Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).

Comment

JR: Should be B.1.3.2 Accessible Auto-Generated Content (WCAG Level AA)

AUWG Response

AUWG: Re-organized instead. [ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.2.2 Assist authors in checking for accessibility problems.

Success Criteria

B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., low-level check results, high-level conformance claims, etc.)

Comment

MS49: B.2.2.7 This SC belongs to AAA. Move SC to AAA.

AUWG Response

AUWG: The WG has decided that this is AA. The metadata might be as simple as a single WCAG conformance level value. [ADDRESSED]

Summary

(1 response didn't contain an answer to this question)

Details

Guideline

B.2.2 Assist authors in checking for accessibility problems.

Success Criteria

B.2.2.6 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc.

Comment

GL28. MEDIUM: Clarify minimum requirements for Status Report. "Implementing Success Criterion B.2.2.6 Status Report" again could better clarify the minimum requirements for conforming. For example, if the user chooses a menu command to check the document and it provides a dialog box listing the errors and potential errors, but provides no way to save or print that information, does that still count as a "report"? What if the dialog box only shows one error or potential error, and the user has to press a "Next" button to display each successive point?

AUWG Response

AUWG: Your point is taken, but at some point we can't control bad UI design. [ADDRESSED]

Summary

(1 response didn't contain an answer to this question)

Details

Guideline

B.2.2 Assist authors in checking for accessibility problems.

Success Criteria

B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., low-level check results, high-level conformance claims, etc.)

Comment

GL29. MEDIUM: Clarify minimum requirements for Metadata Production. "Implementing Success Criterion B.2.2.7 Metadata Production" could clarify whether saying the results must be stored "with the web content as metadata" means it must be stored in the file (e.g. as markup in the HTML document) or whether it can be separate (e.g. in the tool's database or in separate report files). If the latter, then it's hard to see how it differs from the requirement to make a report of test results available, other than that this might require it to be machine-readable and parsable using a documented format, instead of only human-readable text.

AUWG Response

AUWG: As you say, metadata is machine readable and parsable, whether or not it is human readable. [ADDRESSED]

Summary

(1 response didn't contain an answer to this question)

Details

Guideline

B.2.2 Assist authors in checking for accessibility problems.

Success Criteria

B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., low-level check results, high-level conformance claims, etc.)

Comment

OC23: -B.2.2.7 – We recommend making this Level AAA.

AUWG Response

AUWG: The WG has decided that this is AA. The metadata might be as simple as a single WCAG conformance level value. [ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.2 Assist authors in checking for accessibility problems.

Success Criteria

B.2.2.6 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc.

Comment

IBM53: B.2.2.6 Difficult to have a web email client or a wiki provide a status report on accessibility of dynamic content. There is value, but this is a significant requirement, should be AAA and configurable.

AUWG Response

AUWG: If the checker can perform the check, it does not seem too difficult to produce some form of report. [ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.2 Assist authors in checking for accessibility problems.

Success Criteria

B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., low-level check results, high-level conformance claims, etc.)

Comment

IBM54: B.2.2.7 Need more concrete examples of using metadata here. Metadata is very abstract.

AUWG Response

AUWG: This requirement is intended to be open to a variety of implementations. The main point is to encourage the use of metadata, of any kind, to store and convey checking results. [ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.4 Assist authors with managing alternative content for non-text content.

Success Criteria

B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse.

Comment

MS50: B.2.4.4 This SC seems extraneous. If text alternative can be accessed, then obviously it can be reused. If nothing, at least delete “for future reuse.” since it represents future event which is unverifiable at the time of conformance claim. Consider deleting the SC or at least delete “for future use.”

AUWG Response

AUWG: Reworded for clarity: B.2.3.4 Save for Reuse: When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA) (a) Save and Suggest: the text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and (b) Edit Option: the author has the option to edit or delete the saved text alternatives.[ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.2.4 Assist authors with managing alternative content for non-text content.

Success Criteria

B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse.

Comment

GL30. MEDIUM: Clarify minimum requirements for Save for Reuse. "B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)" does not make it clear whether the content strings need to be associated with the original content (e.g. with the image), or that the user should be able to delete obsolete or erroneous entries to keep the list from becoming unwieldy. I worry that a simple way of complying is just to have a single, ever-growing list of previously used strings that can quickly change from useful to detrimental (like Thunderbird's list of recipients), so even if the minimum is left vague, I recommend at least providing some guidance or best practices.

AUWG Response

AUWG: Reworded for clarity: B.2.3.4 Save for Reuse: When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA) (a) Save and Suggest: the text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and (b) Edit Option: the author has the option to edit or delete the saved text alternatives.[ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.4 Assist authors with managing alternative content for non-text content.

Success Criteria

B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse.

Comment

OC26: -B.2.4.4 – We recommend making this Level AAA as this is applies equally to non- accessibility related content and moves into a product usability feature.

AUWG Response

AUWG: it has been moved to AAA. See response for MS50. Reworded for clarity: B.2.3.4 Save for Reuse: When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA) (a) Save and Suggest: the text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and (b) Edit Option: the author has the option to edit or delete the saved text alternatives.[ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and
(b) Prominence: Any accessible options are at least as prominent as other pre-authored content options.

Comment

GG7: B2.5.6 Pre-Authored Content: Also see B2.5.8 below - Who decides on the accessibility status of pre-authored content, which may be user provided. In note (a) the words "Indicate" and "if known" provides a loophole that would allow tools to ignore this guideline. If none of the pre-authored content is reviewed for accessibility, developers can pass this requirement by omitting the accessibility status.

AUWG Response

AUWG: This is now B.2.5.1. The accessibility might be determined by a checking mechanism and recorded with metadata. [ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.

Comment

UAWG6: B.2.5.4: The definition for prominence says in part: For purposes of conformance to ATAG 2.0, item A is considered to be at least as prominent as item B if: both items occur in the same item container (e.g., a menu for menu items, a list for list items, a dialog box for text boxes); if item B is emphasized, then so is item A; so if the accessible option is at the bottom of a menu separated from the less accessible option by 10 entires, this is acceptable? If the list has 25 items and the user must scroll to see the accessible option, is this then acceptable? Off the topic somewhat, but the question of whether accessible options should be displayed as prominently as, and/or in proximity to, their inaccessible counterparts applies to more things than just templates (for example, a list of schemes).

AUWG Response

AUWG: It is not perfect, but it is very difficult to get more prescriptive about the order within a container because the order is dependent on so many factors. [ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.

Comment

MS51: B.2.5.4 If all templates are equally accessible, why would this be necessary or beneficial? There seems to be an assumption here that the templates are not all of similar accessibility status. Revise the SC

AUWG Response

AUWG: User created templates could be less accessible and require this feature to distinguish them. [ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.

Comment

MS52: B.2.5.4 Please provide examples of how one goes about indicating the accessibility status of a template. How much detail is needed? Please provide instruction of the level of detail required to indicate template accessibility status.

AUWG Response

AUWG: There are multiple ways this might be achieved. Two possibilities are mentioned in the examples (e.g. accessibility status as a sortable field, WCAG 2.0 conformance level included in its name). Checking is also mentioned, in which case the metadata produced when meeting "B.3.1.5 Metadata Production" might be used. [ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.

Comment

MS53: B.2.5.4 What happens when there is a large variety of template of all different sorts? The language suggests that the “accessible” option must take precedence regardless of other logical grouping. Please change the SC to account for other logical grouping of templates.

AUWG Response

AUWG: At least as prominent is not the same as taking precedence. @@ADD note to prominence on logical groupings.

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.

Comment

MS54: B.2.5.4 The term “…accessible template options” implies that there is a distinction of “accessible template” and “non-accessible” template. How does one go about making such distinction? Without an exact definition, this SC is not testable. Please provide a structured way to indicate accessibility status of templates and how to go about showing prominence of template of various (or equal) status.

AUWG Response

AUWG: This issue has been moved to a new defined term: Accessible template, which is defined as:
Templates that the author or authoring tool can use to create web content that meets the WCAG 2.0 success criteria at a particular level (Level A, AA or AAA) under both of the following conditions:
- Authors correctly follow the minimum instructions associated with the template, including providing complete and correct information when requested (e.g., by responding to prompts, replacing highlighted placeholders, etc.); and
- No further authoring occurs (e.g., a "blank" document template would be assessed only on the basis of the resulting blank web content)[ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.5 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates.

Comment

MS55: B.2.5.5 This SC assumes that author is given freedom to create templates with different degree of accessibility. The assumption is not always valid. Please address the scenario in which author has no freedom to change accessibility of a template.

AUWG Response

AUWG: Agreed, but in cases where the result is always accessible, this would seem to simplify the task of labeling it as such. [ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and
(b) Prominence: Any accessible options are at least as prominent as other pre-authored content options.

Comment

MS56: B.2.5.6 All comments from 2.5.4 apply equally. Please reference comments from B.2.5.4

AUWG Response

AUWG: See responses above.[ADDRESSED]

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.2.5 Assist authors with accessible templates and other pre-authored content.

Success Criteria

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.

Comment

GL41. MINOR: Indicators during template selection. Re "B.2.5.4 Template Selection Mechanism", would you really recommend listing entries like "slide show template - wcagA"? If you want to recommend something, wouldn't "slide show template (WCAG A)" be more acceptable to users and software designers? The examples might also be more acceptable to designers and developers if you show their mainstream uses, such as also showing which templates are available in multiple languages, whether they're suitable for small screens, etc.

AUWG Response

AUWG: @@update

Summary

(3 responses didn't contain an answer to this question)

Details

Guideline

B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.

Success Criteria

B.3.2.3 Deactivation Warning: If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems.

Comment

WCAGWG27: B.3.2.3 Deactivation Warning: Consider promoting this SC to Level A.

AUWG Response

AUWG: Moved to AA. [ADDRESSED]

Summary

(4 responses didn't contain an answer to this question)

Details

Guideline

B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.

Success Criteria

B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors).

Comment

MS57: B.3.2.4 “Comparable” is not testable. Please revise SC.

AUWG Response

AUWG: We believe comparable is legitimate given the examples listed: B.4.1.4 Feature Prominence: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g. invalid markup, syntax errors, spelling and grammar errors)[ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.

Success Criteria

B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors).

Comment

MS58: B.3.2.4 “Other types of web content problems” has no definition and, thus, there is no way to determine if the SC is met. Please replace “other types of web content problems” with something more precise.

AUWG Response

AUWG: This wording is clarified sufficiently by the examples ("(e.g. invalid markup, syntax errors, spelling and grammar errors)"). [ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.

Success Criteria

B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors).

Comment

GL19. MEDIUM: User should be allowed to override B.3.2.4 At Least As Prominent. Re "B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors). (Level AA)" is an example of a success criterion that should acknowledge that this refers to the default user interface, but that the user can be allowed to override these defaults.

AUWG Response

AUWG: The Developer control Conformance Applicability Note covers this.[ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available.

Success Criteria

B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors).

Comment

OC31: -B3.2.4 – Because there are a variety of prominence levels for the examples given it will be very subjective which to choose. How we would highlight markup is very different from a spelling issue. This makes the item very subjective and hard to test.

AUWG Response

AUWG: We agree that it is difficult to test, but most people would agree that a spell checker that underlines words in text has a much higher prominence than an accessibility utility that is activated from a third-level menu item.[ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details

Guideline

B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible.

Success Criteria

B.3.4.2 Model Accessible Practice (WCAG Level AA): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AA accessible authoring practices.

Comment

MS59: B.3.4.1 What counts as a range? Two or more? Please remove “A range of” from the SC

AUWG Response

AUWG: Yes two or more is the minimum. But the term range was selected because it also indicates that the spirit of the requirement is to provide more than that. [ADDRESSED]

Summary

(2 responses didn't contain an answer to this question)

Details