PDF documents and accessibility support

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

Received on Monday, 17 December 2012 23:48:42 UTC