Adobe Accessibility

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.

Harmonization of accessibility standards is a primary goal for Adobe which is why for many years Adobe has worked on the W3C Web Content Accessibility Guidelines (WCAG) working group – our participation was driven by a desire to help define a WCAG 2.0 standard which would be useful for web content that Adobe tools are involved with the authoring or display of, including PDF, Flash, HTML, and more. There is great benefit for developers, authors, and end users when there is an agreed on standard for what constitutes an accessible experience, and it is encouraging to see that WCAG 2.0 is regarded as the primary standard for web accessibility and is referenced by national governments around the world. However, there is more to achieving accessibility than the normative text of WCAG 2.0.

In 2004, Adobe and AIIM started the PDF/UA (Universal Accessibility) activity with the intent of producing standards specific to PDF authoring and presentation which ensure that conforming PDF (ISO 32000-1) files are accessible and usable to all, including users who rely on assistive technology. Today, PDF/UA is ISO 14289-1, a “Final Draft International Standard (FDIS)”, expected to be published later in 2012.

We’ve received many questions about the relationship between PDF/UA and WCAG 2.0. WCAG 2.0 was developed as a technology-independent standard and provides individual (normative) success criteria for accessibility which are general enough to apply across technologies. The W3C’s WCAG working group also provides a growing collection of advisory (non-normative) techniques to offer technology-specific guidance, including a growing set of techniques for HTML, CSS, Scripting, PDF, Flash, and more. Beyond these techniques, developers need to conduct additional research to ensure that the content or applications they create meet the WCAG 2.0 success criteria – for example, a Java developer looking to offer a compliant applet will not find techniques on the W3C site at this time, but may be able to meet WCAG 2.0 if they correctly follow guidance provided elsewhere and evaluate the resulting applet against the WCAG success criteria.

PDF developers need this type of clarity on how to meet WCAG 2.0, and the PDF techniques, while useful, do not presently represent a complete set which encompass all technical requirements for accessibility in all PDF documents. This is where PDF/UA provides help. PDF/UA provides normative technical specifications for the use of the PDF format, defining proper structure and syntax to enable reliable access. This includes identification of necessary tagging structures, how to specify alternative text for images, how to ensure correct Unicode mappings for character glyphs, and many other file, page and object-level specifications, as well as how Reader applications and assistive technologies can fully process PDF/UA conforming files to maximize accessibility.

PDF/UA defines the technical specifications to enable PDF documents to meet WCAG 2.0, but WCAG 2.0 has additional requirements which require an author’s attention. The areas where WCAG 2.0 has additional requirements include time-based media (guideline 1.2), scripting and actions (e.g. success criteria 3.2.1 and 3.2.2), and certain types of content (e.g. success criteria 2.4.4). For these and other additional requirements, the W3C’s technique documents (both general and PDF-specific techniques) provide guidance for authors interested in complying with WCAG 2.0.

PDF/UA clarifies and simplifies the PDF-specific technical requirements to meet WCAG 2.0. Adobe fully supports PDF/UA and intends to use and promote it in our PDF authoring tools. Adobe also plans to support the conforming Reader requirements, which are part of PDF/UA. Authors using Adobe tools such as Adobe Acrobat will be enabled to support PDF/UA as a first and major step toward compliance with WCAG 2.0.