August 28, 2013

Open-source accessible mega menus

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.

5:02 AM Permalink
June 25, 2013

What is PDF/UA all about, anyway?

The PDF/UA (“Universal Accessibility”) specification, or ISO 14289, published by the International Organization for Standardization (ISO) in August of last year, was a big step forward for authors of the tools we use to create and consume PDF content. But what the spec itself does is a little harder to explain, and there’s been a lot of confusion. I even confused myself recently about what PDF/UA does and doesn’t specify. So I thought it might help to summarize the spec in some detail for those who are coming to grips with its place in the world of PDF accessibility.

If the PDF/UA specification could be summed up in one sentence, it may go something like this:

“PDF/UA makes certain that the PDF format isn’t the source of accessibility problems.”

The end result of a document built using the PDF/UA spec is a more reliable, more accessible document that avoids the tricks and traps that PDF can present. PDF authors don’t need to know anything specific about what goes on behind the scenes; the tools themselves are responsible for adding and preserving the accessibility of the PDF. That’s the value of PDF/UA.

That does not mean that a PDF/UA-compliant document will always be perfectly accessible—issues like poorly-built Word documents or other source material will, of course, carry their accessibility flaws no matter what format they’re converted into. No one should claim that PDF/UA conformance means that a given document will pass the Web Content Accessibility Guidelines (WCAG) 2.0, and organizations shouldn’t treat PDF/UA as a WCAG stand-in. But conformance does indicate that the authoring process for a given piece of content retains its accessibility level when it’s output as a PDF.

The PDF/UA specification defines conformance for three different aspects of PDF: content, readers, and assistive technology. The authoring tools are intentionally omitted: only the content they produce matters here, and that can only be measured at the individual document level.

We’ve seen a number of organizations that are specifying PDF/UA-compliant documents, and that’s a worthwhile approach, as far as it goes. The revamped accessibility checker in Adobe Acrobat Pro XI bases its tests on PDF/UA and WCAG criteria, but doesn’t yet fully test PDF/UA compliance.

The PDF/UA document itself is 23 pages, and thanks to ISO’s publishing model, it’s about $90 US to purchase a copy. We’re sensitive to the cost issue here, but in the interest of full disclosure, Adobe doesn’t own this work (it was the product of participants from a number of companies, and its copyright belongs to ISO), so we’re not able to simply republish the spec. To those who are planning to implement PDF/UA in their readers and assistive technologies, $90 is not a barrier (and if you promise to implement PDF/UA in an open-source tool, I’ll buy you a copy myself, though I’m sure I’d get the better end of that deal).

The material is what we in America call “inside baseball”—it’s very technical, requires a solid understanding of PDF internals, and is heavily cross-referenced with ISO 32000-1:2008, the PDF 1.7 specification. For non-technical authors looking to create accessible PDFs, this spec is very technical; you may be better off looking at the PDF Techniques for WCAG 2.0. However, I’ve taken the liberty of summarizing this spec so that everyone has a chance to understand what conformance entails.

The spec starts by listing what PDF/UA does not do: help with converting paper or electronic documents to PDF/UA; give implementation advice for rendering PDF documents; or tell you how to store PDFs or what OS to use. The rest of the front matter includes normative references to WCAG 2.0, PDF 1.7, PDF/A-2, and PDF/X-1a; defining a handful of terms; and setting a namespace for PDF/UA metadata which goes into every conforming file.

The document then defines conformance at three levels: individual files, PDF readers, and assistive technology.

Conforming files

A conforming file contains features that are valid according to the PDF 1.7 spec, except for features PDF/UA specifically forbids. It has to be marked as a PDF/UA document as described in Section 5, and meet all the requirements in Section 7 below.

Conforming reader

A conforming reader must also be a conforming reader according to PDF 1.7. It will support all the tags, attributes and key values specified for accessibility, and respect when optional content is hidden. It will make the logical reading order available. It will allow AT to inspect artifacts, and its interface must itself be accessible, and not interfere with any AT feature.

