Posts in Category "PDF"

June 14, 2017

Updates on PDF Accessibility from Document Cloud

Interested in PDF accessibility? Rob Haverty, Senior Product Manager for Document Cloud Accessibility, writes about recently released updates for accessibility in Acrobat DC on the Document Cloud team blog, including tag panel improvements, improving the Create PDF feature in Word on the Mac to create well-tagged PDFs, adding a Preflight tool to check against the PDF/UA standard (ISO 14289-1:2014), and more.

For additional details, check out the blog post: Adobe Continues to Improve on Making PDFs Accessible.

2:47 PM Comments (0) Permalink
April 7, 2015

Adobe Acrobat DC and Acrobat Reader DC documentation

As promised, Adobe Acrobat DC and Acrobat Reader DC were released today. If you’re an Adobe Creative Cloud subscriber, you will find Acrobat Pro DC among the apps available to install.

If you’re interested in accessibility documentation on the DC releases, we’ve got you covered. The Adobe Acrobat accessibility site has loads of new documentation on Acrobat DC, including a step-by-step guide on adding accessibility support to PDF documents, and new VPAT documents. We’re also updating our guide to Acrobat Reader for users of screen readers, including information on our new support for VoiceOver, and will let you know when that is available.

We would like to pass along one note of caution: Acrobat DC will replace your installed copy of Acrobat XI. If you need to revert to the older version for any reason, you can uninstall Acrobat DC, then reinstall Acrobat XI by going to the Acrobat downloads page. Creative Cloud subscribers will still be able to activate the Acrobat XI installer by logging into their account.

11:59 AM Permalink
March 24, 2015

Acrobat DC and Reader DC accessibility update

Last week, Adobe announced the upcoming release of Adobe Acrobat DC and Adobe Reader DC. We have a few big new accessibility features that we want to let you know about in advance.

First, the upcoming release of Adobe Acrobat and Adobe Reader will contain support for reading tagged PDF content with assistive technology on both Windows and Mac OS X. For the first time, Mac users will be able to use VoiceOver to create, edit and read accessible PDF documents.

The new user interface in Acrobat and Reader is also improved, and includes features that will help both readers and producers of PDF content. The whole UI now responds to high-contrast modes, with new icons customized for light or dark backgrounds.

A view of Acrobat DC in high-contrast mode, with files listed in white text on a black background

The Tools panel in Acrobat DC, shown in high-contrast mode with colored icons on a black background

Accessibility authoring features in Acrobat are now organized in the Accessibility Tool, which is more configurable than in earlier versions. And you can still find the Make Accessible Action in the Actions Tool, along with a number of components you can use to test and automate the production of accessible PDF documents.

Acrobat and Reader DC will be available within the next 30 days. If you are an Adobe Creative Cloud subscriber, you’ll find the new version of Acrobat in the Creative Cloud app for you to download on the day it ships.

We’re working on lots of accessibility documentation for users and authors, and will keep you up to date as we go.

6:12 PM Permalink
September 23, 2014

PDF accessibility starts with the author

PDF accessibility is a popular topic around here. We believe access to the universe of PDF documents out in the world is critically important to users with disabilities, and we try where we can to help authors make PDFs as accessibly as possible using Adobe Acrobat and other products we make.

Freedom Scientific recently announced a beta version of their flagship screen reader, JAWS 16. In that release, their Convenient OCR (optical character recognition) feature has been expanded to help take inaccessible PDF documents (for example, paper documents taken directly from a scanner) and make them readable to screen-reader users. In light of this news, we want to caution creators of PDF content regarding what this new feature means for PDF accessibility.

Authors frequently ask us to automate this process for the thousands, millions or billions of documents they’ve already produced, and while tools do exist to do this, there’s no guarantee that they can be 100% effective at what they do. Likewise, tools like Convenient OCR, made for readers to access previously inaccessible content, all have their own limitations.

None of these tools is a silver bullet. Neither automated authoring tools nor assistive technology for readers is intended to relieve creators of PDF content from their responsibility to make that content accessible.

The PDF format, along with tools which implement the PDF/UA specification, have many features intended to enable a final PDF document that works for users on the devices they choose, with the software they choose, and with the accessibility features they prefer. No matter what technology may come along, authors know more about the structure and content of the document than any algorithm can.

