E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Liko, Todd
Date: Thu, Mar 13 2014 6:13AM
Subject: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
No previous message | Next message →

Hello all.

I use both tools to assess a PDF document for accessibility. Both tools provide reports and are more often than not, quite different from each other. For example, PAC always flags borders, table borders, etc... as untagged content, whereas, Acrobat full check does not. Adobe full check always flags table irregularity even when colspan or rowspan are properly set.

Neither tool flags if the <Reference> tag is properly used for links referencing content within the document, but that makes sense as the automated check cannot determine if the link in internal or external. I always add it because it is part of the ISO Standard.

I also realize the PAC tool assesses against the Matterhorn Protocol which is not required under WCAG 2.0, therefore returns many errors that probably can be overlooked. I prefer to address the errors, however, in order to be proactive.

I guess my question is should I care that the table borders are untagged, that the <Reference> tag or <Label> tag is not being used? Obviously addressing all of these items requires more effort and time and I am getting some pushback/questions as to why it takes so my time to make a PDF document accessible.

There are also suggestions that we simply convert all PDF documents to HTML 5, in order to meet the Standard on Mobile Devices.

Any thoughts or feedback would be much appreciated.

_______
Todd Liko
Communications Advisor | Conseiller en communications
Web Services | Services Web
Communications and Marketing | Communications et Marketing
427 Avenue Laurier Avenue West (AEAD), Ottawa ON K1A 0N5
427 Avenue Laurier Ouest (AEAD), Ottawa (Ontario) K1A 0N5
e-mail / courriel: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
telephone / téléphone: (613) 949-9425 | fax / télécopieur: (613) 949-2386
Government of Canada | Gouvernement du Canada

From: Lucy Greco
Date: Thu, Mar 13 2014 9:59AM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
← Previous message | Next message →

I say go the html way. Really it's a better format to read and in the end
easier for all

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
follow me on twitter @accessaces

From: Liko, Todd
Date: Fri, Mar 14 2014 5:00AM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
← Previous message | Next message →

Thank you for your response Lucia.

While I agree with you, the reason we are creating accessible PDFs is because that is how the targeted audience for these documents consume these documents. We prefer not to create HTML version just to be able to post the non-accessible PDF version.

Todd.

From: Trafford, Logan
Date: Fri, Mar 14 2014 5:58AM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
← Previous message | Next message →

Hey Todd.

Just letting you know, we've invested significantly in the CommonLook PDF product to help ensure PDF accessibility. While it currently only checks against 508, the new release coming within a couple of months will be checking against WCAG and PDF U/A as well. There's less of a learning curve for staff, as opposed to trying to figure out the meaning of some of the "errors" that come up from both Acrobat and/or PAC. In my opinion, it makes the remediation process simpler for those who don't fully understand WCAG or other standards.

Logan Trafford
Intermediate Web Developer (WCAG Compliance)
City of Ottawa (Canada)
From: = EMAIL ADDRESS REMOVED = [ = EMAIL ADDRESS REMOVED = ] on behalf of Liko, Todd [ = EMAIL ADDRESS REMOVED = ]
Sent: Friday, March 14, 2014 7:00 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check

Thank you for your response Lucia.

While I agree with you, the reason we are creating accessible PDFs is because that is how the targeted audience for these documents consume these documents. We prefer not to create HTML version just to be able to post the non-accessible PDF version.

Todd.

From: Liko, Todd
Date: Fri, Mar 14 2014 6:12AM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
← Previous message | Next message →

Hello Logan.

Thank you for the information. I am very well versed with WCAG and the other standards, although not all staff are.

We did purchase a copy of CommonLook PDF over a year ago. Many of our developers found the learning curve significant. However, we just ordered 4 more licenses to assist us with the remediation of PDF documents.

Would you be willing to talk offline about the CommonLook Product? I have left my email below.

Todd.
= EMAIL ADDRESS REMOVED =

From: Monir ElRayes
Date: Thu, Apr 03 2014 11:54AM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
← Previous message | Next message →

I think it is important to realize that PDF is here to stay for a variety of
reasons, not the least of which the fact that PDF typically represents a
"document" as opposed to an html "page" which usually represents an
information fragment.

In any case, using the right tools, PDF can easily be made as accessible as
HTML. Accessibility technology should accommodate all popular formats as
long as these formats are inherently capable of being accessible.

Best Regards,
Monir ElRayes
Founder / Director
NetCentric Technologies 
Creator of the CommonLook Suite of Tools
Email : = EMAIL ADDRESS REMOVED =
www.commonlook.com
Please consider the environment before printing this e-mail

From: Lynn Wehrman
Date: Thu, Apr 03 2014 12:05PM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat ProXI full check
← Previous message | Next message →

From the standpoint of our testers who live with sight-related disabilities, we're finding that properly structured PDF's don't create significant accessibility issues anymore. There used to be a time when the technology that most nonvisual users could afford wasn't keeping up with PDFs, even those that were structured for access, but that is changing as more affordable technology, and savvier users emerge.

The neat trick for the future is going to be getting PDF's structured for access but the tech you're discussing on this thread is part of making that a viable reality.

From: Chagnon | PubCom
Date: Thu, Apr 03 2014 12:38PM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe AcrobatProXI full check
← Previous message | Next message →

Chiming in with agreement with Monir ElRayes and Lucia Greco re:
accessibility of PDFs.

They can be just as accessible as any other form of information, but the key
is having users trained in how to make accessible Word documents, InDesign
layout files, and PDFs. And, of course, having the right software tools to
do this.

