W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 2010

RE: ATAG 2.0 Last Call Comments from the WCAG Working Group

From: Richards, Jan <jrichards@ocad.ca>
Date: Mon, 30 Aug 2010 14:53:01 -0400
To: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <F2C77FB59A1A4840A01EF5F59B1826E209092E8FA3@ocadmail.ocad.ca>
Hi all,

Here are some thoughts (marked JR) on comments we received from the WCAG WG over the weekend. Where I mention "substantive change" I'm referring to the meaning in the W3C Process document:
"A substantive change (whether deletion, inclusion, or other modification) is one where someone could reasonably expect that making the change would invalidate an individual's review or implementation experience. Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections)"

> -----Original Message-----
> From: public-atag2-comments-request@w3.org [mailto:public-atag2-
> comments-request@w3.org] On Behalf Of Loretta Guarino Reid
> Sent: August 27, 2010 8:38 PM
> To: public-atag2-comments@w3.org
> Cc: WCAG
> Subject: ATAG 2.0 Last Call Comments from the WCAG Working Group
> *** General Comments
> Consolidate WCAG 2.0 related SC: A number of the guidelines include SC
> that reference conformance to WCAG 2.0 at various conformance levels.
> Consider combining these to reduce the overall number of success
> criteria and to minimize repetition and cross-references in the
> implementation guide.
> For example, combining the three SC listed in A.1.1 might look like:
>     A.1.1.1 Web-Based Accessible (WCAG Conformance): Web-based
> authoring tool user interfaces conform to WCAG 2.0 at one of the
> following conformance levels.
>         * Level A: For Level A conformance, web-based authoring tool
> user interfaces conform to WCAG 2.0 Level A. (Level A)
>         * Level AA: For Level A conformance, web-based authoring tool
> user interfaces conform to WCAG 2.0 Level AA. (Level AA)
>         * Level AAA: For Level A conformance, web-based authoring tool
> user interfaces conform to WCAG 2.0 Level AAA. (Level AAA)
> A similar approach should be considered for the B.1.1.x, B.1.3.x,
> B.2.2.x, B.2.3.x, B.2.5.x, etc.

JR: We should consider this. Some other ideas are here: http://lists.w3.org/Archives/Public/w3c-wai-au/2010JulSep/0053.html
(not substantive change)

> *** Comments on specific SC
> A.1.2.1 While we agree with the approach and the rationale cited in
> the implementation guide, this SC, specifically "...and/or platform
> conventions..." may not be testable. How does an authoring tool
> developer determine whether they have followed enough platform
> conventions to pass? Suggest revising this SC to make it more testable
> and adding additional detail to the implementation guide to clarify
> what would be required.

JR: Obviously it's not a "number" issue. If we say "At least one" it would be testable and we could back it with more explanation. (change request is substantive, my suggestion would not be)

> A.2.2.2: Consider adding background color to the list of minimum
> presentation properties for text.

JR: (change request is substantive)

> A.3.2.2 Timing Adjustable: What would be an example of an authoring
> tool time limit where extending the time limit would invalidate the
> activity (e)?

JR: Authoring something as part of a exam perhaps.

> A.3.2.4 Content Edits Saved (Extended): Suggest revising this SC to
> include "automatically" (The authoring tool can be set to
> [automatically] save all content edits made by authors.)

JR: Agreed. (change request is not substantive)

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

JR: Agreed. (change request is not substantive)

> A.3.7.2 Preview: As worded, it appears that a UA that utilizes any
> third-party user agent for preview would automatically meet this SC.
> Suggest that part (a) be revised to require the use of the author's
> default user agent, which would avoid a situation where the author is
> unable to preview content in the UA that best meets their
> accessibility needs.

JR: We had wanted to leave this up to developers - e.g. to embed user agents directly into the authoring tool UI (change request is substantive).

> A.4.2.1 Document Accessibility Features: Suggest incorporating the
> accessibility of the documentation in the SC text itself or include
> the note from the implementation guide, "The accessibility of the
> documentation is covered by Guideline A.1.1 and Guideline A.1.2." with
> the SC.

JR: Agree with adding note. (change request is not substantive).

> B.1.2.2(a): "Option to Save: authors have the option to save the
> accessibility information in another way (e.g., as a "comment", as a
> backup copy of the input);" It would be great to add "accessible" to
> "authors have the option to save the accessibility information in
> another [accessible] way."

JR: Need to discuss: Accessible to whom? The author or the user? (change request may be substantive).

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

JR: Need to discuss. (change request may be substantive).

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

JR: Need to discuss. (change request may be substantive).

