Accessibility and Adobe Open Government
As the leader of Adobe's accessibility team, I am proud of the commitments Adobe has made to the mission of accessibility and needs of individuals with disabilities. Adobe produces innovative software that enables the development of content that is visually rich and highly interactive, and as a result rendering that content in a productive way for people with visual disabilities can be a challenge - one we take seriously.
Adobe has worked on accessibility standards committees in the U.S. and internationally, including: the W3C's WCAG 2.0, ATAG 2.0, Timed Text/DFXP, HTML5, and Protocols and Formats working groups; the U.S. Access Board's TEITAC subcommittee; and the PDF Universal Accessibility work group at AIIM. Two important goals of our participation are to help ensure that accessibility standards are effective at meeting the needs of those with disabilities and to promote technological neutrality. From an accessibility perspective, we believe that developers should be able to use any technology as long as they are able to deliver content that meets accessibility standards and end-user needs.
Adobe Flash and PDF (which is now an ISO standard - ISO 32000-1) both provide support for accessibility, but it is important for authors and developers to learn best practices and understand user needs in order to deliver results that take advantage of the unique capabilities of the formats and that allow all users to access the information and functionality. Authors sometimes will make a trade-off between producing a visually interesting application in a timely fashion and adhering to accessibility requirements. Other times, accessibility gets left to be dealt with at the end of a project that has a firm end-date and when other features take longer than expected, accessibility or other items fall off the schedule. Government agencies don't get to make these trade-offs as they are bound by law to make their services accessible, but commercial entities don't have the same requirements and often overlook the needs of people with disabilities when creating web experiences and documents.
Despite our best intentions, Adobe overlooked the needs of people with disabilities in our recently-launched Open Government web site, which failed to meet certain accessibility best practices. Some customers have contacted us and a few bloggers pointed out the issues and we are working to improve the Open Government site. We apologize to everyone who attempted to access the site and was unable to do so. With the benefit now of seeing the site in its present state rather than the initially-planned more dynamic and interactive version, the team is recreating the site using a combination of HTML and Flash. Several improvements to the current Flash-based site have been addressed already. My hope for this post and the intention of the Open Government site is to help other developers learn from this example, and improve their own development practices of visually rich web sites for access by all users.
Whether users need to use assistive technologies such as screen readers or magnifiers, operate their computer with the keyboard alone, view larger text sizes, view captions or subtitles for audio information, or utilize many other accessibility features, these features already exist in Adobe products. And while these are not perfect in all products yet, we are dedicated to enabling our tools to handle accessibility in robust and reliable ways.
If you are interested in learning more about accessibility in Adobe products, I'm providing some interesting links below. As always, we value the feedback of our customers and end users, so let us know your thoughts.
For more information about PDF accessibility:
- http://www.adobe.com/accessibility/products/acrobat
- http://www.adobe.com/accessibility/products/reader
For more information about Flash accessibility:
PDF and Flash accessibility training resources:
- http://www.adobe.com/accessibility/tutorials.html
- http://www.adobe.com/accessibility/best_practices.html
Adobe accessibility compliance statements:
Comments
Proprietary technologies are NOT open.
DEATH TO FLASH!!!!
Posted by: ndeplume | November 8, 2009 7:26 AM
What specifically has been addressed in the current version, and what specifically will be addressed in what I assume is a future revision?
Posted by: foresmac | November 10, 2009 6:56 PM
Sorry, I no longer believe in Adobe when it comes to following their own rules for accessibility. Adobe has often failed or fallen far behind often due to budgets and politics. Even third party ebooks teaching Adobe products fail to follow Adobe guidelines. Adobe wont dare tell those party publishers their mistakes or encourage them to work better with disabled readers. Having happy publishers is more important than helping disabled readers. I am not a thief -- I resent being treated like one-- just a struggling smart disabled person determined to master adobe products. Adobe, prove me wrong!
Posted by: Andrew Meit | November 10, 2009 10:55 PM
Even when Flash is made "accessible", assistive technology/keyboard users on platforms other than Windows, and screen reader uses that aren't using JAWS or Windows Eyes, are unable to access Flash content. Would love to see this improved.
Posted by: hh | November 11, 2009 10:10 AM
Heidi,
You are limited to Windows presently, but you can also use HAL or NVDA to access Flash content.
Posted by: AWK | November 11, 2009 10:25 AM
would you care to be more specific about the "certain accessibility best practices" - what those practices are, in what way the open government site fails to meet them, and the planned solution? This could be a great educational case-study.
Posted by: Doug | November 11, 2009 2:58 PM
Doug and Chris,
I will provide the information that you are asking for - I'll post an update once I can provide a better sense of likely timing for the changes.
Posted by: AWK | November 12, 2009 4:33 PM
Here is a broader question.
In what cases can we consider Flash as "accessibility supported" in a WCAG 2.0 context?
It should not be left to developers and designers to define these parameters. Vendors should clearly define the limits, if any, of their accessibility support and publicly post their "accessibility supported" limitations, VPAT is useless (too much room to fudge the real results).
We need specifications detailing: platform, plug-in, and recommended AT and configuration, before we can chose to consider a technology for use as "accessibility supported" and WCAG 2.0 conformant.
Tell us, up, front where it WILL work.
Vendors have greater resources available than individual developers/designers.
Very interested in the the response.
Posted by: Steve Buell | November 13, 2009 7:21 PM
took a real long time to set up,I hope its worth it
Posted by: annette | January 5, 2010 9:05 PM
It would already be good to make people believe in your nonsense if the Adobe web store followed the best practices in the first place, and these best practices quite honestly have a number of gaping holes, thus making them too little too late.
Posted by: LD Martin | February 1, 2010 1:30 AM