There’s a new document to check out if you develop interactive forms using LiveCycle Designer, whether you do so in an environment where you simple save the forms to PDF in Designer or you make use of Adobe’s LiveCycle Forms ES product to produce your forms from the XDP XML file that LiveCycle creates. The new document is available at http://www.adobe.com/accessibility/products/livecycle/pdf/LiveCycle8_2AccessibilityGuidelines.pdf. Please let us know if you have comments, questions, or suggestions.
Posts in Category "PDF"
InDesign authors often ask about generating accessible PDF files. To help respond to this, we worked with David Blatner of InDesignSecrets.com to combine our accessibility experience with his deep knowledge of InDesign so that we could produce a document that would be useful to InDesign authors interested in accessibility.
The document is located at http://www.adobe.com/accessibility/pdfs/accessibledocswithindesignCS4.pdf but you might also be interested in the InDesign product accessibility page for additional information.
Please pass on any comments.
Tomorrow is the final webinar in the series offered by The Paciello Group. The final session is on Interactive PDF forms, using Adobe Acrobat and Adobe LiveCycle Designer. The free webinar is at noon EDT on Wednesday April 8, 2009.
Information about how to join the webinar is available at http://www.paciellogroup.com/blog.
The session will be captioned live and offered as an archived session for asynchronous viewing.
Open question – what topics would you like to see covered in future webinars?
The Paciello Group is doing a series of free webinars on PDF and Flash accessibility. The first webinar on PDF accessibility and WCAG 2.0 was recorded for asynchronous viewing, and the slides from the PDF accessibility talk are available for download.
Next week there are two additional webinars. March 31 the topic is Flash accessibility and WCAG 2.0, and April 1 the topic is PDF forms and WCAG 2.0 (Correction: the PDF Forms webinar is April 8. See the Paciellogroup blog for complete information).
All of the 90-minute webinars are captioned as real-time events (using Adobe Acrobat Connect) and the captions are included in the recorded sessions.
The webinars will be held at noon Eastern time at http://my.adobe.acrobat.com/wcag2. You can find out more about the webinars at the Paciello Group’s blog – see the post titled The Paciello Group and Adobe Present WCAG 2.0 Accessibility Webinars for Flash and PDF for more information. Set your calendars!
WebAIM released the results of a survey of screen reader users and the results are interesting for what they tell us about HTML use, but the commentary around user’s thoughts on Flash content and PDF documents is of particular interest at Adobe. The results state that 71% of screen reader users responding feel that Flash content is very difficult (34%) or somewhat difficult (37%) to use, and 48% of screen reader users responding feel that PDF documents are very difficult (17%) or somewhat difficult (31%) to use. I think that it is worth putting some additional context around these numbers.
Given that the Flash player has supported accessibility since 2001 when Player 6 was released, and the Flash authoring tool provides support for developers to add accessibility to Flash content, why are Flash developers not adding necessary information to their projects? Some are, to be certain — there are examples of Flash being used properly such as what is offered at Social Security (http://ssa.gov/pgm/flash/overviewcaptioned.htm) and the U.S. Department of Education (http://federalstudentaid.ed.gov/mystory/index.html) web sites, but you don’t need to look too far to find inaccessible examples.
Flash is a tool to make content, but many developers aren’t providing the necessary information. We’ve published books with information relevant to the topic such as Web Accessibility: Web Standards and Regulatory Compliance which I contributed chapters to and Universal Design for Web Applications: Web Applications that Reach Everyone which Matt May on the Adobe accessibility team co-authored with Wendy Chisholm. We also have information available at the Adobe Accessibility web site — please point these resources out to Flash developers who don’t make their content accessible.
The story is similar for PDF documents – there is tooling readily available to make PDF documents and forms accessible, and many authors do take the time to add necessary accessibility information, but not everyone does. For PDF, please point authors to the Acrobat 9 accessibility guides at http://www.adobe.com/accessibility/products/acrobat/ or to the Web Accessibility: Web Standards and Regulatory Compliance book chapter on PDF.
I feel that it is important to not over generalize from the WebAIM survey data for Flash and PDF. It is fair to say that users are rating these formats less favorably than any of us would like to see but that does not mean that the formats are not accessible. Users have interacted with examples in these formats from which they have formed impressions but that does not mean that developing accessible content in Flash or PDF is impossible. This idea is echoed in Adrian Higginbotham’s comments to the WebAIM blog announcement of the survey results where he acknowledges challenges with some Flash content but finds success with others.
Flash and PDF are tools and the accessibility of the content depends on whether the developer is making an effort to produce accessible content. Please encourage authors and developers to handle accessibility properly.
Adobe Reader 9 is out and I wanted to point out where to download Reader and to mention that there is a new document available to help screen reader users understand how to access PDF.
The Guide was created in conjunction with AFB Consulting (the consulting arm of the American Foundation for the Blind) and provides information for users of two tools (JAWS and Window-Eyes) to help understand what is possible and expected when interacting with different types of PDF documents that are commonly found online. The types are PDF documents that are:
- tagged correctly for accessibility
- untagged, with no author attention to accessibility
- scanned documents
- interactive forms
Helping users understand the differences between these documents and how their assistive technologies can be best used is an important step toward efficient user of PDF files by screen reader users. We hope that this guide is useful, and are interested in any comments.
The guide is presently available as a PDF file, but will also be available as a series of HTML pages soon.
The guide and reader 9 can both be accessed from the Reader 9 accessibility page, at http://www.adobe.com/accessibility/products/reader/.
Adobe announced Acrobat 9 yesterday, so I want to point out the resources that are available to people interested in accessibility. The Acrobat 9 accessibility page is located at http://www.adobe.com/accessibility/products/acrobat/, and from there you can read the brief overview, find information about what’s new in Acrobat 9, and locate the Acrobat FAQ for accessibility.
There is a lot of PDF that is generated though Adobe’s PDFMaker plug-in for Microsoft Word. You can quite easily create PDF documents that meet the majority of accessibility needs with very little effort, if you know how. For the CSUN conference, we created a one-page document that helps guide users who may not know much about accessibility so that they can more easily address accessibility in their documents.
This document doesn’t cover every possible issue, but identifies the small number of items that need some attention to avoid the most common issues that authors can prevent. In general, if an author:
- provides equivalents for images in Word
- uses Word’s styles to define structural headings
- identifies table headings for simple tables
- uses Word’s column feture instead of text boxes, and
- enables the generation of tagged PDF
The results are excellent for most documents created in Word. Yes, you can deviate from this path and need to perform repair work to make a PDF document accessible, but to start I want to ensure that authors know what the path to minimize challenges looks like.
This is a first stab at this document, please let us know what you like, if it is useful to you, or any other comments you may have.
Download Reference Card
Last week, members of the Adobe accessibility team attended the California State University’s “Technology and Persons with Disabilities Conference” – aka CSUN. This is a big event in accessibility each year and if you are interested in accessibility you should consider attending in 2009.
Adobe participated in four talks at CSUN:
- IAccessible2 Development: An Accessibility API that Works for Assistive Technologies and Applications. This was a panel discussion involving IT and assistive technology companies.
- Accessible PDF Authoring Techniques. This was a talk by Greg Pisocky and Pete DeVasto from Adobe and Brad Hodges from the American Foundation for the Blind. The presentation slides are available.
- Rich Internet Applications with Flash and Dreamweaver. This was a talk by Matt May and Andrew Kirkpatrick discussing Flash and AJAX accessibility, related to Adobe’s SPRY framework, Flash and Flex. The presentation slides are available.
- Accessible Internet Video. This was a talk by Andrew Kirkpatrick on how you can deliver the most accessible experience in video online using Flash. The presentation slides
are available. I’m going to post the main demonstration example shortly.
Please take a look and let us know if you have any comments.
A group of IT and assistive technology companies have formed a group designed to address engineering challenges around accessibility issues. The group’s name is the Accessibility Interoperability Alliance, or AIA. Adobe is part of this group because it is important to have improved methods to provide straightforward interoperability between IT products and assistive technology tools.
Of particular interest is the project that seeks to harmonize existing accessibility APIs such as IAccessible2 and UIAutomation. With the wide variety of assistive technologies available today, both these tools and Adobe’s players need reliable and standard methods to participate in information exchanges with assistive tools. There are too many tools for Adobe’s players to support directly through customization and similarly the assistive technology tools have too many IT products that they need to support so they too cannot provide custom solutions across the board. The way forward is through better and harmonized (or converged) APIs.
The AIA press release is at: http://www.accessinteropalliance.org/newsevents/pr121007.html.
The AIA group web site is http://www.accessinteropalliance.org/.