- From: Joshue O Connor <joshue.oconnor@ncbi.ie>
- Date: Tue, 31 Mar 2009 11:31:53 +0100
- To: rhudson@usability.com.au
- Cc: w3c-wai-ig@w3.org
Roger Hudson wrote: > A highly experienced screen reader user and I recently reviewed a couple of > PDF forms for compliance with WCAG 2. [...] > The way these screen readers handled the forms threw up some interesting > issues or questions. > WCAG 2 contains "testable" Success Criteria, which are normative, and there > is a general belief that all testers will obtain the same or very similar > results for the different Criteria. However we found considerable > inconsistencies in the way some components of the forms behaved. For > example, sometimes a particular button or checkbox would be reported and > sometimes the same button/checkbox would be ignored. And often the status of > buttons/checkboxes would not be correctly reported. In cases of inconsistent > or unreliable performance what yardstick do you use to determine compliance? Thanks for bringing this up as I think there is a lot of confusion around this area, notwithstanding my own lol. Can you consider a technology accessibility supported that essentially doesn't /work/ in particular, (so we don't for the sake of illustration, have to factor in backwards compatibility) with newer assistive technology, even though it conforms to the letter of the law of a particular specification or standard? I would say no, that we cannot consider a platform or format like PDF to be truly accessibility supported if it won't /work/ consistently even in an ideal setting (newer version of AT, up to date OS, good graphics card, lots of RAM etc). It would be better to state that this support is a work in progress rather than confuse many who will buy into the platform/format in good faith that it will work and they are doing the right thing. Having said all that, I have some sympathy with the position of vendors trying to improve the accessibility of their application/platform. There could be /many/ reasons why there were inconsistencies in your tests, for example problems with the AT and the graphics card on the users machine could be causing focus issues (come across this lots) or interfering with access to the contents of the PDF or sometimes the Flash API. The use of newer graphical themes can even interfere with screen reader output. If these variables could be taken out of the equation you could get different results. > When it comes to determining Accessibility Supported technologies, who or > how do we decide which version of a technology should we use as the > reference point? [...] > And, what happens when there are competing determinations about which > technologies and technology versions should be deemed supported? This could > be within a jurisdiction and across jurisdictions. These points are best addressed by ensuring that a truly accessible alternative is provided, for example a HTML version of the PDF or a structured MS Word doc. This is not what vendors want to hear as they want you to use /their/ platform. However, producing this kind of content is less problematic and easier for many non technical people these days - with a little know how - and ensures that those who can successfully use the PDF with AT can do so and those who cannot have an alternative they can work with. Cheers Josh ******************************************************************** NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. NCBI endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent the views of NCBI ********************************************************************
Received on Tuesday, 31 March 2009 10:32:50 UTC