WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A better PDF editor for accessibility?

for

From: Jonathan Metz
Date: Jun 13, 2013 7:29AM

"Ryan E. Benson" < <EMAIL REMOVED> > wrote:


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

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.

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

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!


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