Re: PDF documents and accessibility support

Most interesting thread.
Question?
Is it possible to suggest the use of a third party platform in the same way 
the three pdf programs are apparently used?
For example, there is a service.

www.robobraille.org

That can convert pdf documents into a variety of things. audio, braille, 
rtf and the like.
I have no idea what google uses to allow the viewing of *some* pdf 
documents in HTML, at least if one is accessing gmail in a low graphics 
browser, but this can work, in some cases.
None of this, i suspect? would speak to the importation situation of 
forms links and the like.
Although I have been able to access the links in pdf files converted to 
say rtf than HTML via Linux tools with Robobraille starting the process.

I encountered the forms  problem  when attempting to use the state of New 
York's overseas voter registration pdf structure, which has its mirror at 
the federal level too via the federal voter assistance program.
My question is, <yes there is one> if some of the convert tools offered 
via robobraille might  translate into user agent options to help address 
this issue?
Or can the use of the service aid, even slightly?
Karen

On Tue, 18 Dec 2012, Ramón Corominas wrote:

> Dear all,
>
> Since Shawn has kindly reminded it, I open a new thread about "PDF 
> accessibility support", which is IMO a completely different case from that of 
> JavaScript.
>
>
> Andrew Kirkpatrick wrote:
>
>>  On the Mac and iOS preview provides access to PDF documents, albeit in
>>  a more limited way than you get with Adobe Reader on Windows. For Linux
>>  Adobe Reader has provided support but it was never as complete as on
>>  Windows and has taken some steps backward since the main support work
>>  was done. In all versions, users are able to save the PDF content to
>>  a text file, which doesn't qualify as anywhere near full support, but
>>  does help some users.
>
> Preview on MacOS/iOS has no support for alternate texts for images. It does 
> not support bookarks. It does not support tagged PDFs, and therefore it does 
> not support headings, lists, tables or any other semantics. It does not 
> support forms. It does not support links... I must admit that I don't know 
> myself if Adobe Reader on Linux supports any of those features, but I've been 
> told by blind Linux users that it doesn't.
>
> I sincerely doubt that any of the 23 techniques listed in the "PDF Techniques 
> for WCAG 2.0" document are any useful on Mac or Linux platforms. Indeed, only 
> three user agents that support accessibility features are listed in that 
> document: Adobe Acrobat Pro, Adobe Reader and Kurzwell 3000 (TM). The three 
> run only on Windows, and two of them are not free.
>
> According to the WCAG 2.0 definition, the second condition that must be met 
> for "accessibility support" states:
>
> "2. The Web content technology must have accessibility-supported user agents 
> that are available to users."
>
> With four different possibilities:
>
> a) Native support in widely-distributed user agents.
>
> FAIL: There are no user agents for Mac/Linux that natively support PDF 
> accessibility features other than plain-text reading.
>
> b) Suupport through a widely-distributed plugin.
>
> FAIL: no plugin is available on Mac to read PDF documents in an accessible 
> way.
>
> c) Content is available in a closed environment.
>
> PASS: but only if the website is not publicly available and that environment 
> is based on Windows.
>
> d) Accessibility-supported UA for download/purchase.
>
> FAIL (for now): maybe in the future the "Callas pdfGoHTML" suggested by Olaf 
> can meet this. Only if the tool is accessible AND it is available for 
> download free of charge AND the download process is also accessible. Even in 
> that case I'm not sure that "it is as easy to find and obtain for a person 
> with a disability as it is for a person without disabilities"; remember that 
> non-disabled users can read PDF documents using preview without any extra 
> effort, but I'm open to consider this as a valid solution.
>
> Please note that, as opposed to the JavaScript case, the PDF-compatible user 
> agents that exist on MacOS or Linux can be used by people without 
> disabilities, but not by users with disabilities (and blind users in 
> particular). PwD will not be able to read PDF documents in an accessible way 
> unless they use Windows.
>
>
>>  Another good point here is that accessibility supported is not applied
>>  like a warm (or wet) blanket on an entire technology.  Accessibility
>>  supported applies to _features_ of technologies.  You can have a
>>  technology that is regarded as highly accessible, but may not have
>>  sufficient support for some new features.  For example, should we
>>  regard the longdesc attribute as accessibility supported?
>
> That's true! However, since none of the accessibility features are supported 
> on MacOS or Linux (no tagged PDFs), then PDF documents are only as accessible 
> as plain text documents. This means that they will rarely meet all WCAG 2.0 
> success criteria, including (but probably not limited to):
>
> 1.1.1 Non-text content (level A): you cannot provide alternate texts for 
> images unless you write the text in the body of the document. You cannot 
> "hide" decorative images. Any PDF that includes images would not be 
> accessibility supported unless you only consider a Windows closed 
> environment.
>
> 1.3.1 Info and relationships (level A): no semantics, so only plain text PDFs 
> with no structure would comply. No headings. No lists. No tables. No links. 
> No forms. Only plain text can meet this SC in a publicly available website.
>
> 4.1.2 Name, role, value (level A): unless the PDF consists of plain text (and 
> even in that case), there is no way to convey the role of the different 
> elements. Of course forms or any other interactive components such as links 
> would fail this success criterion in publicly available websites.
>
>
>> >  [RC] most accessibility features of HTML are well supported on
>> >  Windows, MacOS  nd Linux, and also on iOS (maybe Android is not so 
> good).
>
>>  [AWK] If you're saying that "most accessibility features" then you might
>>  be agreeing with me.  If you can say "all accessibility features are
>>  well supported" on the platforms you name then we disagree on this 
> point.
>
> I think we agree on that. Not "all accessibility features" are supported, 
> only "most of them", or even "many of them". For PDF, today, the reality is 
> that only "plain-text access" is supported. Yes, they might exist text-only 
> PDF documents that meet WCAG 2.0, but it will not be the case for more common 
> PDF documents.
>
>
> In any case, I want to make clear that I am not trying to start a flame 
> against the PDF format itself, just pointing out that -most of- its 
> accessibility features are not "accessibility supported" according to the 
> WCAG 2.0 definition, and therefore they will cause accessibility barriers to 
> many users. I am optimistic and I hope that they will be supported in the 
> near future (maybe the adoption of PDF/UA as an ISO standard will help). But, 
> for now, -most- PDF documents cannot meet WCAG 2.0 if they are publicly 
> available.
>
> Of course, it is not a failure of the PDF format, since it has appropriate 
> accessibility features. It is the lack of support what makes it inaccessible. 
> Thus, PDF documents are, in my opinion, a perfect candidate for a "Statement 
> of Partial Conformance" due to language (even if the problem applies to any 
> language):
>
> "the page does not conform, but would conform if accessibility support 
> existed for (all of) the language(s) used on the page."
>
> But "partial conformance" does not mean "conformance".
>
>
> Of course, I would like to read your thoughts about this (smile)
>
> Regards,
> Ramón.
> 
> -- 
> Ramón Corominas
> Accessibility specialist
> Technosite - Fundación ONCE
> E: rcorominas@technosite.es
> T: @ramoncorominas
> P: +34 91 121 0330
> W: http://technosite.es
>
>
>
>