Some comments on ATAG Draft of 08 July 2010

  (Here is the plain text, with an HTML version attached.)

Comments on Authoring Tools Accessibility Guidelines (ATAG)
W3C Working Draft 08 July 2010

Greg Lowney
Lowney Access Research, LLC
gcl-0039@access-research.org

Overall I'm very impressed by ATAG, and want to thank and congratulate the editors and contributors. Both the success criteria and implementation are written in a consistent manner, are reasonably clear and easy to understand (if sometimes, perhaps unavoidably, technical and dense), and the examples are very helpful.

Nevertheless, here are some comments and suggestions. I apologize for the fact that other these are late, numerous, and lengthy; do with them what you will, but I hope some may still prove useful for you.

For your convenience I've divided them into "High Priority", "Medium Priority" (although the line between those two categories is often blurry), "Minor", and "Clarifying Minimum Requirements" (examples of cases where success criteria remain are vague as to the minimum requirements for conforming).

High Priority

1. HIGH: Programmatically Determinable is not limited to Platform API. The glossary entry for "programmatically determined (programmatically determinable)" says "For non-web-based user interfaces, this means making use of a platform accessibility architecture." In the UAAG 2.0 draft we stress the importance of not only supporting the platform accessibility architecture, but also other programmatic interfaces. For example: "Intent of Success Criterion 2.1.4: Assistive technologies often use a combination of methods to get information about and manipulate an application and its content. These methods include platform accessibility APIs (such as MSAA or JAA), general-purpose platform APIs (such as those used to determine a window's title), application-specific APIs (typically a last resort when an application does not make all information available through the former means), DOMs, and hard-coded heuristics. It is the user agent's responsibility to make the necessary information 
and facilities available through the appropriate corresponding means. Because DOMs typically provide capabilities that are fine-tuned to a specific content type, and therefore far richer than the other methods, exposing DOMs to assistive technology is an extremely important part of AT compatibility. This complements, but does not replace, the need to support other methods, such as platform accessibility API, because although they are less powerful, they allow assistive technology to work with a wider range of applications."

2. HIGH: Note misleading about scope of A.2.2.3: ATAG's "Implementing Success Criterion A.2.2.3" has a note that is misleading as it seems to limit the scope of the SC to only properties that can be edited by the authoring tool, whereas the SC clearly applies to all properties that are rendered whether they can be edited or not. The SC says "If an editing view (e.g., WYSIWYG view) RENDERS any presentation properties for text, then those properties can be programmatically determined." Whereas the note says "See Implementing Success Criterion A.2.2.2, substituting all text presentation properties that are BOTH RENDERED AND EDITABLE by the authoring tool for the four presentation properties listed in A.2.2.2." (emphasis added)

3. HIGH: Keyboard trapping too narrowly defined. Re "A.3.1.2 No Content Keyboard Traps:...(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)." The problem with this wording is that being able to move the focus from an object to the authoring tool's menu is not sufficient if, when they return to editing mode, the keyboard focus returns to a trapped state. For example, imagine that you are authoring content and use a command insert a Flash object, leaving the focus on that object and no keyboard command such as Tab to move it off; the only thing you can do is press a key combination to move the active keyboard focus to a menu, but upon dismissing the menu the focus is back on the Flash object, and you still cannot get to the rest of the document, and you presumably have to close the document and 
reopen it again to get back into a usable editing mode. The true intent should be to allow the author to move the keyboard focus to other elements inside the content--specifically, being able to move the focus elsewhere within its current viewport and to any other viewports that can take keyboard focus.

4. 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)"

5. HIGH: Need exceptions for A.3.6.2 Respect Platform Settings. "A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings. (Level AA)" seems problematic because--while this was certainly not the intention--the wording (a) prevents the authoring tool from allowing the user the override those settings, and (b) prevents it from displaying content as a preview or in WYSIWIG mode when content colors, fonts, and so forth conflict with system preference settings.