The Convenient OCR feature is what’s known in accessibility as a repair technique. As with most other things, when you have to repair something, it means you’re starting with an item that is broken. This is true of inaccessible PDF documents: for example, when a page is scanned into a PDF without being properly tagged, readers miss both the textual content and the document structure that sighted users take for granted. When a tool tries to repair that document, it can only guess at the original text (and we know first-hand that OCR still isn’t 100% effective) and what kind of structure was intended.

Authors alone have the ability to communicate exactly what they mean, in a way that can be read by people with perfect vision, or who use a screen reader, or who use magnification software and/or features like high-contrast mode to adapt to their individual needs.

None of this is intended to take away from the work that Freedom Scientific is doing. Repair techniques are invaluable tools, and features like OCR have been used to work around inaccessible text since the 1970s. We feel this is a great feature for JAWS users. And other assistive technology companies such as Dolphin and AiSquared have also built tools to make text found in graphics readable to their users.

But for authors, the rules don’t change. We have lots of tools and tips on how to create accessible PDF documents that can be used by people of all kinds of abilities and preferences, and it’s still our responsibility to use them.

8:19 AM Permalink
June 25, 2013

What is PDF/UA all about, anyway?

The PDF/UA (“Universal Accessibility”) specification, or ISO 14289, published by the International Organization for Standardization (ISO) in August of last year, was a big step forward for authors of the tools we use to create and consume PDF content. But what the spec itself does is a little harder to explain, and there’s been a lot of confusion. I even confused myself recently about what PDF/UA does and doesn’t specify. So I thought it might help to summarize the spec in some detail for those who are coming to grips with its place in the world of PDF accessibility.

If the PDF/UA specification could be summed up in one sentence, it may go something like this:

“PDF/UA makes certain that the PDF format isn’t the source of accessibility problems.”

The end result of a document built using the PDF/UA spec is a more reliable, more accessible document that avoids the tricks and traps that PDF can present. PDF authors don’t need to know anything specific about what goes on behind the scenes; the tools themselves are responsible for adding and preserving the accessibility of the PDF. That’s the value of PDF/UA.

That does not mean that a PDF/UA-compliant document will always be perfectly accessible—issues like poorly-built Word documents or other source material will, of course, carry their accessibility flaws no matter what format they’re converted into. No one should claim that PDF/UA conformance means that a given document will pass the Web Content Accessibility Guidelines (WCAG) 2.0, and organizations shouldn’t treat PDF/UA as a WCAG stand-in. But conformance does indicate that the authoring process for a given piece of content retains its accessibility level when it’s output as a PDF.

The PDF/UA specification defines conformance for three different aspects of PDF: content, readers, and assistive technology. The authoring tools are intentionally omitted: only the content they produce matters here, and that can only be measured at the individual document level.

We’ve seen a number of organizations that are specifying PDF/UA-compliant documents, and that’s a worthwhile approach, as far as it goes. The revamped accessibility checker in Adobe Acrobat Pro XI bases its tests on PDF/UA and WCAG criteria, but doesn’t yet fully test PDF/UA compliance.

The PDF/UA document itself is 23 pages, and thanks to ISO’s publishing model, it’s about $90 US to purchase a copy. We’re sensitive to the cost issue here, but in the interest of full disclosure, Adobe doesn’t own this work (it was the product of participants from a number of companies, and its copyright belongs to ISO), so we’re not able to simply republish the spec. To those who are planning to implement PDF/UA in their readers and assistive technologies, $90 is not a barrier (and if you promise to implement PDF/UA in an open-source tool, I’ll buy you a copy myself, though I’m sure I’d get the better end of that deal).

The material is what we in America call “inside baseball”—it’s very technical, requires a solid understanding of PDF internals, and is heavily cross-referenced with ISO 32000-1:2008, the PDF 1.7 specification. For non-technical authors looking to create accessible PDFs, this spec is very technical; you may be better off looking at the PDF Techniques for WCAG 2.0. However, I’ve taken the liberty of summarizing this spec so that everyone has a chance to understand what conformance entails.

The spec starts by listing what PDF/UA does not do: help with converting paper or electronic documents to PDF/UA; give implementation advice for rendering PDF documents; or tell you how to store PDFs or what OS to use. The rest of the front matter includes normative references to WCAG 2.0, PDF 1.7, PDF/A-2, and PDF/X-1a; defining a handful of terms; and setting a namespace for PDF/UA metadata which goes into every conforming file.

The document then defines conformance at three levels: individual files, PDF readers, and assistive technology.

Conforming files

