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.
Posts in Category "Uncategorized"
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.
We’re proud to announce our first Adobe Accessibility open-source product, Accessible Mega Menus. We’ve already written about the menus and how they came to be, and now they’re available to the public, under the Apache 2.0 license.
This is a port of the same code we use on adobe.com, and it combines great keyboard and screen-reader support with the kind of pixel perfection you would expect from a site like ours. We’re confident this will meet the needs of a wide range of sites, so we’d love to hear your feedback.
The Mega Menu homepage on GitHub is the place to read up on how it works. You can download Mega Menus from the repository, and you can file issues there as well. Or, if you want to contribute code, just make a pull request, and we’ll address it.
Editor’s note: Recently, the adobe.com site switched over to a using a mega menu for global navigation. Adobe accessibility engineer Michael Jordan worked closely with our web team to build a menu system that brings great accessibility to a very design-sensitive site. Here, Michael explains his approach.
While mega menus, in many flavors, are fairly ubiquitous these days, thanks in part to the thumbs up given to them by Jakob Nielsen in his 2009 article Mega Menus Work Well for Site Navigation, we had a hard time finding many good examples for accessibility.
We think our approach strikes a decent balance between user expectation for global navigation, keyboard navigability, and screen reader access, and we felt that others might find it useful if we shared some of the thinking that went into our choices.
Our first major decision in implementing our Adobe.com mega menu was to respect user expectations for global navigation. As an accessibility engineer, it’s tempting to want always want to implement the appropriate WAI-ARIA design pattern for the widget I’m developing. In this case, working on a menu, I looked to the WAI-ARIA Menu or Menu bar (widget) design pattern which describes the keyboard interaction and WAI-ARIA roles, state and properties for a list of links presented “in a manner similar to a menu on a desktop application.” This would seem to fit the bill, but it’s somewhat problematic when implemented in its entirety for global navigation.
The design pattern specifies that the menu be treated as a single stop in the tab order, after which the arrow keys move between the menu and submenu items. This is the way application menus behave in desktop applications, and it improves accessibility for keyboard users because only one tab key press is required to move from the menu to the next focusable element in the application. However, for global navigation, we feel that most users still expect to be able to tab to at least the top level links in the navigation, and that the discovery of a jump in focus from the second link in the site to the search input, skipping all other top-level navigation items, could be confusing and would require unnecessary explanation.
Our implementation permits tab focus on each of the six top-level menu items. When one of the menu items has focus, pressing the Enter key, Spacebar or Down arrow will open the submenu panel, and pressing the Left or Right arrow key will shift focus to the adjacent menu item. Links within the submenu panels are included in the tab order when the panel is open. They can also be navigated with the arrow keys or by typing the first character in the link name, which speeds up keyboard navigation considerably. Pressing the Escape key closes the submenu and restores focus to the parent menu item.
The menu bar design pattern defines WAI-ARIA roles, state and properties. Some of these are also problematic when used in global navigation. If we use role=”menu” for the menu container and role=”menuitem” for each of the links therein, assistive technology will no longer interpret the links as links, but instead, as menu items. It is common for users of assistive technology to use a shortcut command to open a list of links in a web page. This allows them to quickly find a desired link without hunting through all the other content on the page. It’s a killer feature. If we use role=”menuitem” on links within our global navigation, they will no longer show up in the list of links identified by assistive technology. Cue the sad trombone.
We also want to maintain the semantic structure of the submenu panels in our mega menu, our links are organized into lists and separated by headings. Omitting role=”menu” and role=”menuitem” for the global navigation seems the safer way to go.
We still make use of the WAI-ARIA properties aria-haspopup, aria-owns, and aria-expanded to indicate which top-level links open submenus, the relationship between a link and its submenu, and the current state of the submenu.
We hope you find this useful, and we welcome any suggestions or comments you may have on the global navigation mega menu or other accessibility-related issues with adobe.com.
It’s hard to measure the impact the W3C/WAI Web Content Accessibility Guidelines Working Group (WCAG WG) has had on web accessibility. The WCAG 2.0 standard is the basis for a growing number of policies worldwide, providing a common reference for web content that adapts to users of all levels of ability.
Andrew Kirkpatrick, Group Product Manager for Accessibility, has been offered and accepted the role of co-chair of the WCAG WG, along with Joshue O’Connor of the National Council for the Blind of Ireland. Andrew and Joshue will take the place of Gregg Vanderheiden, who has chaired the WCAG WG since its inception, and Loretta Guarino-Reid, who played a pivotal role shepherding WCAG 2.0 to its final status as a W3C Recommendation in 2008. Both Loretta and Gregg will continue to participate in the WCAG WG, and we at Adobe Accessibility extend our gratitude to them for their years of effort moving the field of accessibility forward.
Andrew’s role will include the rechartering of the working group, to define goals for the working group and the WCAG standard in the coming years, as well as to reflect its continued development of accessibility techniques and other supporting materials. Andrew would like to hear from people from all different backgrounds on how the WCAG WG can help advance web accessibility overall. Apart from his Twitter account, @awkawk, leaving a comment here is one way to reach him, or you can submit a comment to the WCAG working group via the online form.
It’s that time again. The Adobe Accessibility team will be at the 28th Annual International Technology and Persons with Disabilities Conference, better known as CSUN 2013, all next week. Here’s where you can find us.
- CVAA Compliance Using Adobe Tools with Andrew Kirkpatrick, Wednesday, 4:20pm, Edward CD, 2nd Floor
- Adobe Acrobat XI Walkthrough with Matt May, Thursday, 1:50pm, Del Mar AB, 3rd Floor
Andrew will also be a panelist on the Progress Toward an Accessibility Profession session, which will be on Thursday at noon in Mohsen AB, 3rd Floor, and should prove a robust exchange of ideas.
We don’t run a booth at CSUN, but we’ll be happy to meet with you all during and after our sessions if you have questions or comments about any of the products we make.
Adobe Digital Editions 2.0 is released and available for immediate download. This version includes major improvements for accessibility over Digital Editions 1.7, and is designed to provide greater access to both protected and unprotected electronic books in the EPUB format for Windows and Mac users.
Digital Editions 2.0 utilizes accessibility features on Windows and Mac OS to provide access for users who are blind or who have visual difficulties, including support for high contrast modes and support for resizing of book text. Digital Editions also offers keyboard support which is dramatically enhanced over version 1.7.
Screen reader users can use one of several tools to read books with Digital Editions. On Mac OSX VoiceOver support is provided, although one limitation at present is that book content can only be read one page at a time rather than as a continuous stream. On Windows, users can choose between JAWS, NVDA, and Window-Eyes. GW-Micro provides Window-Eyes support via an app – to get the app for Window-Eyes users should go to the Window-Eyes control panel, press ALT-A to get to the App Menu, and select AppGet. When the list of available apps is displayed, Digital Editions can be found in the “Program Enhancements” group.
Adobe Digital Editions supports books protected by Adobe’s DRM (Digital Rights Management) solution. This allows users to access books available from libraries which use the Overdrive service, as well as those books purchased from vendors such as Barnes & Noble, Kobo, Waterstones, and other booksellers.
Adobe Digital Editions 2.0 is free and available for download at http://www.adobe.com/products/digital-editions.html.
After many years of work and with contributions from individuals around the globe, the August 7, 2012 publication of ISO Standard 14289-1, better known as PDF/UA, marks one of the most significant developments in the evolution of the popular and widely used Portable Document Format (PDF). The publication and availability of PDF/UA will encourage the production of PDF files that are more consistently accessible to persons with disabilities.
Initially referred to as PDF/Access in 2004 by the AIIM standards committee, PDF/UA was conceived in response to the proliferation of PDF documents that were valid according to the PDF specification, but were insufficiently accessible to persons with disabilities. To meet the needs of the widest possible audience, the producers and viewers of PDF content needed a common standard.
The main PDF standard, ISO 32000, already defines the format’s accessibility features. What PDF/UA does is to clarify and demonstrate how those features should be used, for both producing and consuming PDF documents. As with the other PDF standards (such as PDF/A and PDF/X), ISO 14289 omits features of the PDF specification that are ill suited towards its purpose. Features of the PDF specification necessary for accessibility are mandated in PDF/UA even though they may be optional in the core PDF specification. Also, any features which are allowed in ISO 32000 but which inhibit accessibility are prohibited in PDF/UA.
It’s important to note that PDF/UA is neither a spec to measure PDF content, like the Web Content Accessibility Guidelines (WCAG), nor an everyday authoring guide. It focuses on giving developers of PDF authoring tools and viewers, as well as vendors of assistive technologies that support PDF, critical information on how to build and present PDF content more accessibly. The goal is to make accessible PDFs easy to author and use, however they are produced. While PDF/UA contains great information for authors on how to meet the needs of users with disabilities (and also to address most WCAG success criteria), much of that work should really be done by tools and read by assistive technology, so PDF/UA support will mean authors do less work and get more accessible content.
Over the last 8 years, Adobe has participated in the development of PDF/UA and we are integrating support for PDF/UA into our products. It’s important to us that our tools do what’s right to communicate effectively what authors intend.
Of course, this work extends beyond our own products, and so we’ve been supporting the open-source NVDA screen reader project to include support for PDF/UA and other PDF and Acrobat/Reader-related features as well.
If you want to follow the further developments of the standard or even participate, please see AIIM’s PDF Standards page.
If you are interested in PDF accessibility and PDF/UA, here’s two suggestions for you to learn more:
- View our training materials for Acrobat and PDF accessibility. These resources offer information about how to use Acrobat to produce or repair PDF files for accessibility. WCAG Techniques for PDF are also available and provide useful information for authors looking to meet WCAG 2.0.
- Check out the PDF/UA standard. The document itself can be purchased directly from ISO (You don’t have to buy this standard if you just want to author accessible PDF files. However, you should encourage authoring tool makers, PDF viewer makers, and AT vendors to buy it, read it, and support it.)
The United States District Court in Massachusetts ruled June 19 on a motion to dismiss a suit brought against Netflix by the National Association of the Deaf (NAD) and others. The suit is about Netflix not providing enough captions for videos delivered via the “Watch Instantly” site, but the ruling addresses the applicability of the Americans with Disabilities Act (ADA) for electronic accessibility in general, not just limited to access issues for users who are deaf or hard of hearing. The dispute on the applicability of the ADA to the internet and electronic media has been brewing for several years, with cases against the Metropolitan Atlanta Transportation Authority, Southwest Airlines, and Target all part of the long-term debate. While the charge of judicial activism has been leveled against this decision, supporting precedents seem to exist which support the judge’s ruling, and the Department of Justice’s statement of interest provides a clear view of the DOJ’s position in support of this decision. The implications of this ruling are significant, but also fit well within the context of additional policy work in the US and abroad.
A key issue which is core to the debate is whether a web site or any other internet-delivered service can be regarded as “a place of public accommodation”. In the Netflix case, the judge ruled that the website delivering movies to the customer qualifies as a public accommodation. Specifically, the judge indicated:
Netflix, which operates its website and Watch Instantly service through computer servers and the Internet, is a public accommodation subject to title III of the ADA, even if it has no physical structure where customers come to access its services.
Establishing electronic resources as a place of public accommodation means more than a requirement for captioning, it also means that other users with disabilities need to have access to the information and services provided. Electronic content can readily be made accessible to users with disabilities, whether the user is deaf, blind, unable to use their hands, or has a variety of other disabilities or combinations thereof.
A growing policy emphasis on accessibility
This ruling comes at a time when there is greater evidence of expanding support for accessibility globally as well as within the United States.
The court made reference to a Department of Justice effort to release policy guidance to clarify that the ADA does apply to electronic services such as the web – the DOJ issued an advance notice of a ruling on the 20th anniversary of the signing of the ADA. This update to the ADA proposed to apply the W3C WCAG 2.0 specification as the standard for accessibility, which includes requirements for video accessibility such as captioning. The court writes:
Contrary to Defendant’s unsupported assertions, the Department’s ongoing regulatory developments support that Netflix is a public accommodation subject to title III of the ADA. The Department is currently developing regulations specifically addressing the accessibility of goods and services offered via the web by entities covered by the ADA. The fact that the regulatory process is not yet complete in no way indicates that web services are not already covered by title III.
In addition to the DOJ effort, President Obama signed the United Nations Convention on the Rights of Persons with Disabilities (UNCRPD) and last month sent the Convention to the Senate to be ratified. In doing so, the US would be committing to “take appropriate measures to ensure to persons with disabilities access, on an equal basis with others, to the physical environment, to transportation, to information and communications, including information and communications technologies and systems” (UNCRPD, Article 9). Separate from the UNCRPD, the United States Access Board is preparing to release updated standards for section 508 of the Rehabilitation Act which will likely also align with WCAG 2.0 criteria, and the FCC recently published regulations for access to broadcast video (not including non-broadcast video, user-generated video, or theatrical movies), including regulations which address access to the video when delivered via the internet after or concurrent with the broadcast delivery.
Outside of the United States, 152 other countries have signed (and 115 have ratified) the UNCRPD, and efforts to expand existing and develop new policies are well underway.
Why do we care about accessibility?
It isn’t hard to find opposition to this ruling (1, 2), but the most important point remains – that people with disabilities deserve equal access to information and services, whether provided via the internet or in a physical location. Access equals opportunity and self-reliance, whether for a person seeking accessible educational materials to help prepare for employment, accessible video for entertainment and social connections with others, or access to necessary goods and services without needing to depend on the help of others to arrange or obtain them. Access leads to employment, and active participation in society. Accessibility has costs, although less when considered early in any process and less at scale, but whatever the costs of providing access, the cost of not providing it is in the long run greater for society.
No major web sites, applications, or mobile apps are perfectly accessible, including Adobe’s. But Adobe and many others are making continual improvements and pushing toward greater access. We’ve worked on not only our own products but on accessibility standards and policies in the United States and around the world, and continue to seek ways to enable our customers to support accessibility with greater ease and effectiveness on their part. There is more work to do, but we know why we’re doing it and are committed to continue working for equal access for all
Note: I am not a lawyer, so anything in this post that sounds like a legal interpretation should not be construed as actual legal advice, just as the considered opinion of an interested party.
Thursday, March 1 is Adobe Day at the CSUN Conference. We’ve got five sessions lined up, all in Elizabeth C (2nd floor):
- Acrobat X, with Greg Pisocky and Pete De Vasto, 9:20am
- Accessible e-books with Adobe Digital Editions with Kiran Kaja, 10:40am
- HTML Accessibility with Adobe Software with Michael Jordan and Matt May, 12pm
- Video and CVAA Compliance with Adobe Tools with Andrew Kirkpatrick, 3:10pm
- Adobe Town Hall with the whole Adobe Accessibility team, 4:20pm
There’s more to come. (Probably involving hors d’oeuvres.) But for now, mark your calendars, and we’ll see you in San Diego.