- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Tue, 23 Feb 2010 16:02:47 -0500
- To: WAI-AUWG List <w3c-wai-au@w3.org>
Draft responses to the IBM feedback...all of the items have responses.
IBM FEEDBACK 1
(http://lists.w3.org/Archives/Public/w3c-wai-au/2009OctDec/0047.html)
=================================================================
...
> *General / global comments*
>
> 1. *Applicability to Mobile devices* ATAG 2.0 is written to be
> technology agnostic. Is there value is reminding the reader in the
> document that it applies to mobile devices as far as web
> applications are accessed through mobile browsers? For example,
> this might be appropriately added in the _definition of web
> content_
>
<http://www.w3.org/TR/2009/WD-ATAG20-20091029/#def-Web-Content-Technology>
RESPONSE: We added this to the examples of authoring tools: "software
for creating mobile web applications"
> 2. *Repair assist* It appears to me from reading that ATAG
> requires checking and repair options for all WCAG checkpoints. I
> wonder if this is intended to be fully encompassing. There are
> checkpoints that are very difficult to automate detection and even
> harder to automate repair. For example, the recognition that color
> is being used without alternate form, is very difficult to
> automate. I'm just checking that the intent is that all
> checkpoints are checked.
RESPONSE: The relevant notes were updated for clarity:
"Note: Automated and semi-automated checking is possible for many types
of web content accessibility problems. However, manual checking is the
minimum requirement to meet this success criterion. In manual checking,
the authoring tool provides authors with instructions for detecting
problems, which authors must carry out by themselves. For more
information on checking, see Implementing ATAG 2.0 - Appendix B: Levels
of Checking Automation."
"Note: Automated and semi-automated repair is possible for many types of
web content accessibility problems. However, manual repair is the
minimum requirement to meet this success criterion. In manual repair,
the authoring tool provides author(s) with instructions for repairing
problems, which authors must carry out by themselves. For more
information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of
Repair Automation."
> *Section specific comments*
>
> 1. *Abstract; Introduction.* Suggest adding hyperlink to
> "Implementing ATAG 2.0" at first reference in each section. As it
> stands, several references are made in these sections, but the
> first hyperlink is not provided until the Guidelines section, and
> then only in the Guideline A.1.1 box – not obvious to identify or
> find.
RESPONSE: Done.
> 2. *PART A, Guideline A.1.2* The link provided "Implementing
> A.1.2" is incorrect. It links to
>
"http://www.w3.org/TR/2009/WD-IMPLEMENTING-ATAG20-20091029/#gl-Web-based-accessible",
> which is the same link as "Implementing A.1.1" I believe it is
> intended to link to:
>
"http://www.w3.org/TR/2009/WD-IMPLEMENTING-ATAG20-20091029/#gl-non-Web-based-accessible"
RESPONSE: Done.
> 3. *Guideline A.3.1* This guideline is worded "Enhance keyboard
> access to authoring features." The word enhance infers to me that
> this is an extended enhancement beyond minimal. I believe the
> intent is to require keyboard access for all function. I suggest
> wording such as, "Ensure keyboard access..." or "Provide keyboard
> access..." be considered.
RESPONSE: Reworded as "Provide keyboard access to authoring features."
> 4. *Guideline A.4.2 ... Document the user interface* The
> documentation should be provided in at least one accessible
> format. Perhaps this is obvious to the reader, but I don't see
> this stated in the /TR Draft/ or the /Implementing/ document. I
> would hate to see someone weasel out of it.
RESPONSE: We cover this with the intent text "The accessibility of the
documentation is covered by Guideline A.1.1 and Guideline A.1.2." ALSO
the following were done:
- added an applicability note at the top of Part A ("Features for
meeting Part A must be accessible:..."
- added "ACCESSIBLE documentation" to the rationale of this section.
- Adding text to the example: "The documentation conforms to WCAG 2.0
Level A..."
> 5. *PART B; Existing Technologies* Please check the wording of
> this section. Something appears to be extra/missing/erroneous:
> "The Part B success criteria /in only apply/ to support for
> production of web content..."
RESPONSE: Done.
> 6. *Guideline B.1.2; Rationale* Please double check that the
> wording selected covers retaining accessible information that
> comes from a non-web source. For example, the headings and
> alternate text in a non-web word editing document that is output
> to HTML. Please see related comments about the /Implementing/
> document, that the intent wording seems to limit the intent only
> from /web/ transformed to /web/.
RESPONSE: Reworded for clarity "Accessibility information is critical to
maintaining comparable levels of accessibility between the input and
output of web content transformations."
> 7. *Guideline B.2.2; B.2.2.4 Help Authors Locate* This may seem
> obvious, but it might be useful to state that it should be located
> or indicated in an accessible manner. Tools often highlight
> problems. This is sometimes accessible only to the sighted.
RESPONSE: Reworded, adding highlight: " For any checks that require
author judgment to determine whether a potential web content
accessibility problem is correctly identified (i.e., manual checking and
semi-automated checking), the relevant content is identified (e.g.,
highlight the affected content, displaying line numbers, etc.) (Level A)"
> 8. *Guideline B.3.3;* Documentation of authoring tool support for
> production of accessible content should be provided in an
> accessible format.
RESPONSE: This is covered by this Part B applicability note: "Features
for meeting Part B must be accessible: The Part A success criteria apply
to the entire authoring tool user interface, including any features
added to meet the success criteria in Part B (e.g., checking tools,
repair tools, tutorials, documentation, etc.)."
IBM FEEDBACK 2
http://lists.w3.org/Archives/Public/w3c-wai-au/2009OctDec/0063.html
=================================================================
Sueann Nichols wrote:
> Below is additional feedback from IBM:
>
> *Section specific comments*
>
> 1. *Guideline A.1.2* This is a general comment about the non web
> accessibility compliance points: There are no restrictions on what an
> accessibility standard is. It is user defined now. Consequently, the
> evaluator could define their own compliance claims.
RESPONSE: That's correct, but it would be a major challenge to be
objectively prescriptive about what form the guidance will take while
still covering all of the platforms. In order to clarify this point, the
following has been added to the intent:
"Intent of Success Criterion A.1.2.1:
The intent of this success criterion is to ensure that authoring tool
user interfaces that are not web applications are accessible to authors
with disabilities. In formulating a requirement that would best fulfill
this intent, the Working Group decided upon a requirement to follow and
cite the accessibility standards and platform conventions that already
exist for many platforms. It was decided that this was the best approach
because:
1. the requirement to "cite in the conformance claim", which is
published on the Web, would mean reputable developers would refrain from
implementing obscure or weak requirements.
2. the "accessibility standards" wording allows developers the scope
to harmonize with accessibility legislation in their markets.
3. "platform conventions", by their nature, include
platform-specific details such as API calls and look-and-feel examples
that generic software guidance cannot.
4. "accessibility standards" and "platform conventions" will
continue to progress even after the publication of these guidelines.
Note: Developers should take note of the documents listed in the
"Related Resources for Success Criterion A.1.2.1" section, below. Unless
extenuating circumstances exist (e.g., a document has been superseded,
the platform has undergone major architectural changes), the listed
resources should be assumed to be relevant to the platforms listed."
> 2. *A.1.2.1* In WCAG, it is not a requirement to make a conformance
> claim. This provision seems to require that authoring tools make a
> claim. Suggest removing "and cite in the conformance claim)" and adding
> an additional sentence: "If an ATAG 2.0 conformance claim is made, the
> claim should cite the accessibility standards and/or platform
> conventions that were followed.
RESPONSE: Agreed. This text has been added: "If a conformance claim is
made, then the conformance claim must meet the following conditions and
include the following information (authoring tools can conform to ATAG
2.0 without making a claim):"
> 3. *A.2.1.1* Define "accessible" as used in the context of this
provision.
RESPONSE: Reworded: A.2.1.1 Recognized Alternative Content: If
recognized alternative content is available for editing view content
renderings, then the alternative content is provided to the author(s).
> 4. *A.2.2.2* The use of "and" at the end of each item in the list seems
> redundant with the wording of the provision ("any of the following").
RESPONSE: This is the convention used by WCAG 2.0. e.g., see 2.2.1
Timing Adjustable.
> 5. *A.2.2.2* If you are accessing text, you need access to the caret
> position, and the selected text. Does use of a text view preclude
> embedded objects? If not then they need to be accessible as well.
RESPONSE: This is meant to refer to text presentation characteristics
only. The "caret position" and "the selected text" are assumed to be
part of most platform requirements and so covered by A.1.2.1.
> 6. *A.3.1.1* The provision is repeated. Why is this provision needed? It
> is already required by provision A.1.1.1.
RESPONSE: The provision has been reworded. In general, because ATAG2
applies to non-Web-based applications, WCAG requirements sometimes need
to be repeated.
> 7. *A.3.2.2* Why is this provision needed? It is already required by
> provision A.1.1.1.
RESPONSE: As above, because ATAG2 applies to non-Web-based applications,
WCAG requirements sometimes need to be repeated. This line has been
added to the intent: "Web-based authoring tools will already be required
to meet this success criterion as part of a Success Criterion A.1.1.1."
> 8. *A.3.2.3* This provision is an example of a WCAG requirement that is
> made for stringent in ATAG. There's no issue with doing that when there
> is a good reason which in this case, I think there is. But the problem
> is that the authoring tool developer may have already implemented one of
> the other strategies that are allowed by WCAG. Somewhere ATAG should
> call out where there are provisions that override WCAG provisions. Maybe
> in A.1.1.1?
RESPONSE: The following text now appears in the intent of A.1.1.1: "Some
success criteria in Part A that are based on WCAG 2.0 may in some cases
be more stringent than WCAG 2.0. In most cases, this is because authors
need to be able to edit all web content, while certain types of content
(e.g., decoration, invisible content) are not as important to an end
user's experience."
> 9. *A.3.2.3* This checkpoint only says to stop. Per WCAG 2 you want to
> be able to Pause and Hide content.
RESPONSE: Done.
> 10. *A.3.4.2* This should include role types such as ARIA roles.
RESPONSE: After debate, the WG decided that being prescriptive about
what kinds of structural navigation were required was
counter-productive, so all of the sections have been combined into one
requirement: "A.3.4.2 Navigate By Structure". Navigation by roles is now
mentioned in the intent: "navigation by role: the ability to move focus
between elements identified by their roles "
> 11. *A.3.4.2* There should be a navigate by relationships: labels,
> controls, describedby, etc. should those features be supported.
RESPONSE: See above. Navigation by relationship is now mentioned in the
intent: "navigation by accessibility relationships: the ability to move
focus between elements bound by accessibility relationships (for
attribute of label in HTML4, aria-describedby, etc.). "
> 12. *A.3.4.3* Should be scoped to structured element sets that have
> heading elements. Suggest changing "If an editing view displays a
> structured element set" to "If an editing view displays a structured
> element set that includes heading elements".
RESPONSE: See above. Navigation by headers is now mentioned in the
intent: "navigation by headers: the ability to move focus between
elements identified as headers in the markup (e.g., h1, h2, etc in HTML4). "
> 13. *A.3.4.4* Parent and child need clarifying. Suggest " *Parent:* The
> owning element" and *"Child:* The first owned element" ARIA or HTML
> might have some better wording.
RESPONSE: See above. Navigating tree structures is now mentioned in the
intent: "tree navigation: the ability to move focus to the elements up,
down and across tree structures. "
> 14. *A.3.6.1* and *A.3.6.2* What about auditory settings? Most authoring
> tools don't have them but if they do, shouldn't the preference setting
> be saved?
RESPONSE: The definition of "display setting"
(http://www.w3.org/WAI/AU/2009/ED-IMPLEMENTING-ATAG20-20091221/#def-Display-Settings)
already includes display settings (audio), display settings (visual) and
display settings (tactile)
> 15. *A.3.7.2* See comment on A.1.2.1 regarding requiring conformance
> claims (item a).
RESPONSE: Reworded: " A.3.7.2 Preview: If a preview is provided, then at
least one of the following is true: (Level A) [Implementing A.3.7.2]
(a) Third-Party User Agent: The preview makes use of an existing
third-party user agent; or (b) UAAG (Level A): The preview conforms to
the User Agent Accessibility Guidelines Level A [UAAG]."
> Item b may not be possible if the author has not met
> the requirements of WCAG (included text alternatives, provided
> structural markup, etc.)
RESPONSE: Item b was removed.
> Is item c referring to UAAG version 2.0? If
> ATAG 2.0 is on track to finish first, it may be problematic to reference
> a standard that is not yet complete and I don't think we want to be
> referencing UAAG 1.0 which may be outdated.
RESPONSE: This is now addressed in the intent:
"The most straightforward way to meet this success criterion is for
authoring tools to simply implement preview features using user agents
that are already in use by end users - see (a). This might be done in
several ways, including by opening the content in the author's default
user agent or by making use of a user agent widget nested within the
authoring tool's own user interface. On the other hand, if a preview is
being developed that is already a departure from existing user agents,
then the W3C User Agent Accessibility Guidelines (UAAG) must be followed
- see (b). At the time of publication, UAAG version 1.0 is a W3C
Recommendation and version 2.0 is under development. Note: Developers
may develop a preview from scratch that does not meet (b) as long as
authors retain the option to preview using their own user agent, since
this meets (a)."
Cheers,
Jan
Received on Tuesday, 23 February 2010 21:03:29 UTC