There are some repair techniques for headings and tables, rules for handling optional content, attached and embedded files, digital signatures, actions, metadata, navigation, annotations, forms and media.

Conforming assistive technology

A conforming AT supports all of the features of the content and the reader, and should allow navigation by page labels, document structure, or the outline. It should also let the user override default navigation zoom. (A combined reader and AT, perhaps something like TextHelp’s PDF Aloud, could be both a conforming reader and a conforming AT.)

File format requirements

This is the meat of the spec, and there’s some good advice in here for those of you who are already well-versed in tagging PDFs.

All PDF/UA documents must be tagged PDF. Tags must be semantically appropriate (that is, you can’t just mark everything <p> and be done), and in logical reading order. Artifacts (sometimes referred to as “Background” in Acrobat) must not be tagged. If a PDF does anything non-standard with its tags, those tags have to be remapped to standard PDF tags. Standard tags can’t be overridden.

Content can’t flicker, blink or flash, and it can’t be conveyed solely by color, contrast, formatting,  layout or sound. Image-only PDFs may be created, but their content must also be tagged.

The document must have a title, and it must be displayed in the title bar.

Text must be Unicode. The document’s language, and any changes in language, must be declared.

Graphics must be marked up with the Figure tag, and must have alt text, unless it’s presentational, in which case it’s an Artifact. Groups of images that represent one thought are to be tagged as a single Figure. Captions that go with figures must be tagged as such.

Headings must be nested sequentially (e.g., H1-H2-H3 is acceptable, but H1-H3 is not). Headings can go as deep as necessary (e.g., H1041 is valid, if you’ve used the first 1040 levels). Generic “H” headings are acceptable, but can’t be used interchangeably with numbered headings.

Tables should have headers (“TH” tags) with a Scope attribute.

Lists must be marked up appropriately.

Math equations must be in a Formula tag, with alt text.

Page headers and footers must be marked up as Pagination artifacts, so they’re not read out repeatedly.

Footnotes and endnotes must be marked up with the Note tag.

All optional content configuration dictionaries (a PDF feature which allows content to be hidden conditionally) must be named.

Any embedded files must also be accessible.

Article threads (which allow multicolumn layouts across pages) must retain proper reading order.

Digital signature form fields must be laid out accessibly.

Non-interactive forms have to be tagged with PDF “PrintField” attributes so they will appear as read-only form fields to AT.

Static XFA-based forms are allowed. Dynamic XFA forms are not.

Secured documents must allow AT access.

Documents should have outlines that reflect the reading order and nav hierarchy.

Visible annotations must be represented in the right place in the reading order.

Tab order must be defined.

Links must be tagged, and contain an alternate description.

Metadata tags must be properly set for embedded media.

Actions (i.e., scripting) are allowed. Changes in content or focus must be announced to AT, and cannot set time limits on individual keystrokes.

There are requirements for the implementation of fonts that are well out of scope for an overview, but important for reliable rendering of fonts across operating systems and reader implementations.

Conclusion

So, that’s it. We’re hoping a little transparency regarding PDF/UA helps everyone understand what it does and doesn’t do. In time, we anticipate that PDF/UA will make accessible authoring a more automatic and uniform process across authoring tools, which in turn will make the accessibility of PDFs in the wild a lot better in general.

1:45 PM Permalink
May 31, 2013

Mega menu accessibility on adobe.com

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.

The adobe.com mega menu, with an item selected by keyboard

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.

7:01 PM Permalink
March 21, 2013

Slides from CSUN 2013 presentations

Here are PDF versions of our presentation slides from the CSUN 2013 conference:

6:06 PM Permalink
March 7, 2013

Andrew Kirkpatrick to Co-Chair WCAG WG

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.

8:39 PM Permalink
February 20, 2013

Adobe & CSUN 2013

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.

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.

2:15 PM Permalink
February 1, 2013