> Guideline B.1.3 "Ensure that automatically generated content is
> accessible" and note "See Also: If accessibility information is
> required from authors during the automatic generation process, see
> Guideline B.2.1." It's not clear how the SC under Guideline B.2.1 help
> retrieve accessibility information from authors. Guideline B.2.3 seems
> to be the most relevant for providing assistance, though "repair" may
> not be fully accurate as it would apply to Guideline B.1.3. However,
> given that "actions of authors" is exempt and seems to include the
> provision of accessibility information (faulty or otherwise) then this
> may be a moot point.

JR: That B.2.1 reference is outdated and should be removed (change request not substantive).

> B 2.1.1 (a) and elsewhere term "accessible content" is used where
> perhaps "conforming with WCAG 2.0" would be better.

JR: We should do a better job of tying in WCAG 2.0 there (change request not substantive since that's in our definition of "web content, accessible")

> B.2.3.1: Typo refers to Guideline B.2.2 should be, "as required by SC
> B.2.2.1."

JR: Agreed - typo (change request not substantive).

> B.2.4.1 Editable: "Authors are able to modify...," may be difficult to
> test and it can be argued that it has been met in situations where
> it's possible, but more difficult for an author with a disability to
> make the change. Consider incorporating into the requirement or the
> implementation guide something about the ease with which an author can
> make the modification. The "at least as prominent" concept from
> B.2.5.6 may be a way to address this concern.

JR: The point is that all authors need to be able to edit alternative content. (change request may be substantive).

> B.2.4.2 Automated Suggestions: The use of the word "can" makes this SC
> sound like it's optional. "During the authoring session, the authoring
> tool can automatically suggest alternative content..." Suggest "can
> [be configured to] automatically suggest...."

JR: It is meant to be optional. Maybe needs more explanation as to why in the "Implementing" doc.

> B.2.5.2 Provide Accessible Templates: Suggest incorporating a
> requirement to clearly identify accessible template options. (ex. "If
> the authoring tool provides templates, then there are accessible
> template options for a range of template uses [and accessible
> templates are clearly identified as such]." Another approach would be
> to require that they be "at least as prominent as other templates.

JR: That's in B.2.5.4.

> B.3.2.1 Active by Default: Consider softening this requirement to
> include a subset of support features (ex. those that relate to WCAG
> Level A). Alternatively, consider changing the level of this SC. The
> concern here is that automatic tests, especially at Levels AA and AAA,
> often lead to repetitive and erroneous error and warning messages,
> which could result in authors being motivated to turn off accessible
> content support features altogether.

JR: Hard to control bad UI design. But if they start off they may NEVER get turned on. I suggest adding more Implementing guidance on this point instead. (change request may be substantive)

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

JR: Need to discuss. (change request is substantive)

> B.3.4.1, B.3.4.2, B.3.4.3: Consider adding a requirement to these SC
> that the accessible examples be clearly identified and at least as
> prominent as other examples in the documentation.

JR: The idea is that they don't need to be clearly identified - they are simply worked into the routine documentation. (change request is substantive)

> Conformance
> Required Components of an ATAG 2.0 Conformance Claim #5 (Authoring
> tool information): Consider adding information about the role and
> requirements for information about extensions, plugins or modules that
> may have modified or extended the authoring tool to meet a
> requirement.

JR: I think the note covers it, but we could try to be more clear. (change request is not substantive)

> Required Components of an ATAG 2.0 Conformance Claim #6 (Web content
> technologies produced): Consider dropping the requirement for a list
> of technologies not included as this can be derived from the list of
> technologies that the tool is capable of producing when compared to
> the list of technologies included in the claim.

JR: Sometimes tools "Save As" some formats and "Export" to others etc. It would be easier for the reader of a conformance claim to know what the Claimant thought they were. (change request may not be substantive)

> Required Components of an ATAG 2.0 Conformance Claim #7 (Declarations)
> and Checklist: This requirement implies that each claim would have to
> list each SC that is met. It should be possible to declare a range of
> SC that have been met. (ex. All Level A). Additionally, inviting
> claimants to declare success criteria that are not applicable may be a
> slippery slope and often leads to inaccurate claims. Instead, suggest
> including a statement that says that where an authoring tool does not
> include a feature that is relevant to a given SC, then that SC is
> automatically satisfied.

JR: Personally, I think it is more clear to have to address each SC individually. In addition, I think "automatically satisfied" is more "slippery" because it leads provides less information as to the thinking of the Claimant. (change request is substantive)