6. HIGH: Accessible documentation. Re "A.4.2: [For the authoring tool user interface] Document the user interface including all accessibility features." I am very surprised that you require things to be documented but not for them to be documented in accessible fashion. The Intent says "The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2." but that is not normative, and I don't see them as applying to, say, documentation provided on the manufacturer's Web site rather than through the product's user interface. By contrast, UAAG has "5.3.1 Accessible documentation: The product documentation is available in a format that conforms to WCAG 2.0 Level 'A' or greater."

7. HIGH: Include alternative content for text. Re "B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)", alternative content for text content (e.g. acronyms, abbreviation) should be handled the same was alternative content for non-text content.

Medium Priority

8. MEDIUM: Broaden definition of authoring tool. Re the definition of "authoring tool", I wonder whether you also want to explicitly cover tools that cannot directly output Web formats, but can output rich content that can then be converted into Web formats. For examples, imagine a word processor that cannot save documents as HTML but can copy rich text and graphics to the clipboard, from which they can be pasted into a tool that can save them as HTML. The source editor could take steps, such as prompting the user for Alt text for an image, so that the rich content it creates can be converted to Web formats that conform to WCAG. The only nod to this in the definition is the one example that is not explicitly Web-related, "multimedia authoring tools", and that is ambiguous.

9. MEDIUM: Broaden definition of essential. The section "Understanding Levels of Conformance" says "factors evaluated when setting the level in Part A included: ...whether the success criterion is essential (in other words, if the success criterion is not met, then even assistive technology cannot make the authoring tool user interface accessible)" While probably unintentional, this sounds as if success criteria are only included if there is no workaround using assistive technology. As you know, most users with disabilities do not use assistive technology, nor should they need to as long as mainstream software is designed to meet basic accessibility guidelines. For example, software should not be considered accessible if it fails to provide built-in keyboard UI, even if AT such as MouseKeys can retrofit keyboard access onto such software.

10. MEDIUM: Criteria need not apply to all types of authoring tools. The section "Understanding Levels of Conformance" says "factors evaluated when setting the level in Part A included:...whether it is possible to satisfy the success criterion for all types of authoring tools that the success criteria would apply to (e.g., text editors, WYSIWYG editors, content management systems, etc.)" I don't believe a potential success criterion should be excluded just because it does not apply to all authoring tools; rather:

     When writing very specific requirements, it's important to make sure the wording doesn't cause products to fail based simply on technicalities, or force them to add features that provide no real value to users, because of requirements that really shouldn't apply to them. This happens if the requirement's scope is too broad and it fails to include appropriate exemptions.

     There are four approaches to avoiding these types of problems:

         * Appropriately structure requirements so the only apply in certain contexts (scope). For example, ISO 9241-171 provision 8.1.5 starts "If a user interface element has a visual representation...", and provision 8.2.1 starts "When the software enables the user to set personal preferences, these settings should...".
         * Include specific exemptions into specific requirements. For example, ISO 9241-171 provision 11.1.4 states "Instructions and 'Help' for software should be written so that they refer to the user's actions and resulting output without reference to a specific device. References to devices, e.g. the mouse or the keyboard, should only be made when they are integral to, and necessary for, understanding of the advice being given."
         * Provide category exemptions for specific classes of circumstances. For example, the Conformance section of ANSI 200.2 provides that software used on, or intended to be used on closed systems should be exempt from clauses regarding compatibility with assistive technology.
         * Provide a general-purpose exemption, such as allowing "Not Applicable" as a valid response to any requirement. For example, the Conformance section of ISO 9241-171 states that any requirements that have been determined not to be applicable shall also be listed, together with a statement of the reasons why they are not applicable.

