Comments on Developers' Guide to Features of Web Accessibility Evaluation Tools Draft

Thanks for the opportunity to review the document (http://www.w3.org/TR/2014/WD-WAET-20140724/). Please find my comments below:

1.1: 
- re: quote of the definition of "Web authoring tool": I'm glad this definition is being quoted. Perhaps it should be made a bit more clear that this is just quote from a longer definition
- re: Web quality assurance tool: Perhaps some examples of other quality criteria could be included (e.g. broken links, etc.) 

2
- It would help if the "Features of an accessibility evaluation tool" terminology matched the wording of features in the list of evaluation tools (http://www.w3.org/WAI/ER/tools/advanced). Since that older document is to refreshed, perhaps its wording can be refreshed if that makes more sense.

2.1.4:
- Related to Dynamic Content, I wonder if the document should touch on the difference between testing "the code" and testing the onscreen rendering. In the future I can imagine more "AI" coming into the process e.g. to determine if an alt-text is likely to be appropriate for an image, to check if captions match the soundtrack, etc.

2.1.6:
- "an reuse it"->"and reuse it"

2.1.9:
- use of term "Customers" is odd. In other places, they are referred to simply as "users".
- " It is typical from web resources to link many times to the same resource "->" It is typical for web resources to link to the same resource many times."

2.2.2
- ATAG 2.0 has very similar wording: http://www.w3.org/TR/ATAG20/#def-Checking
- This statement seemed like it needs some smoothing out "Some tools do not declare that they only perform automatic testing. Since it is a known fact that automatic tests only cover a small set of accessibility issues, full accessibility conformance can only be ensured by supporting developers and accessibility experts while testing in manual and semiautomatic mode." In particular:
 
2.2.3:
- "need sometimes"->"sometimes need"

2.3.1
- in order to make this claim, it would be useful to have a list of tools than can read-in these reporting languages.

2.3.3
- Does not seem to add anything beyond what 2.3.1 does

2.3.6
- "assess quickly" -> "quickly assess"
- re: As described in 2.2.2: Or semi-automated checking

2.3.7:
- "Tools may provide together with their reporting capabilities additional information to support developers and accessibility experts to correct the accessibility problems detected." ->  "Together with their reporting capabilities, tools may provide additional information to support correction of the accessibility problems detected."
- "If the evaluation tool is part of an authoring tool as described in the Authoring Tool Accessibility Guidelines 2.0 [ATAG], then the tool will meet its success criterion B.3.2.1." - Careful how you refer to meeting SC's...the repair functionality must cover the full range of issues the checker could uncover...not just some of them.

 2.4.1 & 3:
- In "Workflow" I expected a bit more discussion of different types of error displays (e.g. a list vs embedded icons) as well as bug system integration.
- Since not everyone can imagine what you mean from the text, it would help to have example screenshots of tools would be useful here. Perhaps there is something that can be borrowed from the ATAG mockups here: http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/#checking-types ; http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/#prompting-types)

2.4.3:
- "web commissioners" - I just haven't hear the term before

2.4.5
- especially Part A of ATAG 2.0

3.1
- "allows to export the" -> "allows the export of"


Cheers,
Jan

(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca

Received on Friday, 1 August 2014 18:54:33 UTC