A conforming file contains features that are valid according to the PDF 1.7 spec, except for features PDF/UA specifically forbids. It has to be marked as a PDF/UA document as described in Section 5, and meet all the requirements in Section 7 below.

Conforming reader

A conforming reader must also be a conforming reader according to PDF 1.7. It will support all the tags, attributes and key values specified for accessibility, and respect when optional content is hidden. It will make the logical reading order available. It will allow AT to inspect artifacts, and its interface must itself be accessible, and not interfere with any AT feature.

There are some repair techniques for headings and tables, rules for handling optional content, attached and embedded files, digital signatures, actions, metadata, navigation, annotations, forms and media.

Conforming assistive technology

A conforming AT supports all of the features of the content and the reader, and should allow navigation by page labels, document structure, or the outline. It should also let the user override default navigation zoom. (A combined reader and AT, perhaps something like TextHelp’s PDF Aloud, could be both a conforming reader and a conforming AT.)

File format requirements

This is the meat of the spec, and there’s some good advice in here for those of you who are already well-versed in tagging PDFs.

All PDF/UA documents must be tagged PDF. Tags must be semantically appropriate (that is, you can’t just mark everything <p> and be done), and in logical reading order. Artifacts (sometimes referred to as “Background” in Acrobat) must not be tagged. If a PDF does anything non-standard with its tags, those tags have to be remapped to standard PDF tags. Standard tags can’t be overridden.

Content can’t flicker, blink or flash, and it can’t be conveyed solely by color, contrast, formatting,  layout or sound. Image-only PDFs may be created, but their content must also be tagged.

The document must have a title, and it must be displayed in the title bar.

Text must be Unicode. The document’s language, and any changes in language, must be declared.

Graphics must be marked up with the Figure tag, and must have alt text, unless it’s presentational, in which case it’s an Artifact. Groups of images that represent one thought are to be tagged as a single Figure. Captions that go with figures must be tagged as such.

Headings must be nested sequentially (e.g., H1-H2-H3 is acceptable, but H1-H3 is not). Headings can go as deep as necessary (e.g., H1041 is valid, if you’ve used the first 1040 levels). Generic “H” headings are acceptable, but can’t be used interchangeably with numbered headings.

Tables should have headers (“TH” tags) with a Scope attribute.

Lists must be marked up appropriately.

Math equations must be in a Formula tag, with alt text.

Page headers and footers must be marked up as Pagination artifacts, so they’re not read out repeatedly.

Footnotes and endnotes must be marked up with the Note tag.

All optional content configuration dictionaries (a PDF feature which allows content to be hidden conditionally) must be named.

Any embedded files must also be accessible.

Article threads (which allow multicolumn layouts across pages) must retain proper reading order.

Digital signature form fields must be laid out accessibly.

Non-interactive forms have to be tagged with PDF “PrintField” attributes so they will appear as read-only form fields to AT.

Static XFA-based forms are allowed. Dynamic XFA forms are not.

Secured documents must allow AT access.

Documents should have outlines that reflect the reading order and nav hierarchy.

Visible annotations must be represented in the right place in the reading order.

Tab order must be defined.

Links must be tagged, and contain an alternate description.

Metadata tags must be properly set for embedded media.

Actions (i.e., scripting) are allowed. Changes in content or focus must be announced to AT, and cannot set time limits on individual keystrokes.

There are requirements for the implementation of fonts that are well out of scope for an overview, but important for reliable rendering of fonts across operating systems and reader implementations.


So, that’s it. We’re hoping a little transparency regarding PDF/UA helps everyone understand what it does and doesn’t do. In time, we anticipate that PDF/UA will make accessible authoring a more automatic and uniform process across authoring tools, which in turn will make the accessibility of PDFs in the wild a lot better in general.

1:45 PM Permalink
March 21, 2013

Slides from CSUN 2013 presentations

Here are PDF versions of our presentation slides from the CSUN 2013 conference:

6:06 PM Permalink
January 14, 2013

Free Webinar: “Exploring Electronic Document Accessibility”

Adobe is offering a free webinar on document accessibility in conjunction with SSB BART Group and FedInsider News. The webinar will take place Wednesday January 23, from 1:30-2:30 (US eastern time zone).

Jon Avila from SSB BART Group will lead the session which will target managers and content authors in addressing the following topics:

  • Overview of accessibility requirements relevant to document creation.
  • Guidance on how to analyze known problems in existing documentation.
  • Proper use of native document creation software.
  • Techniques for finding and fixing accessibility violations.
  • Best practices to maintain and update document creation processes to ensure ongoing accessibility.

