I spoke on Adobe’s efforts to support the captioning aspects of the 21st Century Communications and Video Accessibility Act at the TDI Conference a couple of weeks ago in Austin, TX. In this talk I highlight a number of efforts to support captioning that Adobe has worked on – most people interested in captioning are familiar with some but not all of these. Take a look and let me know if you have any comments.
The new real-time captioning pod for Adobe Connect 8 is now available at the Adobe Exchange. Note: Link updated to point to the current version of the captioning pod
This pod improves on the previous version in several ways:
- Predefined connection information for CaptionColorado, CaptionFirst, and the Media Access Group at WGBH
- Built-in ability for users to record a transcript of the captioning, and export to text or HTML. (Meeting hosts can disable this if required)
- Five color and contrast options for caption display, and multiple font size choices
- Support for multiple concurrent tracks of captioning, of particular use for multi-lingual audiences
- End-user rewind controls to review caption information
As with the earlier version, captions are recorded when a Connect meeting is recorded, so an archived meeting will display any captions available during the live meeting, and end-users who may find live captioning distracting or who simply do not wish to view captions can disable the display for their view of the meeting without disrupting the captioning for other participants.
Closed captioning vendors interested in delivering captioning to Adobe Connect meetings can contact us (email: access [at] adobe) for instructions on how to communicate with the caption pod.
The pod was developed by eSyncTraining who did a great job taking a wide variety of requirements into consideration and building the pod. We’re discussing further improvements to the pod already, as in developing this pod we consulted with experts at each of the caption agencies as well as current users and captioning experts and as a result have additional ideas to investigate. If you have other ideas for the pod, please let us know.
I’m pleased to share a new document: Flex 4 Accessibility Best Practices. This document was developed with the help of the SSB BART Group and provides valuable information to help developers create applications in Flex that meet the needs of users with disabilities and help address compliance targets.
This document will soon find its permanent home on the Adobe Accessibility Best Practices page.
Please feel free to send any comments or questions.
The California State University at Northridge’s Conference on Disability is going on March 16-18, 2011, and Adobe is offering a number of sessions that we hope people will find interesting and informative, as well as offering opportunities to talk directly to Adobe’s accessibility team and product team members.
The event will feature several sessions and events that I want to provide some details for. Here’s our schedule of events:
Wednesday, March 16
- PDF Portfolios: Accessible Interactive Collections of Documents and Multimedia Files (WEB-1030) (8:00-9:00am Emma C)
- Accessible HTML with Adobe Authoring Tools (WEB-1052) (9:20-10:20am Manchester A – Adobe)
- Adobe® Reader® X and Screen Reader Access (WEB-1050) (10:40-11:40am Manchester A – Adobe)
- Accessible Web Conferencing with Adobe Connect (WEB-1053) (1:50:00-2:50pm Manchester A – Adobe)
- Using Adobe Acrobat® X Action Wizards for Accessibility Repair (WEB-1059) (3:10-4:10pm Manchester A – Adobe)
Thursday, March 17
- Advice from the Field: Processes that Work to Ensure PDF Accessibility (WEB-1056) (9:20-10:20am Manchester A – Adobe)
- Adobe Open Forum (WEB-1055) (1:50:00-2:50pm Manchester A – Adobe)
- Using Adobe® InDesign® to Author Accessible PDF (WEB-2060) (3:10-4:10pm Manchester A – Adobe)
Friday, March 18
- Accessibility Best Practices for Authors (WEB-1058) (9:20-10:20am Manchester A – Adobe)
- Adobe Flex Best Practices – What to Expect (WEB-2054) (10:40-11:40am Manchester A – Adobe)
- e-books with Adobe Digital Editions (WEB-1051) (1:50:00-2:50pm Manchester A – Adobe)
- HTML 5 and Flash – An Accessibility Comparison (WEB-2057) (1:50:00-2:50pm Manchester A – Adobe)
- New session: NVDA with Adobe Reader and Flash – Michael Curran & James Teh present an overview, highlighting NVDA’s advanced support for Adobe Reader and Flash. (3:10-4:10pm Manchester A – Adobe)
The following is not an Adobe session, but it is introducing a valuable resource in the form of a course on accessible Flash development, developed jointly by the Department of Veterans Affairs and SSB BART Group.
- Creating Dynamic, Interactive, Accessible Flash (WEB-2009) (Wednesday 1:50-2:50, Cunningham B)
Adobe will have several people at CSUN and will be attending the TweetUp as well as being available to talk between or after sessions. Please come introduce yourself and ask questions and share your thoughts.
Adobe is running a series of training in Australia the first week of March to help Australian Government employees understand how to create accessible PDF documents. The trainings are being held in Canberra at the National Museum of Australia, but will be recorded and made available online after the sessions (probably with a 1-2 week delay in order to have the recordings captioned and posted). We are running these sessions in conjunction with the Australian Government Information Management Office (AGIMO).
I’m delivering two different presentations (twice each):
- PDF Accessibility for Everyone – suitable for a wide range of user knowledge of accessibility, focusing on common authoring pathways
- PDF Accessibility for Techo’s – an advanced session for people with good knowledge of accessibility
More information about the sessions, and registration for attendance, is now available.
I’m looking forward to these sessions and helping people understand how to create PDF documents that meet WCAG 2.0 and are easily used by people with disabilities.
BS 8878:2010 is a new code of practice developed by the British Standards Institute (BSI) which describes a process to ensure that websites and online services provided by an organization are accessible to all web users including persons with disabilities. BS 8878:2010 will formally be launched on Tuesday, 7th December 2010.
BS 8878 is not intended to be a technical specification. Instead, it sets out a process and brings together and summarizes the information needed by organizations providing web services to understand how to embed accessibility requirements into their production processes at all stages. Additionally, BS 8878 also provides information on why accessibility should be an integral part of the planning and design process by listing out legislative, commercial and ethical reasons.
It also states that the ideal situation for assuring accessible experiences is that organizations produce web products that confirm to W3C’s Web Content Accessibility Guidelines (WCAG) and associated standards.
We welcome this new code of practice and hope that this will provide a better understanding of the importance of accessibility to an organization providing web products. Most web accessibility standards are inherently technical in nature and are difficult to understand by non-technical members of an organization. BS 8878 fills this information gap.
We at Adobe are always striving to provide the best experiences for our users irrespective of their disability. At the same time, we are also trying to make it easier for web developers, designers and content authors to create accessible content and applications on the web using various Adobe tools.
- Adobe is an active participant in W3C’s Web Accessibility initiative (W3C-WAI) and made contributions to the development of the WCAG 2.0 standard.
- The Techniques for WCAG 2.0 document published by W3C now includes techniques for Flash content and helps define a way for authors to comply with WCAG 2.0.
- We are also working on a collection of PDF techniques, which we aim to have available in the next round of the techniques document update.
- The Adobe Accessibility web site contains several useful resources for authors, end users, and those getting started learning about accessibility.
There was an important ruling today on accessibility from the Canadian Federal Court that is worth a read.
A blind woman filed suit against the government of Canada stating that the government “violated her rights under section 15(1) of the Canadian Charter of Rights and Freedoms, Part I of the Constitution Act, 1982″. In short the findings of the court were that many web sites for the Canadian government are not meeting the Common Look and Feel standard (CLF). The Court found that the government should update the CLF standard to utilize WCAG 2.0 instead of WCAG 1.0 and that there is sufficient evidence of compliance problems that need to be addressed that the Court found that the applicant was discriminated against due to the need to access information and apply for employment via these websites. The Court is allowing the government 15 months to come into compliance.
There are a couple of points raised in the ruling and in a Globe and Mail online article (Court orders Ottawa to make websites accessible to blind) that I would like to clarify. The points are as follows:
- From the ruling: “The applicant testified that in June 2007 she attempted to access information on the consumer price index and unemployment rate from the Statistics Canada website. She stated that actual statistics were, however, only available in “pdf” format, which is not accessible to screen reader technology.”
- From the ruling: [reported by a witness for the applicant] “…for example, “flash” is a technology that cannot be read by many screen readers. If a website uses “flash” technology, the user will not be able to access that content…”
- From the Globe and Mail article: “Many blind people use screen readers, computer software that translates electronic text into audio. But the readers aren’t foolproof — for one thing, most can’t decipher PDF files, a format often used to publish documents online.”
None of these is accurate. Even in 2007, most screen readers could read PDF and Flash capably. In fact, the screen reader used by the applicant was capable of reading both PDF and Flash. The points above indicate that most screen readers can’t read PDF or Flash, but it is more accurate to say that most can, including JAWS, Window-Eyes, NVDA, and others. Adobe provides a “read out loud” feature in Adobe Reader that provides basic access to PDF documents, but most users who are blind will depend on a more full-featured assistive technology.
This is not to suggest that the applicant didn’t encounter challenges, she clearly did. Authors of HTML web pages, as well as authors of PDF documents and Flash content need to make sure that they follow accessibility standards, and if authors don’t, users suffer.
We have techniques available for complying with WCAG 2.0 when authoring Flash, HTML, and techniques for PDF are in the works (there are training resources available for PDF at Adobe’s accessibility site in the meantime). The information that authors need is available, this ruling will undoubtedly stimulate an increased interest in these sources of information.
Adobe is committed to helping authors comply with accessibility requirements, whether using HTML, PDF, or Flash. Here’s a few links to relevant information:
- Dreamweaver (HTML authoring): http://www.adobe.com/accessibility/products/dreamweaver/index.html
- Acrobat (PDF authoring): http://www.adobe.com/accessibility/products/acrobat/
- Flash Professional (Flash authoring): http://www.adobe.com/accessibility/products/flash/
The Adobe Digital Publishing team released updates yesterday – Adobe Content Server 4.1 and Reader Mobile 9.2 SDK. Of primary significance to accessibility, Content Server includes a new permission setting for Text To Speech which will provide the ability to indicate if a book can be voiced by a ‘Read Out Loud’ feature of a ebook reader.
Access technologies for people with disabilities use TTS, but this is considered a different case, and the upcoming Digital Editions 2.0 will provide the ability for assistive technologies that utilize the operating system’s accessibility API (e.g. screen reading software such as Window-Eyes, JAWS, VoiceOver, or NVDA) to read book content whether the TTS permission is enabled or disabled. This ensures that print-disabled users have the same fundamental access to eBook content as non-disabled users. However, devices with ‘Read Out Loud’ functions not dedicated to the support of people with disabilities are expected to honor the TTS permission’s setting.
More information about the release of Adobe Content Server and RMSDK 9.2 is available from the Adobe Digital Publishing blog.
Yesterday Reader X was released and with it a new feature for security sandboxing. I want to alert assistive technology users to some implications of this feature, as they may be affected if they are using Windows XP.
Sandboxing works without issue for assistive technology users with Windows Vista or Windows 7. Your version of Reader will install with Protected Mode enabled and you don’t need to do anything different to read or interact with PDF documents.
Windows XP users who use assistive technology have a little different situation. When one of these users opens a PDF file they will get an alert that indicates the following:
“Adobe Reader has detected that you may be using Assistive Technology on your computer. While using Adobe Reader with Protected Mode enabled on Windows XP operating systems, some Assistive Technologies may not be able to read some document content. If you do encounter problems, turning off Protected Mode may help. This can be done by choosing Edit > Preferences > General and unchecking Enable Protected Mode at startup.”
What this means is that some assistive technologies are not able to navigate the security sandbox. So, as an assistive technology user, you should first check to see if you are able to access PDF content with your AT – JAWS and Window-Eyes users will need to disable Protected mode in the Reader preferences. There are many assistive technologies and many possible system configurations, so we encourage you to try for yourself. For an accessible PDF file to try, here is a simple test PDF file. Feel free to post your results as comments.
Update: This post initially indicated that Window-Eyes 7.2 was able to read in protected mode, but I received incorrect information on this point and was corrected by contacts at GW-Micro. The key issue is that the sandbox blocks COM interfaces, which includes current accessibility APIs, so it does make sense that Window-Eyes doesn’t work within Protected mode on XP.