- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Mon, 31 Jan 2005 09:10:52 -0500
- To: <w3c-wai-eo@w3.org>
- Message-ID: <007f01c5079e$ac33cbb0$a201a8c0@deque.local>
Judy / Shadi and all, 2. Focus should be Evaluation Process : The doc should recognize that there are two distinct processes: the development process and evaluation process, though in practice the tasks may be intertwined. The eval tasks are part of the quality assurance process. Every individual developer or content writer subjects his/her work to accessibility self-examination (which might include other quality checks) before declaring the work to be complete. In small orgs. there may be no other QA process. But these are essentially two separate tasks. Here the developer plays a dual role: as content author and as evaluator. In larger orgs. the content may be subjected to a QA process through another group / department. The focus of this doc again is eval tools being used primarily during eval process. They help developers but that is a secondary benefit. The focus here should be "want to help <del>developers</del> <ins>accessibility evaluators</ins> find appropriate tools to assist the manual evaluations they have to carry out" Shadi writes: "Of course, all these are just interim solutions while authoring tools slowly increase their support for accessibility by providing in-line automated checking and filters to better assist the Web developers..." Sailesh: Likewise , when authoring tools incorporate accessibility checks, the authoring process is intertwined with the eval process. The authoring tool plays a dual role: authoring tool and eval tool. Developers may use an authoring tool but will an individual in the QA and accessibility eval department depend on an authoring tool? He would just like to use a tool that checks for accessibility. And are you suggesting that as authoring tools incorporate accessibility checking, there will be no need for stand alone eval tools? Again please make the eval process the focus of this doc and not the development process. This doc is more closely related to Techniques for accessibility eval and repair and not techniques for WCAG. If the subject is tools for creating accessible Web content, thenit is a different matter. Sailesh Panchang Senior Accessibility Engineer Deque Systems,11180 Sunrise Valley Drive, 4th Floor, Reston VA 20191 Tel: 703-225-0380 Extension 105 E-mail: sailesh.panchang@deque.com Fax: 703-225-0387 * Look up <http://www.deque.com> *
Received on Monday, 31 January 2005 14:14:55 UTC