11. MEDIUM: UAAG has more Level A text properties. ATAG's A.2.2.2 and A.2.2.3 correspond to UAAG20's 2.1.6, but the latter includes a wider range of text properties at Level A. ATAG A.2.2.2 says "Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG view) renders any of the following presentation properties for text, then those properties can be programmatically determined: (Level A) [Implementing A.2.2.2] (a) Text Font; and (b) Text Style (e.g., italic, bold); and (c) Text Color; and (d) Text Size." UAAG20's 2.1.6 covers "(a) the bounding dimensions and coordinates of rendered graphical objects (b) font family of text (c) font size of text (d) foreground color of text (e) background color of text. (f) change state/value notifications (g) selection (h) highlighting (i) input device focus".

12. MEDIUM: Deactivation warning should prompt for confirmation. "B.3.2.3 Deactivation Warning" would be more effective if it required the authoring tool to prompt for confirmation; that is, not only inform the author of the implications of their decision to turn off an accessible content support feature, but also gives them the opportunity to cancel that operation (as is shown in the example).

13. MEDIUM: Standardize on "both of the following are true". I think the phrasing used in B.2.1.1 "both of the following are true: ... ; and ...", is clearer than that used in SC such as B.2.4.2, which only provide the subtle, trailing "; and" to tell the reader that it's an AND rather than OR clause.

14. MEDIUM: Clarify what authoring tool may repair. "Implementing Success Criterion B.2.4.3 Let User Agents Repair" is great but "c. Repairs are also allowed that go beyond simple text processing to directly processing images, audio or video. The intent here is to encourage progress in these rapidly advancing fields" carves out a category of exception that's not actually reflected in the normative text. In theory, the user agent has just as much access to an audio clip as the authoring tool does, and therefore could perform speech recognition itself or outsource the task to a network resource. Therefore you might want to modify the SC to explicitly make an exception for specialized or processor-intensive tasks (e.g. speech recognition to generate a text transcript or captions from an audio file).

15. MEDIUM: Features should be available to all applicable roles. In "Implementing PART B: Support the production of accessible content", "Applicability Notes" it says "5. Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role." This seems a bit overly broad, as individual features required by ATAG part B should be visible in any mode where they would be useful. As an extreme example, syntax checking should be visible and available to authors and QA, so it should be insufficient to have them available only to system administrators.

16. MEDIUM: Save information for round-tripping. "B.1.2.2 End Product Cannot Preserve Accessibility Information", "(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)" should support round-tripping. That is, if the authoring tool recognizes accessibility information in the source format that cannot be converted to an equivalent in the output format, it should try to encode the information in the output format in such a way that, when the output format is transformed into back into the original format or to another format that does have the same or equivalent information, the accessibility information can be restored to its proper function. For example, the information can be encoded as comments in the first output format, using a consistent, parsable convention that can be recognized by the authoring tool, and ideally should also be documented for use by third-party authoring 
and conversion tools.

17. 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.

18. MEDIUM: Consider recommending an Undo stack. A.4.1 discusses Undo and Redo, but only applies to a single operation. As one error may invalidate actions taken after it, and a user may not recognize an error immediately (especially when using AT), consider adding a Level AA or AAA success criteria about allowing the user to undo more than just the single most recent operation (i.e. a stack for undo or undo/redo operations).

19. 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.

20. MEDIUM: Identify accessibility features in documentation. B.3.3 requires that features that support the production of accessible content be documented, but I would suggest adding (either as a best practice or as a new SC) that the user should be able to find a list or index of such features. This would be equivalent to UAAG 2.0's "5.3.4 Centralized View: There is a centralized view of all features of the user agent that benefit accessibility, in a dedicated section of the documentation. (Level AA)" However, in ATAG this should apply to both accessible content support features and to features that make the tool's user interface accessible.

21. MEDIUM: Identify inaccessible practices demonstrated in documentation. In addition to B.2.4.1 requiring that a "range of examples in the documentation...demonstrate WCAG 2.0 Level A accessible authoring practices", consider adding an SC to the effect that any examples in documentation that demonstrate inaccessible authoring practices should include a warning to that effect.

Clarifying minimum requirements

