- From: Sham Mitra <sham.mitra@gmail.com>
- Date: Thu, 30 Jan 2014 20:36:42 +0000
- To: public-wai-evaltf@w3.org
- Cc: shadi@w3.org
- Message-ID: <CAPzMBabFicGo7=VBKJk7vHhOtaUxZHatXpPz5N3WFhwcqEufYQ@mail.gmail.com>
Dear team, Thanks for publishing these in-draft guidelines; it does give a good feel for an approach to testing accessibility. I began my research into web accessibility in 2003/2004 whilst an undergraduate at Durham University. I worked closely with the university's disability department, and employed the services of some of its members (inc. disabled users) to test a website I built to model my research. Below are my comments with respect to the published guidelines. 1. Greater intimacy with target audience STEP 2 discusses the target website; I feel this should also include a sample of the target audience. Websites are built with an audience in mind, and it is my view that a sample of that audience should be invited to test the product continuously. 2. Have text only Those with disabilities, particular visual impairments, care not for graphics or presentation. Testing should also include the option to completely switch off layout and images, and have content linear to improve navigation, e.g. if it's made a best practice to left-align all links and texts, then a user can move the cursors to the left of the page and as they move down the screen reader will pick up each link and paragraph. 3. Cross-browser compatibility Many corporations still run legacy versions of web browsers. Backwards compatibility with modern web technologies may impact meeting WCAG 2.0 guidelines. Additionally, cross-browser accessibility for a website can be problematic. Therefore, I do recommend testing guidelines include testing across multiple desktop/mobile browsers. In STEP 3, I would recommend testing the pages across multiple browsers. 4. Set minimum criteria The recommendation for 'AA' rating is a great baseline. I do feel through the evaluation process, there should be continuous feedback. In STEP 5, I do feel the report should identify 'recommendations for improvement' on which the developer/s can re-work the solution. Additionally, with my first point ('greater intimacy with target audience'), document if any disabled testers were used to evaluate the product - it does not need to include the disabled testers name, only there disability (and document observations through questionnaires post testing). In closing, I would like to support the W3C on it's work with accessibility. If I can support you, or your team in any way please do reach out. I'm a consultant within Accenture's Digital practice, having previously worked at IBM and advised on web accessibility to a large government account. One of my colleagues from IBM, Bill Curtis-Davidson, will I hope have a few good words to say about me. Many thanks, Sham
Received on Friday, 31 January 2014 08:37:48 UTC