Frequently Asked Questions

Why Use CommonLook PDF (formerly PDF GlobalAccess)?

It’s faster

CommonLook PDF increases the speed of testing and remediation of PDF documents by 8 to 20 times (depending on document complexity) as compared to “manual” testing using screen readers and Acrobat’s tags tree. Labor costs are the most significant component in achieving compliance with accessibility standards; the investment in CommonLook PDFis typically recovered within 3-5 days of production usage. Those working with documents containing complex tables, forms, lists and tables of content will get the highest value out of CommonLook.

The tagging is of higher quality

The quality of documents corrected with CommonLook PDF is significantly higher than “manual” testing for two reasons. First, because the internal structure of such documents is thoroughly examined and corrected. Secondly, because CommonLook makes it possible to test each document for Section 508 compliance comprehensively and methodically, with CommonLook Reports providing detailed evidence of verification.

It is more methodical

Using CommonLook PDF, you can verify compliance with a specific standard by methodically addressing instances of non-compliance and verifying all items that require user intervention.

It is more comprehensive

CommonLook PDF supports verification and remediation for a variety of accessibility standards including WCAG 2.0, PDF/UA, HHS and more.

Why can’t the Acrobat Accessibility Checker test for compliance with Section 508 or WCAG 2.0 AA?

As Adobe Systems themselves point out in the “Disclaimer” they provide, the Acrobat Accessibility and Section 508 Checkers do not check effectively for most of the Section 508 checkpoints. In other cases, the “checking” is incomplete. For example, Acrobat’s checker can verify alternative text exists, but it does not provide a way for a user to verify the text.

What constitutes Section 508 or WCAG 2.0 AA compliance for a PDF document on the internet/intranet?

Under current regulations, PDF documents must comply with the checkpoints specified in § 1194.22 (Web-based Intranet and Internet Information and Applications).

(a) Text Tags
(b) Multimedia Presentations
(c) Color
(d) Readability
(e) Serve-Side Image Maps
(f) Client-Side Image Maps (not applicable to PDF)
(g)&(h) Data Table
(i) Frames (not applicable to PDF)
(j) Flicker Rate
(k) Text-Only Alternative
(l) Scripts
(m) Applets and Plug-Ins
(n) Electronic Forms
(o) Navigation Links
(p) Time Delays

Why is it harder to make PDF documents accessible than HTML?

HTML is simply plain text. It’s explicit, and prior to CSS, occurs in natural reading order.

By contrast, PDF files are self-contained vessels for text, fonts, graphics, bookmarks, links and many other types of objects. As a result, PDF is internally far more complex than HTML. When documents are converted to PDF, it is not uncommon for key information to be missing, and for the file to be structured in a way that makes accessibility difficult.

CommonLook PDF greatly simplifies the process of making PDF documents structurally consistent, checking for compliance with Section 508 checkpoints and remediating compliance problems.

Is it possible to fully automate the testing for Section 508 or WCAG 2.0 AA?

It is not possible; some checkpoints require a user to verify correct content or structure. For example, a text equivalent for a non-textual object should be verified by a tester to ensure it correctly describes the non-textual object. Also, the correct order of a document’s elements should typically be verified by a user, as the tagging process in Acrobat frequently results in missing key structural information (e.g. table headers) or incorrectly identifying or misordering the elements in the tags view. The result of such errors causes a “paragraph (d) violation” because assistive technology such as screen readers will fail to read the text in the correct order.

Can CommonLook PDF perform fully automated tests?

CommonLook PDF GlobalAccess has been automated to the maximum possible extent. However, user judgment is required (but is greatly aided) in a number of checkpoints.

Organizations interested in an automated assessment of the state of Section 508 compliance of their PDF holdings may want to consider CommonLook Clarity, which can spider through internet and intranet sites and perform bulk unattended verification of PDF documents.

Does CommonLook PDF perform OCR?

CommonLook PDF is designed to verify and remediate tagged PDF files. Scanned pages aren’t ready to be tagged until they are OCRed. Before using CommonLook PDF to remediate your scanned PDF files, be sure the file has been OCRed, any OCR errors have been corrected, and the file has been tagged in Adobe Acrobat Professional or a similar application.

Can CommonLook PDF run on a Mac?

CommonLook PDF does not run directly on a Mac. Many of our Mac customers utilize tools such as Parallels to run Windows 10 on the Mac and then run CommonLook PDF within that environment.

What position does the Australian government take on PDF Accessibility on mobile devices?

Background:

As a result of PDF accessibility issues reported by some users of mobile devices, the Australian Government states that HTML should be “the default format for all government information” (See https://guides.service.gov.au/content-guide/accessibility-inclusivity/#pdf-accessibility) with PDF being a secondary source of the information, where required.  However, the Australian Government recognizes that “Sometimes it may not be appropriate to publish in HTML, for example some types of specialist reports. If you don’t publish an HTML version, be sure to publish an HTML summary on a landing page — and provide contact details for users who are unable to access the PDF.” (See https://guides.service.gov.au/content-guide/types-of-content/)

It should be noted that the issues with PDF accessibility on mobile devices are not related to the PDF format itself, which can be made fully accessible, if tagged properly and verified with tools such as CommonLook PDF (CommonLook PDF is recognized by W3C as a tool for Accessibility Checking and Repair. See  https://www.w3.org/TR/WCAG-TECHS/pdf.html.) Standards such as WCAG 2.0 and PDF/UA specify what needs to be done in order for a PDF document to meet accessibility requirements independent of how the PDF document is read.

The issues with mobile devices are typically related to PDF files not being made accessible in the first place or to the Adobe Acrobat reader running on these devices. Adobe has been steadily improving the Acrobat reader on Android and IOS (See https://blogs.adobe.com/accessibility/2017/06/reading-accessible-pdfs-on-ios-and-android.html)

Should I publish in accessible PDF or HTML?

While keeping in mind that the Australian Government states that HTML should be the default format for all government information, there are clearly many reasons why it is appropriate to publish information in the PDF format which is widely recognized as the most ubiquitous electronic document format. However, where PDF is the most appropriate format, you must make sure the PDF document is properly tagged and compliant with WCAG 2.0 or PDF/UA. Make sure you follow the guidance of the Australian Government for non-HTML content which states “Sometimes it may not be appropriate to publish in HTML, for example some types of specialist reports. If you don’t publish an HTML version, be sure to publish an HTML summary on a landing page — and provide contact details for users who are unable to access the PDF.” (See https://guides.service.gov.au/content-guide/types-of-content/ )

  Request a Trial