- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Wed, 01 Apr 2009 20:25:45 +0200
- To: <w3c-wai-ig@w3.org>
Hi Matt, All, At 21:32 31/03/2009, Matt Morgan-May wrote: >(...) > >In any case, I have to say it alarms me that when someone like Roger reports >an intermittent error in a couple of PDF documents (and raises an admittedly >good question in the process), certain others, without hesitation and >without qualifying their statements, start saying PDF is inaccessible. Or >that it's not "accessibility supported," or whatever. I present to these >people the following facts: > >1. Adobe Reader works with Orca on Linux and Solaris. We have been working >with the Orca team for years to help provide accessibility support on free >(speech/beer) platforms. >2. Adobe Reader support in the open-source NVDA screen reader on Windows has >improved dramatically, and we anticipate that it will continue to improve. >3. Apple's Voiceover screen reader for OS X supports PDF content with the >built-in Preview application. > >So, let's do the math. PDF is an open format (ISO 32000=PDF 1.7) with free >readers that support free AT on Windows, OS X, Linux and Solaris. I'd say >that's pretty broadly "accessibility supported". The work that has been done to increase accessibility supported is great, and I welcome the support in software that is available free of charge. However, there is a nasty little detail that is often overlooked in discussions on accessibility-supported technologies: language. In order to be considered as accessibility supported, a technology (and I don't mean to pick on PDF; it applies generally) also needs to be "tested for interoperability with users' assistive technology in the human language(s) of the content" (cited from clause 1 in the definition of accessibility supported [AccSupDef]). For example, a Maltese user who does not know any foreign languages can only access content in Maltese and use software that is localised for Maltese. If there is no accessible user agent (including plugins) that is supported by AT that is available in Maltese (assuming that there are user agents available in Maltese), than Maltese policy makers would better not include that technology in their list of accessibility-supported technologies (if they were making one). So you can't decide which (uses of) technologies are accessibility-supported based on testing in a single language. The EU has 23 official languages (see [EULangs]). This does not mean that each browser or plugin needs to be available in each of these languages, but that there must be at least one accessible user agent for the most common web content technologies (at least one for HTML, at least one for PDF, ...) for WCAG 2.0 to work well in the EU. If we took PDF as an example, we would see that the Adobe Reader is available in all the official langauges of the EU except Irish and Maltese (see [ReaderVersions]), but there might be accessible PDF readers in Irish and Maltese provided by someone else than Adobe. We could do the same excercise for WAI-ARIA and (maybe later...) HTML 5, and come to conclusions that are similar but not exactly the same. >(...) >People can jump on one bug report and try to make it look like PDF is thus >inaccessible, but one swallow does not a summer make. (...) As has been pointed out previously in this thread, WCAG 2.0 talks about uses of technologies. Not every feature of a technology needs to accessibility supported, but features that are not accessibility supported must not get in the way of techniques that are accessibility supported. (Keyboard trap is one example.) "One swallow does not a summer make" also applies to languages: proving accessibility support for English content and user agents is not sufficient in order to claim accessibility support around the globe. [AccSupDef] <http://www.w3.org/TR/WCAG20/#accessibility-supporteddef> [EULangs] <http://europa.eu/abc/european_countries/languages/index_en.htm> [ReaderVersions] <http://get.adobe.com/reader/otherversions/> Best regards, Christophe Strobbe -- Christophe Strobbe K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on Document Architectures Kasteelpark Arenberg 10 bus 2442 B-3001 Leuven-Heverlee BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ --- Please don't invite me to LinkedIn, Facebook, Quechup or other "social networks". You may have agreed to their "privacy policy", but I haven't. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Wednesday, 1 April 2009 18:26:39 UTC