You can read a more information about the webinar and register at Please join us for this event!

Update: I neglected to mention it, but the webinar will have live captioning.

Update: The webinar recording is available.

9:00 AM Permalink
January 3, 2013

Acrobat XI Accessibility Documentation

On behalf of the Adobe Accessibility team, I’d like to welcome you all to 2013. We’ve got a big year ahead of us, and we’re starting with some new documentation for Acrobat XI.

We’ve updated our Acrobat accessibility training resources page with four new PDFs:

PDF Accessibility Overview
Covers the accessibility features of PDF as a document format, as well as Adobe Acrobat and Adobe Reader.
Using the Acrobat XI Pro Accessibility Checker
A complete walkthrough of Acrobat XI’s Accessibility Checker, as well as the Make Accessible action wizard.
Acrobat XI Pro PDF Accessibility Repair Workflow
Walk step-by-step through the PDF accessibility process in Acrobat XI.
Acrobat XI Pro Accessible Forms and Interactive Documents
Create interactive forms that can be used by anyone, ensuring privacy and independence for all.

We’ve also created a Acrobat XI accessibility best practices document which contains all four of the above guides in a single file. Documentation for Acrobat versions 8 and up can be found on the training resources page as well.

The new features of Acrobat XI are intended to make creating PDF documents both easier and more automatic. The Make Accessible action wizard walks users through a number of steps, like running optical character recognition and prompting for alternate text on images, and then tests the final product. This makes the process for editing and testing for PDF accessibility a fast, uniform process for authors of all skill levels. The built-in accessibility checker has also been improved, including testing support for the Web Content Accessibility Guidelines (WCAG) 2.0. We think this is the most substantial improvement in Acrobat accessibility since we added support for assistive technology back in 2002.

The team is looking forward to giving a detailed Adobe Acrobat XI walkthrough at the 28th Annual International Technology and Persons with Disabilities Conference on February 28th, and at other conferences throughout the year. We hope you’ll find these tutorials useful.

5:31 AM Permalink
October 1, 2012

Acrobat XI Accessibility Changes

Acrobat XI (pronounced “Acrobat Eleven”) is coming soon, and with it a host of new accessibility features that will help authors produce more accessible PDF documents, with less effort.

Key improvements in Acrobat include the addition of the Make Accessible Action, enhancements to the Touch Up Read Order Tool, and improvements to the accessibility checking tool to guide authors testing against WCAG 2.0 and PDF/UA.

The Acrobat team has more information about accessibility in Acrobat XI posted, and more information is coming soon.

10:07 AM Permalink
May 20, 2012

Adobe Support for Open Source Assistive Technology

Adobe continues our support for NVAccess development of the NVDA screen reader in 2012, and with that funding we are supporting a number of priorities designed to help NVAccess developers continue to offer an up-to-date tool for end users as well as developers seeking to provide accessible applications and web sites. Included in the list of priorities is support for ongoing improvements to NVDA’s ability to interact with PDF documents, AIR applications, and ebooks read in Adobe Digital Editions, and for general HTML and ARIA improvements.

For PDF specifically, we recognize the value of NVDA supporting the upcoming PDF/UA standard (ISO 14289) and have agreed with NVAccess that the PDF-focused portion of the work should be focused on enabling NVDA to become a PDF/UA compliant assistive technology.

Past improvements to NVDA’s support for PDF have brought significant benefits for NVDA users reading PDF documents. These past improvements were not designed to focus on PDF/UA compliance, but most of the improvements serve to accomplish compliance and dovetail nicely with current efforts focused on the new standard. The work to make NVDA compliant with PDF/UA will not be able to be completed in the current year, as the scope of work is beyond what can be completed within the current year’s funding, but we expect to be able to provide details about progress in the coming months. As support for PDF/UA is an important goal, we will seek ways to offer support to NVAccess in future years also.

We are almost halfway through the year for this funding and NVAccess developers have made continual improvements – we encourage screen reader users and accessibility-interested developers to download the latest release of NVDA to read ebooks, test web pages, read PDF documents, and more. NVDA is a great tool and Adobe is pleased to help support its development.

Update: We should also clarify that our support for NVDA does not come at the expense of support for other assistive technologies. Tools such as Claro Read, JAWS, Supernova, Window-Eyes, ZoomText, and many more are important tools that users depend on and we will continue to work with the vendors of these great tools.

9:43 PM Permalink