Some success criteria are broad or vague on the minimum set of behaviors needed to conform, often presenting loopholes that would let a product comply with the letter of the requirement without meeting its intent or providing significant benefit to users. In effect, they set the bar so low as to be nearly useless. This is a common problem in many standards; here is a non-exhaustive set of examples from the ATAG draft:

22. MEDIUM: Low bar for A.3.4.1 Edit By Structure. "A.3.4.1 Edit By Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure. (Level A)" and "A.3.4.2 Navigate By Structure: Editing views for structured web content include navigation mechanism(s) that can make use of the structure. (Level A)" both seem particularly broad, as having any a single feature that makes use of structure would be enough to comply. That makes it easy for an authoring tool to comply with the letter of the requirement without addressing its spirit. For example, it appears that displaying a completely static outline of a document in a separate window would be enough to comply, even though it would provide relatively little benefit.

23. 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".

24. MEDIUM: Low bar for B2.1.1 Decision Support. Re "B.2.1.1 Decision Support", it seems the intent is that the author should be actively warned when the authoring tool does not support accessible content creation for a specific output format, but the wording is broad enough that all the authoring tool needs to do is (a) provide a note on the Web site or buried in their documentation, and (b) provide at least one output format for which it does provide accessible content creation. The authoring tool should be required to identify less accessible formats at the points where the author chooses one. (I feel this issue is handled much better in "B.2.5.4 Template Selection Mechanism", which says "the selection mechanism indicates...")

25. MEDIUM: Clarify minimum requirements for prominence. "Implementing Success Criterion B.2.1.2 Set Accessible Properties" might do well to clarify required prominence. For example, in the example given, if Alt and/or Longdesc had been in the sub-dialog accessed through the "More..." button, would it still comply? What if instead of providing fields for specific accessibility attributes, there was merely a text input field where the author could manually enter any additional attributes and their values?

26. MEDIUM: Clarify minimum requirements for B.2.2.1 Check Accessibility. "Implementing Success Criterion B.2.2.1 Check Accessibility (WCAG Level A)" again might do well to clarify whether active prompting of the user is required, or whether it is sufficient for the authoring tool's documentation to merely recommend manual checking. The Note seems to say that automatic testing is never required, even in cases where it is well understood and foolproof; is that actually the intention? (This also applies to B.2.3.1, etc.)

27. MEDIUM: Clarify minimum requirements for Help Authors Decide. "Implementing Success Criterion B.2.2.3 Help Authors Decide" again may want to clarify whether simply providing instructions in the manual or online help is sufficient, without any active prompting or guiding the user during their task. If not, how can you phrase it so this is clear?

28. 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?

29. 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.

30. 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.

31. MEDIUM: Clarify minimum for Provide Accessible Templates. "Criterion B.2.5.2 Provide Accessible Templates" strictly speaking says that the authoring tool needs to provide a minimum of two accessible templates in order to comply. If it includes ten different types of templates (e.g. themed home pages, forms, etc.) is the minimum still two total for the entire authoring tool?

32. MEDIUM: Clarify minimum for A.4.1.2 Undo Settings Changes. In "Implementing Success Criterion 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. (Level A)", what is the minimum acceptable level of functionality? Would it be acceptable for an application to make the user quit and restart the application to get out of a mode? What if the application provides only a single command to reset all settings to factory default? That would seem to not meet the intent, since it may reset settings that the user needs in order to make the application accessible. (See my other comment on this SC.)

33. MEDIUM: Clarify minimum for B.3.4.1 Model Accessible Practices. Re "B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)", because "a range" is undefined, the minimum is left unclear. One solution would be to formally require the practice you list in the example, which is that "most" examples demonstrate accessible rather than inaccessible practices.

Minor