PDFs are central for any organization or enterprise, so they are not going
to go away or be replaced by HTML websites. They have a defined purpose of
"locking down" a document in a particular state at a particular point in
time. A snapshot, so to speak. That's nearly impossible to do with a
webpage, which in theory is a living document.

Todd, re: your findings that different AT report or voice items differently
could be due to two factors:

1) The version of the software that created the source document. Example,
Word 2013 does a better job of converting to accessible tags that Word 2017,
and InDesign CC does a better job than InDesign CS 5.5. Each new version of
these programs incorporates newer standards and more accurate tags.

2) The version of the Acrobat conversation engine/module used to create the
PDF from the source document. Acrobat XI does a better job than Acrobat X
and we're hoping that the future Acrobat XII does an even better job.

So many variables affect how accessible a document will be:
- The software that creates the source document; for example, Word is better
than WordPerfect.
- The version of that software; newer is usually better.
- The PDF conversion engine; newer versions are better.
- How well the document's author understands accessibility and how to create
an accessible document.
- Knowledge of and tools used by those who remediate the PDFs.
- The AT used by the end user; newer versions are better.
- How well the AT user can control or customize their AT for their needs.

That's a lot of variables!

-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2014 - www.Workshop.Pubcom.com

From: John E Brandt
Date: Thu, Apr 03 2014 2:25PM
Subject: Re: PDF Accessibility Checker (PAC) vs. AdobeAcrobatProXI full check
← Previous message | Next message →

Ditto to all the above...but the most important statement is this one made
by Bevi.

It almost ALWAYS comes down to...

***How well the document's author understands accessibility and how to
create an accessible document***

PDF's are not to blame...the people who create them are. And this means we
need to train people to do a better job of creating digital documents.

~j

John E. Brandt
jebswebs: accessible and universal web design,
development and consultation
= EMAIL ADDRESS REMOVED =
207-622-7937
Augusta, Maine, USA

@jebswebs

From: Clark, Michelle - NRCS, Washington, DC
Date: Thu, Apr 03 2014 2:28PM
Subject: Re: PDF Accessibility Checker (PAC) vs.AdobeAcrobatProXI full check
← Previous message | Next message →

As I learned and say all too often but it is the truth; "Do it right the first time".

Michelle

From: Chagnon | PubCom
Date: Thu, Apr 03 2014 2:55PM
Subject: Re: PDF Accessibility Checker (PAC)vs.AdobeAcrobatProXI full check
← Previous message | Next message →

And now we just have to get this message across to all the HR departments,
managers, and publishers in the corporate, government, and academic
communities...Whew! <g>
-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2014 - www.Workshop.Pubcom.com

From: Ryan E. Benson
Date: Thu, Apr 03 2014 3:23PM
Subject: Re: PDF Accessibility Checker (PAC) vs. Adobe Acrobat Pro XI full check
← Previous message | No next message

Todd,

>For example, PAC always flags borders, table borders, etc... as untagged
content, whereas, Acrobat full check does not.

I don't use PAC, so I don't know the error it throws. I would open up the
content panel, find the borders - usually Paths. If they are within an
<Artifact>, I'd ignore the error and move on. If not, create an Artifact.

>Neither tool flags if the <Reference> tag is properly used for links
referencing content within the document,

This is a flaw of most automatic checkers, <Reference> can be used in a
number of ways, so it is hard to code something that checks for such
accurately. If you're on LinkedIn, the following thread may be a good read:
http://is.gd/nRBpOL

Re <label> not being used: The label tag can do a number of things, so
where it isn't being used, may cause an issue.

--
Ryan E. Benson


On Thu, Mar 13, 2014 at 8:13 AM, Liko, Todd < = EMAIL ADDRESS REMOVED = > wrote:

> Hello all.
>
> I use both tools to assess a PDF document for accessibility. Both tools
> provide reports and are more often than not, quite different from each
> other. For example, PAC always flags borders, table borders, etc... as
> untagged content, whereas, Acrobat full check does not. Adobe full check
> always flags table irregularity even when colspan or rowspan are properly
> set.
>
> Neither tool flags if the <Reference> tag is properly used for links
> referencing content within the document,but that makes sense as the
> automated check cannot determine if the link in internal or external. I
> always add it because it is part of the ISO Standard.
>
> I also realize the PAC tool assesses against the Matterhorn Protocol which
> is not required under WCAG 2.0, therefore returns many errors that probably
> can be overlooked. I prefer to address the errors, however, in order to be
> proactive.
>
> I guess my question is should I care that the table borders are untagged,
> that the <Reference> tag or <Label> tag is not being used? Obviously
> addressing all of these items requires more effort and time and I am
> getting some pushback/questions as to why it takes so my time to make a PDF
> document accessible.
>
> There are also suggestions that we simply convert all PDF documents to
> HTML 5, in order to meet the Standard on Mobile Devices.
>
> Any thoughts or feedback would be much appreciated.
>
> _______
> Todd Liko
> Communications Advisor | Conseiller en communications
> Web Services | Services Web
> Communications and Marketing | Communications et Marketing
> 427 Avenue Laurier Avenue West (AEAD), Ottawa ON K1A 0N5
> 427 Avenue Laurier Ouest (AEAD), Ottawa (Ontario) K1A 0N5
> e-mail / courriel: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> telephone / téléphone: (613) 949-9425 | fax / télécopieur: (613) 949-2386
> Government of Canada | Gouvernement du Canada
>
> > > >