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

Draft responses to IBM Feedback v1 and v2

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 23 Feb 2010 16:02:47 -0500
Message-ID: <4B844277.2020105@utoronto.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 21:03:31 GMT