| Responder | Comments on new Developers' Guide to Features of Web Accessibility Evaluation Tools by ERT WG |
|---|---|
| Joshue O Connor | Good job, but a couple of omissions (deliberate or otherwise) struck me. The introduction mentions procure processes. Are there any W3C guides to accessible procurement, or other examples of best practice that could be pointed too? What about CEN/BTWG 185 or EN 301 549?. Also what about mentioning specific DOM inspection tools a la Firebug, or even the standard tools within Firefox, Chrome? These are conspicuous in their absence. The document seems to list specific requirements of particular tools for effective evaluation but then doesn't complete the loop for the reader by giving a steer about which ones do make the grade. I know this is due to not wanting to be seen to endorse any given tool but for the average reader may not be very satisfying as they will have to do the work so go through a manual check to compare that any tool they are using does to the list of requirements/comparison in the table in 3.4 Side-by-side comparison [...] . |
| Bruce Bailey | Looks great for a first draft. What I would like is a commitment from a few tool vendors to self report using the format. |
| Andrew Kirkpatrick | Just a few nits Do CSS documents and script documents themselves count as "content"? "Web and cloud applications are becoming very frequent on the web" -- it's official, they "are common" (rather than "are becoming very frequent"). 2.4.5: odd sentence "Additionally, when producing reports (for instance, in HTML format), it is important that they are accessible as well and in compliance with the Web Content Accessibility Guidelines 2.0 [WCAG20]." |
| David MacDonald | Would like to see a line that only about 14%-20% of WCAG can be evaluated automatically, in the best of circumstances. ----- The main purpose of this document is to promote awareness on <of> such tool features and to provide <delete>an</delete> introductory guidance for tool developers on what kind<add>s</add> of features they could provide in future implementations of their tools. |
| Michael Cooper | There's a bit of informality to the tone that needs to be cleaned up editorially. Sentence fragments, dangling prepositions, etc. give parts of the document an overly colloquial feel. The doc should talk about the limitations and benefits of evaluating content not sent over http(s). In addition to not having some of the http environment information, such content may be composed largely of scripts or templates that are hard to analyze with tools. However, a tool well integrated with a particular system could deliver more useful reports. Another challenge of trying to evaluate over http(s) is there could be a large number of relevant environment permutations that it is impractical to test comprehensively. While that problem is maybe referred to the evaluation methodology it should be acknowledged here. Some sections that refer to external resources should be fleshed out more. Although the external resource covers the topic, the point of this document is a one-stop shopping for this viewpoint of the issues, and the document should provide basic understandings and refer externally only for more details. The section on content encodings just says "pay attention to it", and doesn't even get into content language even though the heading implies it. The section on DOM seems to imply background knowledge and a parser / model builder that should be more explicit. Content negotiation can lead to many different but similar views, one of the gotchas of comprehensive evaluation. Session tracking support also can have big implications on how a tool plays with a site. Some examples are needed to help explain the difference between manual and semi-automatic evaluation and why there might be value in each. I'm having a hard time determining whether the document is meant to be descriptive or prescriptive - is it describing what eval tools are, as a background to another resource, or is it suggesting what eval tool developers should consider as they work on their tool? I think the doc has more value if it's prescriptive, so some things in it should be strengthened. |