RE: Re: Some comments on ATAG Draft of 08 July 2010

Here is an update of the compiled comments with Greg Lowney's added.

Cheers,
Jan

--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
Faculty of Design | OCAD University


> -----Original Message-----
> From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf
> Of Richards, Jan
> Sent: September 11, 2010 4:04 PM
> To: w3c-wai-au@w3.org
> Subject: Re: Some comments on ATAG Draft of 08 July 2010
>
> Hi all,
>
> First, thanks to Greg for sending such a detailed review. My initial comments
> are below, marked "JR":
>
>
> > (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."
>
> JR: I agree that DOMs should be mentioned as a possible implementation in the
> definition and Implementing guide. Not Substantive.
>
> >
> > 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)
>
> JR: I agree that the scopes are different. The "editable" part was intentional
> to help bound the requirement. It should be added back in to the SC.
> Substantive.
>
> >
> > 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.
>
> JR: Agreed. We need to be careful here to think about other authoring UIs,
> such as forms. Substantive.
>
> >
> > 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)"
>
> JR: I like alert on no match, but for the other, it seems to assume the UI
> renders the content. Showing the results in a list for example would be fine.
> Substantive.
>
>
> > 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.
>
> JR: Previews already have an exception in the Part A Applicability notes #4,
> but perhaps this can be made more clear. Maybe we could say "respect the
> system settings as a default"? Substantive.
>
> >
> > 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."
>
> JR: This is covered in Part A Applicability Note#4, but other commenters have
> also noted this, so a Note makes sense. Not Substantive.
>
> >
> > 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.
>
> JR: Agreed. Substantive.
>
> >
> > 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.
>
> JR: As a W3C recommendation I think we should stick to Web content. It would
> be fairly easy to apply ATAG 2.0 to Word processor docs if one wished too.
> Maybe Substantive.
>
> >
> > 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.
>
> JR: Agreed. Not substantive.
>
> >
> > 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:
>
> JR: Agreed. It's not actually the case since we have lots of conditionals. Not
> substantive.
>
> >
> >     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".
>
> JR: Needs WG discussion. Substantive.
>
> >
> > 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).
>
> JR: Agreed. Substantive.
>
> >
> > 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.
>
> JR: Agreed. Not substantive.
>
> >
> > 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).
>
> JR: This is intended to be addressed by the phrasing "text value". We should
> make it more clear in the Implementing doc. Typo alert: "text value that
> is"=>text values that are.
>
>
> > 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.
>
> JR: We are trying to be sensitive to the workflows of enterprise systems.
> Perhaps we could add a last sentence: "Accessible Content Support Features
> should be made available to any author role where it would be useful." Not
> substantive - in Implementing doc.
>
> >
> > 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.
>
> JR: That would be nice, but may be unrealistic. E.g., when converting vector
> info to bitmap and back there simply is nowhere for the accessibility info to
> go. Maybe an OPTION to create a backup copy in the original format should be
> the only requirement. Would be substantive.
>
> >
> > 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.
>
> JR: I prefer exempting Undo. Substantive.
>
> >
> > 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).
>
> JR: It's a good practice, but then how tall of a stack? 2, 10, more? Would be
> substantive.
>
> >
> > 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.
>
> JR: Right, but only IF the UI is modifiable. Not substantive.
>
> >
> > 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.
>
> JR: I feel like this may be too prescriptive. e.g. it would rule out a very
> well implemented context sensitive system. Substantive.
>
> >
> > 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.
>
> JR: While I can see the point, I think it might be too prescriptive.
>
> >
> > 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.
>
> JR: Point taken, but the ways structure can be used is simply too broad to be
> more specific. I think we wanted to plant the idea with developers and hope
> that the curb-cut effect encourages more.
>
> >
> > 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".
>
> JR: Point taken, but the combinations of functions and keys available is too
> large to be more specific. I think we wanted to plant the idea with developers
> and hope that the curb-cut effect encourages more.
>
>
> > 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...")
>
> JR: We wanted to steer away from saying there are "accessible" and
> "inaccessible" formats to emphasizing what THE TOOL IN QUESTION does to
> support accessible authoring in the format.
>
> >
> > 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?
>
>
> JR: I think this is sufficiently covered by: 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).
>
> >
> > 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.)
>
> JR: The intention is to require some kind of checking, even if it is manual,
> in hope that usability concerns will kick in and encourage developers to
> automate the tasks they can for their users.
>
> >
> > 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?
>
> JR: Maybe we should state that the decision support is part of the check
> (whether semi-automated or manual).
>
> >
> > 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?
>
> JR: Point taken, but at some point we can't control bad UI.
>
> >
> > 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.
>
> JR: Maybe "programmatically" associated, which could be either internal or
> external.
>
> >
> > 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.
>
> JR: Maybe we should reword to look at it from the other side. That we want an
> automated suggestion system where the suggestions are the authors previous
> entries for THAT object. Substantive.
>
> >
> > 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?
>
> JR: Not perfect, but yes. Maybe at AAA we should require all templates to be
> accessible.
>
> >
> > 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.)
>
> JR: Maybe we add "immediately reversible without affecting any other
> settings"?
>
> >
> > 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.
>
> JR: So 50%+1? These numerical ones are always tricky.
>
>
> > 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).
>
> JR: Perhaps we could briefly address user configurable authoring interfaces.
>
>
> > 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.
>
> JR: Agreed.
>
>
> > 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.
>
> JR: Agreed.
>
>
> > 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.)
>
> JR: That's why we put this in: (a) Author Control: Authors have the
> opportunity to accept, modify, or reject the suggested alternative content
> prior to insertion; and
>
>
> > 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).
>
> JR: Agreed.
>
>
> > 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).
>
> JR: Agreed.
>
>
> > 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.
>
> JR: Agreed.
>
>
> > 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.
>
> JR: Agreed
>
> >
> > 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).
>
> JR: Agreed.
>
> >
> > 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...
>
> JR: Agreed.
>
>
> > 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.
>
> JR: Maybe we can address this in the Implementing doc.
>
>
> > 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).
>
> JR: Agreed. I suggest: A.4.2.1 Document Accessibility Features: All features
> that must be present to meet Part A of this document (e.g. keyboard shortcuts,
> text search, etc.) are documented. (Level A)
>
> >
> >     Thanks,
> >     Greg
>
>
> Cheers,
> Jan
>
> --
> (Mr) Jan Richards, M.Sc.
> jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
> Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
> Faculty of Design | OCAD University
>
>