Adobe & Greg Pisocky: 20 Years

Today we celebrate the 20 years of service at Adobe by accessibility team member Greg Pisocky. If you’ve ever worked on making a PDF document accessible chances are you’ve read or used resources Greg helped develop, and many of you are lucky enough to have worked have worked more closely with him. Greg has worked on accessibility at Adobe since the late 90’s, and through his work on Adobe’s government sales team was instrumental in the introduction of accessibility into Adobe Reader and Adobe Acrobat. Accessibility was introduced as a feature in Adobe Acrobat 5.0 in May of 2001, and Greg’s work with our customers and the Acrobat engineering team helped make this work happen.

Since then, Greg has advocated internally for improvements and worked with external customers to promote the use of the accessibility features in Acrobat, helped countless end users with disabilities understand the accessibility support features available in Adobe Reader and other Adobe tools, and contributed substantially to efforts to help other tools such as Adobe InDesign and Adobe FrameMaker create accessible content. Greg has also worked for many years to make the PDF/UA accessibility standard for PDF documents a reality, contributed to the Authoring Tools Working Group at W3C-WAI, and engaged with the Section 508 refresh committee (TEITAC) on behalf of Adobe.

Comments from colleagues and customers speak volumes about Greg’s impact.

Victoria Richards, Government Customer
I met Greg Pisocky for the first time at an IDEAs Accessibility Forum in Washington DC. I immediately appreciated his extensive knowledge about the issues and his honesty about the ability and limitations to solve accessibility problems. Greg was instrumental in giving me a voice with the Adobe Acrobat team. He is an invaluable source of knowledge and ideas which have greatly improved the workflows to create accessible PDFs. Greg, thank you for helping me improve the products I create for people with visual impairments.

Noha Edell, Sr. Solutions Consultant, Adobe Systems Inc.
Greg Pisocky, a juggernaut of the movement of accessibility, a quintessential liaison between customers, product management, and engineering, and a relentless advocate who dedicates his life to improve the lives of the less fortunate. Greg understands the importance of accessibility and the needs of the customers working with it. His steady contributions to the products teams helped propel Adobe’s advancements in accessibility across products. Happy 20th Anniversary, Greg, it is an absolute honor to work with you.

Duff Johnson, Chair of the US Committee for PDF/UA
Greg led the charge on PDF/UA since the beginning, and showed me the ropes of tagged PDF. Greg combines a gentle demeanor with a fierce passion for accessibility and for his work. Every government agency in DC owes much of its successful use of Acrobat to Greg Pisocky.

Loretta Guarino Reid, Adobe Acrobat Engineer (emerita)
Greg Pisocky was one of the earliest champions of PDF accessibility at Adobe. He was a great partner to accessibility engineering, helping us to understand the needs and priorities of our government customers, and giving them information about new accessibility features in Acrobat. I loved working with Greg and I’m grateful for his part in the PDF accessibility story.

Those of us on the accessibility team appreciate Greg’s knowledge and valuable contributions – thanks Greg, and congratulations!

12:08 PM Permalink
January 29, 2013

Adobe Edge Inspect adds accessibility support

Accessibility takes many forms. While many if not most people have a fixed concept of accessibility that revolves around screen-reader compatibility with published content, the reality is that each product, be it an application, a document, a device or a protocol, has its own capabilities and limitations. And when we review our product teams’ work, sometimes we find unexpected ways to improve the user experience for people of all types.

A recent example is one of our newer products, Adobe Edge Inspect—one of a host of apps we’re working on to make HTML-based development easier for developers, designers and testers. Edge Inspect has three components: a desktop application that runs in the System Tray on Windows or the Menu Bar on OSX, which connects mobile apps running on iOS and Android to a Google Chrome extension, allowing testers to browse and debug the same mobile site across numerous devices simultaneously. It’s one of those apps that you don’t know you need until you know you could have it.