34. MINOR: UI is not always under the control of the tool. In "PART A: Make the authoring tool user interface accessible", "Applicability Notes", "1. Scope of authoring tool user interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc." it is worth noting that things like menus can be completely under the control of the authoring tool (as in its own menus), or completely under the control of the author (as in "fake" menus created by scripts in the Web content), or a hybrid of the two (as in menus created specified by the authored content but implemented by the authoring tool (such as XUL menus).

35. MINOR: Additional benefit to autosave. A minor suggestion re "Implementing Success Criterion A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to save all content edits made by authors. (Level AAA)" is that an additional benefit of both document recovery and Undo capability is that while unfortunate, it is true that users with some disabilities experience a larger number of crashes and incorrect commands than the typical user, such as those caused when a speech recognition utility misunderstands the user, or when typing difficulties result in incorrect key-presses.

36. 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.

37. MINOR: Image metadata Description is not equivalent to longdesc. Re "B.2.4.2 Automated Suggestions", "(b) Relevant Sources: 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).", if your position is that the "long description" (e.g. longdesc or aria-describedby) should be a visual description, rather than a functional description or additional instructions, then it would not do to automatically use an image's Description metadata field defined by IPTC Core/XMP metadata, as those are equivalent to IPTC-NAA IIM 4.1 "Caption/Abstract" and thus not generally used for visual descriptions. (Whether the HTML5 equivalent of aria-describedby should be limited to visual descriptions is apparently an ongoing discussion.)

38. MINOR: Examples for automated omit confirmation. In "Implementing Success Criterion B.2.4.2 Automated Suggestions", the second example explicitly says that the user is given an opportunity to confirm or cancel the suggestion, as is required by the SC, but the other two examples omit this step. That encourages readers to think that confirmation is not an absolute requirement (especially given that the SC's current wording makes it easy to miss the fact that the list of requirements are AND rather than OR).

39. MINOR: Clarify it can use metadata that will be stripped. "Implementing Success Criterion B.2.4.3 Let User Agents Repair", although you certainly don't need to, you might want to elaborate on the existing example, that in this same scenario the authoring tool would be justified in generating repair alternative content based on the image metadata if it knows that metadata will be stripped from the image before it is presented to the user agent (e.g. Facebook).

40. MINOR: Clarify definition of template. Re "B.2.5.1 Templates Accessible (WCAG Level A)", would a task like inserting a radio button in a WYSIWIG form editor count as using a template? If so, you might want to include it as another example as people might not think of that type of operation as being a template. You might want to clarify this in the glossary entry for template.

41. 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.

42. MINOR: Another example of Accessible Options Prominent. In "Implementing Success Criterion B.3.1.1 Accessible Options Prominent (WCAG Level A)" you might include as another example that if a WYSIWIG editor includes a toolbar button to bold text, it should be implemented using <strong> rather than <span> (although it is welcome to use a specific style or class on the strong element if it wants to ensure that the user agent renders it as bold rather than using an alternative rendering).

43. MINOR: Example contradicts Active by Default. In "Implementing Success Criterion B.3.2.1 Active by Default", the example is supposed to show "ALL accessible content support features turned on by default" (emphasis added), yet the dialog box shows one of those features ("U.S. Section 508") turned off. Even if you have a reason for this, the first reaction of this reader was to be puzzled, then to decide it's probably an error...

44. MINOR: Methods of undoing settings changes. Something else to think about regarding "Implementing Success Criterion 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. (Level A)": the text noticeably does not mention "Undo" as a method for achieving this. I can tell you from first hand experience that when speech recognition enters the wrong command into a program, the user interface can be changed in a way that is very difficult to correct because you don't know what command made the change. That argues for an "undo" method for application settings. On the other hand, when applications like Adobe Photoshop Lightroom place interface changes and content changes into the same undo stack it causes another set of major usability problems.

45. MINOR: Ambiguous phrase in A.4.2.1 Document Accessibility Features. Re "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. (Level A)", this is probably silly but the phrase "features that are specifically required to meet" is grammatically ambiguous as to whether it means every feature that is specifically covered by Part A (e.g. all display of content, which is required to be implemented in such a way as to comply with A.2.2.2) or every feature that is implemented specifically to comply with Part A (e.g. undo, which A.4.1.1 requires to be implemented).

     Thanks,
     Greg