> Waiving of WCAG 2.0's conformance requirement #4: Only
> Accessibility-Supported Ways of Using Technologies. Many of ATAG's
> success criteria rely on conformance with WCAG 2.0 but allow for
> information or functionality provided in a way that is not
> accessibility supported. This is potentially quite a loophole and can
> easily mislead (intentional or not) the intended audience regarding
> the production of content that conforms to WCAG 2.0.

JR: I understand the concern, but the cross-cutting nature of authoring tools makes it very difficult. Not sure how we can handle this. Maybe a separate link from all instances of "conform" to a clarifying note? Maybe expanding the explanatory text in the relevant section "Note on 'accessibility-supported ways of using technologies'"? (change request is likely substantive)

> Glossary
> Many of the defined terms in ATAG 2.0 differ from those in WCAG 2.0
> and/or make notes and examples from the WCAG 2.0 definitions a part of
> the definition itself in ATAG 2.0 . We found the resulting definitions
> confusing. We suggest synchronizing and formatting these definitions
> so that they are consistent across the WAI guidelines. Examples
> include "keyboard interface," "label," "non-text content" etc.

JR: Need to discuss. The WG felt that changing the phrase+notes structure of WCAG's definitions to sentences was more clear. Maybe we should put in a general note that we didn't intend to change the sense of definitions unless noted (and then note the exceptions).

> There were only three terms that were different enough to warrant a
> review. We are concerned that it may not be clear to readers that
> these definitions are intended to be the same. We would encourage you
> to use the WCAG definitions as closely as possible, augmented by
> additional information needed to address ATAG-specific considerations.
> 1. assistive technology: We suggest that you use the WCAG definition
> with an additional note about authoring tools providing direct
> accessibility features.
> assistive technology
>     Software (or hardware), separate from the authoring tool, that
> provides functionality to meet the requirements of users with
> disabilities. Some authoring tools may also provide direct
> accessibility features.
> assistive technology
>     hardware and/or software that acts as a user agent, or along with
> a mainstream user agent, to provide functionality to meet the
> requirements of users with disabilities that go beyond those offered
> by mainstream user agents
>     Note 1: functionality provided by assistive technology includes
> alternative presentations (e.g., as synthesized speech or magnified
> content), alternative input methods (e.g., voice), additional
> navigation or orientation mechanisms, and content transformations
> (e.g., to make tables more accessible).
>     Note 2: Assistive technologies often communicate data and messages
> with mainstream user agents by using and monitoring APIs.
>     Note 3: The distinction between mainstream user agents and
> assistive technologies is not absolute. Many mainstream user agents
> provide some features to assist individuals with disabilities. The
> basic difference is that mainstream user agents target broad and
> diverse audiences that usually include people with and without
> disabilities. Assistive technologies target narrowly defined
> populations of users with specific disabilities. The assistance
> provided by an assistive technology is more specific and appropriate
> to the needs of its target users. The mainstream user agent may
> provide important functionality to assistive technologies like
> retrieving Web content from program objects or parsing markup into
> identifiable bundles.
> [[Examples listed for assistive technology were the same for both
> documents.]]

JR: I think I'm ok with this. Needs discussion.

> 2. programmatically determined: We suggest that you use the WCAG
> definition and include your second sentence as a Note.
> programmatically determined (programmatically determinable)
>     When information is encoded in a way that allows different
> software, including assistive technologies, to extract and present the
> information in different modalities. For non-web-based user
> interfaces, this means making use of a platform accessibility
> architecture. For web-based user interfaces , this means following
> WCAG 2.0 so that the user agent can pass on the information.
> programmatically determined (programmatically determinable)
>     determined by software from author-supplied data provided in a way
> that different user agents, including assistive technologies, can
> extract and present this information to users in different modalities
>     Example 1: Determined in a markup language from elements and
> attributes that are accessed directly by commonly available assistive
> technology.
>     Example 2: Determined from technology-specific data structures in
> a non-markup language and exposed to assistive technology via an
> accessibility API that is supported by commonly available assistive
> technology.

JR: I think I'm ok with this. Needs discussion.

> 3. non-text content: We believe that it is critical that your
> definition include the phrase "can be programmatically determined".
> non-text content
>     Any content that is not a sequence of characters that can be
> recognized or where the sequence is not expressing something in human
> language. This includes ASCII Art (which is a pattern of characters),
> emoticons, and images representing text.
> non-text content
>     any content that is not a sequence of characters that can be
> programmatically determined or where the sequence is not expressing
> something in human language
>     Note: This includes ASCII Art (which is a pattern of characters),
> emoticons, leetspeak (which uses character substitution), and images
> representing text

JR: I think I'm ok with this. Needs discussion.


(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
Received on Monday, 30 August 2010 18:53:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:59 UTC