WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: clarification please -> PDF/UA

for

From: Jonathan C Cohn
Date: Feb 26, 2015 4:46AM

PDF can and do contain scripts I have used an accessible form Pdf that computed totals and had dialog boxes warning of missing information.

And I have seen mentions of embedded flash within PDF though I have not directly experienced that to the best of my knowledge. But if there is embedded flash there is the possibility of embedded video. So perhaps these are not as out of scope as you propose.

> On Feb 26, 2015, at 02:39, Jon Metz < <EMAIL REMOVED> > wrote:
>
> 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
>>
>>
>>