WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A better PDF editor for accessibility?

for

From: Ryan E. Benson
Date: Jun 12, 2013 9:44PM

Jon said:
> 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)).

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.

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

In the government realm there is a whole different set of rules. The free
software that Olaf mentioned may be up to date with the PDF Standard better
than Acrobat, but it often fails in other critical areas. Such as, can the
company support a client that has 10k+ users, has it gone through the
various security checks, and does the software play nice with enterprise
management tools, such as SCCM? Often enough, the answers to one or more of
those questions is no. If that is the case, the product cannot be used. The
question can be flipped, why is Acrobat saying it is up to date, but still
runs on 10 year old stuff?

--
Ryan E. Benson


On Tue, Jun 11, 2013 at 1:49 PM, Duff Johnson < <EMAIL REMOVED> > wrote:

> > 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.
>
> Duff.
> > > >