WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: clarification please -> PDF/UA

for

From: Jon Metz
Date: Feb 26, 2015 12:39AM

Hi John,

One of the problems with relying on proprietary software to check for
accessibility is that the errors checked are based on to their opinions.
Current Section 508 means Acrobat or Microsoft only needed to follow
bare minimum rules, despite ISO 32000 as explained Tagged PDFs since 2008
(in the open).

Truthfully, PDFs have been treated like that special kid sitting in the
corner eating paste (ah, memories) for way too long. The less support that
was made available to it, the easier it was to hate and be regarded as a
troublemaker of all the other formats. Unfortunately, clients still used
them and have been posting garbage for while.

When clients started turning to WCAG for answers is probably when Acrobat
and MS Word started tying those rules into their automated checkers. Yet a
bunch of what WCAG recommends could easily be classified as out of scope
(scripting, captions, embedded media, etc.), so there hasn't really been
much change aside from cleaning up the UI a bit.

I'm probably a bit more paranoid than others in this field, but the fact
that the W3C gives "high marks" to software that is owned by two of it's
members isn't really all that surprising. I doubt I'm not the only one
raising an eyebrow that an organization that advocates against endorsing
software or using blatant superlatives uses screenshots of proprietary
software and publicly claims "On the Home ribbon, use the lists tools to
create or repair lists in Word documents. This is the easiest way to ensure
that lists are formatted correctly when they are converted to PDF.".

In fact, I suggested a couple years ago to modify the technique language to
reflect existing standards (
https://lists.w3.org/Archives/Public/public-comments-wcag20/2013Sep/0007.html).
Their response amounted to refusing to adhere to a specification based on
their opinion of value, adding that they were nice enough to include a copy
of the specs for further reading.

There will be people here who will tell you that PDF/UA (ISO 14289) is good
because it will force software developers to make more accessible PDFs,
essentially making less work for you. I'm confident that Adobe and
Microsoft are probably already working on something that will make these
bad rockets. However, I still believe there will be many people who just
hit 'Print' on their Macs and pass that off as an accessible document
continuing work for people like me, so it'll be important to know what to
do when it happens.

You're notion that PDF/UA is a "higher" standard is rather astute, but I
disagree that it's a bad thing. It means that if people will want to
continue to use a filetype they've been using, they're gonna need to start
making it accessible like everything else they put online. They can't
continue using the lame excuse that it sucks because it was underfunded and
came from a broken family (I'm looking at you, Flash...). The purpose is to
set out to make a standard.

And just an aside, you should know better than to rely on automated
testing! Tsk tsk.

— Jon


On Wed, Feb 25, 2015 at 3:27 PM, John E Brandt < <EMAIL REMOVED> > wrote:

> So, I was going to ask the group if the Accessibility Checker built into
> Adobe Acrobat Pro (AAP) would accurately assess a file for PDF/UA.
> According
> to the information Olaf provided from the PDF Association, the answer is no
> and that the only validator that does this kind of assessment is the PAC:
> PDF Accessibility Checker (v2.0). So I checked it out with document that
> was
> initially a VERY simple MS-Word documents (no tables, simple text, a few
> links and one in-line image) that had been converted using the SaveAs PDF
> utility. It passed the Accessibility Checker in MS Word (latest version)
> and
> essentially passed the accessibility checker in AAP - I had to manually add
> the Title even though it was there in the MS-Word version (I think this is
> a
> bug) and verify "manually" that the word order was correct and contrast
> ratio sufficient. But the PAC found a number of errors thus deeming the
> document NOT to be PDF/UA compliant. Interestingly, one of the "errors"
> noted by PAC was the fact that the PDF/UA identifier was missing!
>
> The WC3's document "PDF Techniques for WCAG 2.0"
> http://www.w3.org/WAI/GL/WCAG20-TECHS/pdf.html gives high marks to both
> MS-Word and AAP as the tools to use. Apparently the PDF/UA is a "higher" -
> and perhaps unattainable standard. Clearly I can't figure out a way to meet
> this standard with any of the tools I have.
>
> So, I guessing that this is bad news if Section 508 Refresh is going to
> require the ISO 32000-1 (PDF/UA-1) standard...
>
> ~j
>
> John E. Brandt
> jebswebs: accessible and universal web design,
> development and consultation
> <EMAIL REMOVED>
> 207-622-7937
> Augusta, Maine, USA
>
> @jebswebs
> www.jebswebs.com
>
>
>