When I saw this demo last year, once I picked my jaw up off of the floor, I grabbed their demonstration iPad and turned on VoiceOver, the screen reader that’s built into iOS. This is usually how I shame mobile engineers. (Who says accessibility people can’t have hobbies?) But to my surprise, most of what was there already worked. Before they’d done any custom work, the Edge Inspect team had built a tool that would let me test mobile accessibility use cases alongside the visual layout.

Adobe Accessibility’s Michael Jordan worked with the Edge Inspect team to complete the job, both by tying up loose ends (like naming buttons and ordering controls), and by introducing accessibility features into the Chrome extension. That work is shipping in the latest version of Edge Inspect—which, by the way, you can get just by signing up for a free Adobe Creative Cloud account.

It’s important to remember that it’s not just the end user of a mobile site who may have a disability; your developers and testers may make use of that support as well. We talk a lot with our colleagues at all levels within Adobe about the role accessibility plays in what we create, and how people build upon our work. We can talk about how this or that is required by law, or by policy, but sometimes, as with Edge Inspect, we find a great opportunity to expand both the audience and the capabilities of a tool, with just a little polish. We have even more improvements coming soon, but more importantly, by working together, we have another product team that’s taking a broader view when it comes to designing for their users.

6:07 AM Permalink
January 14, 2013

Free Webinar: “Exploring Electronic Document Accessibility”

Adobe is offering a free webinar on document accessibility in conjunction with SSB BART Group and FedInsider News. The webinar will take place Wednesday January 23, from 1:30-2:30 (US eastern time zone).

Jon Avila from SSB BART Group will lead the session which will target managers and content authors in addressing the following topics:

  • Overview of accessibility requirements relevant to document creation.
  • Guidance on how to analyze known problems in existing documentation.
  • Proper use of native document creation software.
  • Techniques for finding and fixing accessibility violations.
  • Best practices to maintain and update document creation processes to ensure ongoing accessibility.

You can read a more information about the webinar and register at http://solutions.adobe.com/?elqPURLPage=114. Please join us for this event!

Update: I neglected to mention it, but the webinar will have live captioning.

Update: The webinar recording is available.

9:00 AM Permalink
January 3, 2013

Acrobat XI Accessibility Documentation

On behalf of the Adobe Accessibility team, I’d like to welcome you all to 2013. We’ve got a big year ahead of us, and we’re starting with some new documentation for Acrobat XI.

We’ve updated our Acrobat accessibility training resources page with four new PDFs:

PDF Accessibility Overview
Covers the accessibility features of PDF as a document format, as well as Adobe Acrobat and Adobe Reader.
Using the Acrobat XI Pro Accessibility Checker
A complete walkthrough of Acrobat XI’s Accessibility Checker, as well as the Make Accessible action wizard.
Acrobat XI Pro PDF Accessibility Repair Workflow
Walk step-by-step through the PDF accessibility process in Acrobat XI.
Acrobat XI Pro Accessible Forms and Interactive Documents
Create interactive forms that can be used by anyone, ensuring privacy and independence for all.

We’ve also created a Acrobat XI accessibility best practices document which contains all four of the above guides in a single file. Documentation for Acrobat versions 8 and up can be found on the training resources page as well.

The new features of Acrobat XI are intended to make creating PDF documents both easier and more automatic. The Make Accessible action wizard walks users through a number of steps, like running optical character recognition and prompting for alternate text on images, and then tests the final product. This makes the process for editing and testing for PDF accessibility a fast, uniform process for authors of all skill levels. The built-in accessibility checker has also been improved, including testing support for the Web Content Accessibility Guidelines (WCAG) 2.0. We think this is the most substantial improvement in Acrobat accessibility since we added support for assistive technology back in 2002.

The team is looking forward to giving a detailed Adobe Acrobat XI walkthrough at the 28th Annual International Technology and Persons with Disabilities Conference on February 28th, and at other conferences throughout the year. We hope you’ll find these tutorials useful.

5:31 AM Permalink