- From: Nils Ulltveit-Moe <nils@u-moe.no>
- Date: Sat, 16 Apr 2005 22:01:11 +0200
- To: public-wai-ert@w3.org, wp3_eiao@osys.grm.hia.no, wp5_eiao@osys.grm.hia.no
Hi, One use case for EARL, is to use it as an aid for better website production management. Managing websites is in some respects similar to maintaining software, only that the development process and change frequency is much higher. Because of this, it may be a barrier to achieve web accessibility, that good process tools for managing accessibility issues are not available on a broad basis. One possibility for better management of issues found during accessibility assessments, is to add EARL support to e.g. BugZilla, to be able to add and track bug reports for accessibility issues automatically. The idea seems good, but there are several questions that need to be addressed before such a solution can be made in practice. Like e.g. on what granularity do you file bugs? (page, web-site, WCAG checkpoint...) How would/should such a bug report be represented? (text page, annotated copy of original page or what.) How do you define severity of the bug? On the other hand, having good EARL support in BugZilla for accessibility issue management might be a selling point for tool vendors, and may be contributory for EARL adoption because BugZilla is widely used. It would also provide a summary of the bug reports in a standardised way, so that an accessibility aware management could compare the evolvement of the web site with other activities like software development, to get an overview over how the web site progresses, and if there are indicators of "accessibility rot" - e.g. bugs that never are corrected and addresset etc. What are your viewpoints on this? Mvh. -- Nils Ulltveit-Moe <nils@u-moe.no>
Received on Saturday, 16 April 2005 19:57:03 UTC