WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A better PDF editor for accessibility?

for

From: Duff Johnson
Date: Jun 11, 2013 11:49AM

> As Duff pointed out, it’s intended for people who are using something that
> doesn’t understand tags. One could argue that this is necessary to conform
> to many provisions of Section 508 here in the US, such as 1194.21 (d), .22
> (d), .31 (a). Both the Veteran’s Administration (VA) and Health and Human
> Services (HHS) discuss these requirements in their PDF checklists (VA:
> 1194.31 (a.18), 1194.22 (d.21) and HHS: 1.0 (12) and 3.0 (22)).

AT software that can't understand tagged PDF has no access to tables, lists, headings, alt. text etc. in PDF files.

It's kind of like asking websites to deliver good results when read using a text editor.

> Further, one could argue that this has something to do with WCAG 2.0
> (1.3.2 Meaningful Sequence).

Yes… 1.3.2 clearly requires tagged PDF. The only (theoretical) exception would be a PDF that is SO simple (no images, artifacts, tables, headings, lists, languages, links, forms, cross-page content, etc, etc) that tags would be literally unnecessary. Kind of equivalent to an HTML page that consists of nothing at all besides text inside <P> tags.

> I don’t think that it’s an unnecessary step. While it seems logical to
> think that we’re pulling out our hair for “old tech”, a perfect example
> happened to me only a couple years ago. When I tried to make a subway map
> accessible, John Brandt from jebsweb was nice enough to point out that he
> wasn’t able to use the Reading Order to make any sense of it since he was
> using Preview. I don’t use Preview, but I think that it still can’t
> understand tags. That’s a pretty common tech that falls under this
> category.

So, what are you saying… that accessibility efforts must be directed towards the crappiest software in common use?

Why is it OK to take such precious resources and spend them on supporting unfortunately-designed, poor-performing, decade-old software instead of supporting the accessibility mechanism in PDF?

Users who require AT have to acquire AT. Either their AT supports "accessible PDF," or it does not. Coddling software that's not designed or fit for purpose has to end at some point.

Customers will, as ever, get what they *ask* for. If the message received by software producers is fuzzy because lots of people have learned to make-do with the PDF viewer equivalent of IE6 to read modern websites, that's not going to help drive bright, new, cool software.