March 14, 2017

Accessibility Standards Get a Much-Needed Refresh

The last time the federal government updated its accessibility standards for electronic and information technology “Shrek” was dominating the U.S. box office and the Supreme Court was ruling on “hanging chads” in the Florida recount 16 years ago. To keep up with evolving technology, the United States Access Board started working with consumer groups, the disabled community, and technology companies like Adobe in 2006 to update Section 508 of the Rehabilitation Act of 1973 to ensure the federal government’s electronic and information technology is accessible to people with disabilities.

After almost a decade of work, the board released its “Section 508 refresh” on January 18. In the updated rule, the board addresses improved access for numerous disabilities and takes a significant step towards greater accessibility. The most important element of the refresh is the adoption of Web Content Accessibility Guidelines (WCAG) 2.0 put forward by the World Wide Web Consortium (W3C). This is critical because it harmonizes the US government’s rules with the rest of the world, making it easier for American businesses like Adobe to develop products that can be used around the globe.

Adobe commends the U.S. Access Board for not going their own way and developing new standards. For many years, Adobe participated in the development of accessibility guidelines, including the WCAG 2.0 recommendations. We believe that harmonizing standards across the globe is the key to expanding accessible content for everyone. Given the fast pace of technology, accessibility regulations need to be consistent.

While the refresh only pertains to federal agencies, its impact will be felt in state and local governments as well because adopting the WCAG 2.0 standard signals to state and local entities that they should adopt the same rules. Universities and many other institutions are expected to follow the government’s lead and adopt similar standards in the years to come, which is great news and should speed up adoption.

The new rule also applies WCAG 2.0 standards to electronic documents, which many Adobe products already meet. Adobe has taken many steps to make our products accessible for all users, including adding robust capabilities to many Document Cloud products. Adobe Acrobat DC and Adobe Reader DC support assistive technologies and allow users to create, edit, and read accessible PDF documents.

Agencies now have a year to reach compliance. Agencies have traditionally struggled with Section 508 compliance in the past by not providing adequate staff resources and not providing adequate training. As agencies start to review the rules and determine what steps they need to take, Adobe wants to partner with them to find solutions. Adobe can help agencies adopt software solutions that will meet accessibility standards and produce accessible content. Compliance information is provided for most Adobe products that detail how products comply with existing regulation.

The next big step comes in July when an update to the Federal Acquisition Regulations (FAR) will provide additional guidance. The Federal Acquisition Regulatory Council (FAR Council) and federal agencies will incorporate the updated standards into their acquisition regulations and procurement policies. Once this occurs agencies will be able to work with vendors to determine what the best software solutions are for their needs.

Adobe has made it a mission to develop digital tools that are accessible for all users. We work to develop new accessibility features in our products and programs while encouraging developers to produce rich, engaging content that is also accessible. As a global leader in the software industry, we believe that different abilities should never limit opportunities. We will continue to develop software solutions that can be used by as many people as possible, while working with governments around the world to ensure that people of all abilities are able to access and obtain the government services they need.

1:41 PM Comments (0) Permalink
February 24, 2017

Adobe at CSUN 2017

For those of you attending the CSUN Assistive Technology Conference in San Diego next week, so will lots of Adobe employees. Here are the sessions we’re participating in:

Wednesday, 9am
Adobe Experience Manager and AEM Forms Accessibility with Amy Chen and Nirmal Ganesh, Mission Beach AB, 3rd floor, between towers
Thursday, 1:20pm
WCAG 2.1—A New Version of Accessibility Guidelines with panelist Andrew Kirkpatrick, Cortez Hill AB, 3rd floor, Seaport Tower
Thursday, 3:20pm
Advanced Techniques for PDF Accessibility with Rob Haverty, Cortez Hill C, 3rd floor, Seaport Tower
Thursday, 4:20pm
Adobe Accessibility Town Hall, Cortez Hill C, 3rd floor, Seaport Tower
What Comes After WCAG 2.1? with panelist Andrew Kirkpatrick, Cortez Hill AB, 3rd floor, Seaport Tower
Friday, 10am
Accessibility in an Agile World with the Adobe Livefyre Team with Amy Chen, John Martins and Matthew Deutsch, Old Town AB, 2nd floor, Seaport Tower
Friday, 1:20pm
ACT Now: Accessibility Conformance Testing for WCAG with panelist Andrew Kirkpatrick, Torrey Hills AB, 3rd floor, Seaport Tower
Friday, 2:20pm
Being Right Is Not Enough: Critical Lessons for Accessibility Advocates with Matt May, Mission Beach AB, between towers
WCAG 2.1—A New Version of Accessibility Guidelines with panelist Andrew Kirkpatrick, Golden Hill AB, 3rd floor, Seaport Tower

Please join us, and follow our @AdobeAccess Twitter feed for updates.

7:33 PM Permalink
August 29, 2016

Meet the Adobe Accessibility PMs

We’ve grown a lot in the last year or so, and it occurred to us that we haven’t really introduced our new product management team to the world. So we fixed that, in Adobe fashion, with a short video.

1:15 AM 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 30, 2015

G3ict PhoneGap accessibility white paper

G3ict, in collaboration with Adobe Accessibility, presents a free white paper on PhoneGap accessibility. This 10-page introduction covers the state of mobile app accessibility, the advantages inherent to PhoneGap’s approach in creating accessible cross-platform mobile apps, and Adobe’s motivation to create a PhoneGap accessibility plugin that bridges the gap between web accessibility and native mobile accessibility APIs.

