WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A better PDF editor for accessibility?

for

From: Duff Johnson
Date: Jun 13, 2013 10:34AM

>> While I can only speak about HHS' checklist (
>> http://www.hhs.gov/web/508/accessiblefiles/checklistpdf.html), I would
>> say we go beyond the the basics, unless i am missing your point.

I looked at these "guidelines" again. I feel these have changed since I last checked them.

Please tell me where you see requirements specific to content reading order (as opposed to tags).

- Item 3.3 specifies tags
- Item 3.5 can readily be interpreted to be about tags (it even mentions tables!)

> Yes, that actually was my point. The problem is, as Olaf and Duff point
> out, forcing some sort of structure that can be understood by software
> that can¹t understand tagged PDF misses the point of creating something
> specifically for Assistive Technology.

Not only does it miss the point - it's actively counter-productive, because the time taken to fix a PDF so that it "works" for technology that doesn't understand tags is *exactly* the same time that could otherwise be used to make more PDF files accessible, cut the cost of remediation, or whatever.

> It¹s one thing to go above and beyond like one would with WCAG 2.0 AAA,
> but government requirements don¹t let contractors do that.

In my years of selling accessible PDF services to Federal government agencies and contractors I can attest that I only lost this "customer education" argument twice.

In other words, almost every time I took to time to explain the realities to my client - especially the part about how insisting that the PDF be readable when "reflowed" on random cell-phones - can dramatically reduce the number of files that can be handled in the existing budget - I won the argument.

> And that is my
> point overall. While I agree that using the RO is a horrible idea, there¹s
> nothing I can do about it

Educate the customer.

Customers aren't that dumb. If they can understand why old browsers can't handle a modern website they can usually understand that X, Y or Z software doesn't (yet) support accessible PDF.

…especially if the applicable regulations don't actually require content reading order adjustments!

> , and Duff and Olaf recommending to people that
> they don¹t use it because it isn¹t necessary for AT is the same as telling
> people to ignore their client¹s requests.

See above. I've sold PDF accessibility services since 2001. I have almost always won this argument (2 exceptions). We were always paid (no exceptions) for our work.

Now… if someone demanded that the PDF file work with technology that doesn't support accessible PDF; that's OK - we'd do that. I think at DSI we called it "Phone-optimized PDF" or some such. It was more expensive (of course), and much less popular. Plus, we would (often, not always) require the customer to acknowledge that they were requesting features beyond those required to enable accessibility.

> What I¹d rather is a happy medium, or this:
>
>> The question can be flipped, why is Acrobat saying it is up to date, but
>> still runs on 10 year old stuff?
>
> ^^ +1!

Ahhh.

Now, that's a good question.

The answer is: they (Adobe) don't hear (enough) from customers about what a bummer it is that Reflow doesn't use tags.

Apparently there are lots of customers who are grateful for this 10 year old software... and don't know what they could have… so they never ask.

You, however, do know what you could have.

- Ask for better: contact Adobe and tell them how you feel the product should change.
- Educate the customer about the realities (so they know what to ask for as well).

Adobe, like other software developers, pays attention to what their customers say, but also to what their customers do *not* say.

Duff.