If you’re looking for a high-level introduction on what makes PhoneGap a good platform for building accessible mobile apps, this is it.

The PhoneGap Mobile Accessibility repository on Github is also available for PhoneGap developers who are interested in implementing more advanced accessibility support in their apps. (TL;DR PhoneGap apps by default benefit from good web accessibility practices, but the accessibility plugin gives developers access to native accessibility APIs, such as whether high contrast is on, or the user has selected a preferred text size.)

1:14 AM Permalink
March 27, 2015

CSUN 2015 presentations

We had a busy week at the CSUN conference this year. In addition to giving a preview of the next version of Adobe Acrobat and Reader, we presented on mobile application accessibility using Adobe PhoneGap; content management features in Adobe Experience Manager; and our experiences working on an accessibility-first strategy for CloudUI, a core technology used across Adobe products. Here are the slides from those presentations.

Acrobat DC Accessibility: What’s New

Acrobat DC and Reader DC: the Reading Experience

Accessible Documents with Acrobat DC, Reader DC and PDF Maker

CloudUI: a Case Study

Mobile Accessibility with PhoneGap

Accessible Content Management with Adobe Experience Manager

4:56 PM 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
March 26, 2014

Adding accessibility support to Adobe PhoneGap

Last week, at the 2014 CSUN Conference, we were able to give a demonstration of the new accessibility API we’ve been working on for Apache Cordova, better known as Adobe PhoneGap.

PhoneGap uses web technology (HTML, CSS, JavaScript, and the operating system’s browser core) to create mobile apps that you can install from your phone’s app store. There’s support for just about any mobile platform you can name, and somewhere around 20,000 apps are currently available. Odds are, you’ve used at least one of them without knowing it.

The accessibility of PhoneGap apps can actually be fairly good, depending on the underlying code used to build it. That’s because mobile browsers already come with a lot of accessibility support on their own, that these apps can use to their advantage. What they can’t do, that other mobile apps can, is ask the operating system if, for example, a user has large fonts enabled, or has colors reversed, or whether the screen reader is running. That’s why we built a Mobile Accessibility plugin, which feeds that information to PhoneGap apps, including notifying those apps when it changes. This plugin allows PhoneGap apps to look and feel even more like native applications by taking into accounts the preferences of the person using the device.

We’ve developed this API publicly on GitHub, so people can poke at it and give us feedback, but also to encourage more development. We started by building support for iOS and Android because, having built-in screen readers, magnifiers and other features, they had the most existing work we could integrate. But there are other platforms, like Windows Phone 8 and BlackBerry OS, which run PhoneGap apps and have accessibility APIs of their own, and which could have their own support in PhoneGap using this plugin. It’s on our to-do list, but if you have a more pressing need, you can follow the iOS and Android versions as a model for developing (and hopefully contributing) your own.

If you don’t have software development kits for mobile operating systems installed, but you have a free Adobe ID, you can still try your hand at developing a mobile app of your own. Try PhoneGap Build, our new service that lets you upload the code you want to turn into an app, then builds it for multiple platforms at once. You can even install it onto your test devices simply by entering a URL or snapping a QR code.

If you already use PhoneGap Build, we have even better news: the Mobile Accessibility plugin is now supported in Build, so you can use it like any other core plugin. Documentation is on GitHub, and we’ll be working on other ways to show developers how to improve the accessibility of their applications as time rolls on.

9:16 PM Permalink
November 12, 2013

Adobe supports the Convention on the Rights of Persons with Disabilities

The United Nations Convention on the Rights of Persons with Disabilities (CRPD) was adopted in 2006, and has since been signed by 137 countries. The CRPD affirms the equality of all people, without exceptions due to their abilities. This month, Adobe sent a letter of support for the ratification of the Convention to Senators Robert Menendez (D-NJ) and Bob Corker (R-TN), the Chairman and Ranking Member of the Senate Foreign Relations Committee.

The Senate is responsible for approving treaties put forward for ratification by the president. The CRPD was signed by the United States in 2009. Unfortunately, at the time the CRPD was first presented to the Senate, it was not approved, falling just a few votes short of the required two-thirds vote.

Adobe is adding its voice to the chorus of organizations and advocates that believe the CRPD is an important step toward ensuring people with disabilities have equal access to government services, employment opportunities, and technological advances. One of the expectations of the CRPD is that ratifying countries will adopt standards for information technology accessibility. In order to facilitate the goal of equal access, it is critical that the adopted standards be harmonized to ensure that software from companies such as Adobe, developers creating content, and assistive technology vendors can focus on a single global standard for accessibility rather than needing to address unique requirements in each country.

The United States, through legislation such as the Americans with Disabilities Act of 1990, has already affirmed that disability must not be a barrier to entering a building, finding and keeping a job, interacting with government officials and services, shopping, dining out, or moving from place to place. Other U.S. laws guarantee equal access to education, voting, buying a home, catching a flight, and even watch TV shows on the Internet. While there is still work to be done, the foresight of bipartisan U.S. policymakers over the decades in creating a legislative framework that moves this country toward equal access for all people is now being emulated worldwide. Ratifying the CRPD will further show the world that these are the values we should all share.

8:55 AM Permalink