Producing Accessible Documents with Microsoft Word 2010 (Web App)
Detailed Content
Upon starting our research for the Office 2010 release, we knew it was important to continue our accessibility focus (see Microsoft Accessibility for more info) and ensure that Office 2010 is the most accessible version of Office ever. Accessibility aims at offering the benefits of the technology to the greatest number of people and at reducing as much as possible obstacles and gaps in the various resulting user experiences. As such, accessibility improvements provide broad usability improvements and as such are becoming a key area of focus for the software industry in general.
With that in mind, we planned Office 2010 with two key accessibility pillars:
1. Improve Office’s interoperability platform to make it easier for assistive technologies (like screen readers for example) to build features for their users. This includes our forthcoming Web versions;
2. Provide several easy-to-use, powerful features built directly into the product that ensure users around the world are able to reach their full potential.
In order to illustrate some of the Office 2010’s accessibility improvements, this presentation focuses on producing accessible documents with Word 2010, demonstrates in this context the new document Accessibility Checker feature as well as some accessibility features of the Office Web Apps that are the Web versions of the productivity Office 2010 tools, and more specifically the Word Web App.
Word 2010 Accessibility Investments & Document Accessibility
Understanding Document Accessibility
While user interface accessibility has been well understood for years, the accessibility of Office document content is a burgeoning new area. In particular, in response to the many requests on how to create accessible content, we introduce in Word 2010 (as well as in Excel and PowerPoint) a document Accessibility Checker (like a spell checker, but for accessibility issues) as a core feature.
We started by examining the most common accessibility problems in Office documents and bucketing them in terms of their severity – we ended up with three categories:
1. Issues where content is unreadable. For example, a picture missing alternative text (alt text provides a text based representation of an image) is unreadable to a person who is blind.
2. Issues where content is difficult to read. In general, these issues are less severe than unreadable content – for example, if an author has created a data table and used complex formatting to alter its presentation (i.e. using blank rows or columns, or merged and split cells), then a person with a disability might have difficulty understanding content in the table.
3. Issues that may or may not make content difficult to read. In our explorations, there were a set of issues that potentially cause users with disabilities difficulty for which we don’t have a high confidence, automatic way to determine whether the issue is really a problem. For example, knowing whether or not the reading order of objects on a slide or cells in a layout table is optimal for a particular reader falls into this bucket.
Based on these three categories, we came up with a set of issues our checker looks for when presented to the user, they are bucketed into “Errors”, “Warnings”, and “Tips” – these buckets correspond to the above three descriptions.
When Office 2010 ships in June, 2010, there will be full documentation provided that details each violation the checker will scan for.
In the meantime, we have published a white paper that explains how to create accessible documents with Word 2010, and covers the use of the aforementioned Accessibility Checker with the .docx files and provides a quick list of what we check for in Word 2010. As of writing, you can download the Beta or the Release Candidate version and try out the Accessibility Checker with your files to see more details for the issues your content has. While we’ve tried to include as many accessibility issues as we can for Office 2010, we do recognize that there are still accessibility issues we don't yet check for. If you have a particular issue that didn’t make it into these bits, please feel free to let us know things you’d like us to consider for the next version. The white paper also concludes with file conversion into other formats like the DAISY XML (DTBook DTD) or Full DAISY format with the Open Source DAISY Translator for Open XML we co-develop with Sonata Software Ltd. and the DAISY consortium.
Furthermore, as part of our documentation process we’ve provided Assistive Technology Vendors with details about how they can use the Office accessibility platform (including our Object Model) to ensure they optimally read back Office content for the users.
Using the Accessibility Checker
One of our key principles for this accessibility checker was to make the feature available out of the box for all users – in a way that’s integrated with the authoring workflow. Rather than force users to remember to run the accessibility checker before sending a document, we integrated accessibility results directly into the Backstage view. Anytime you click the File tab and view the Information place, accessibility information will be provided under the Prepare for Sharing header.
To receive more detailed information (including what issues were found, why they are issues, and step-by-step instructions as to how to fix each one), users can click ‘Check for Issues’ and then click “Check Accessibility”. This will close the Backstage View and open a task pane so you can interactively find and fix the issues in your document. In addition to the screenshot below I’ve provided a detailed textual description of how to use the checker and how its UI is represented to screen readers.
For organizations that are concerned about compliance for employees, we’ve provided several group policy settings that can be used to customize exactly which accessibility violations are checked. Administrators can also increase the visibility and emphasis of the Prepare for Sharing information when there are errors or warnings. Finally, IT departments can leverage Office 2010’s UI extensibility to enforce a workflow that requires users to run the checker – this will help many corporations reduce the risk of employees creating inaccessible content and increase the amount of accessible information available to people with disabilities.
Extending Accessibility & the user expereiences with Word Web App (editor and viewer)
Given that the Office Web Apps are Web versions of productivity tools our primary focus is on supporting people who are blind, people with reduced vision, and people with limited mobility. Indeed, one of the core commitments during the development of Office Web Apps has been to ensure that the apps are accessible to people with disabilities.
Achieving WCAG (Web Content Accessibility Guidelines) 2.0 AA conformance has been a key tenet of the development of Office server products, including the Office Web Apps, SharePoint Server, and other tools. Notably, when we approached the task of making Office Web Apps accessible we identified several core user goals. These are the three where we invested most heavily:
1. Enable screen reader support (or other assistive technologies) for people with disabilities;
2. Ensure that all functionality is keyboard accessible for people who don't use a mouse;
3. Ensure that we are functional in high contrast and high DPI modes for people who rely on these mechanisms to see the screen.
The rest of the presentation illustrates how these goals Word Web App editor and Word Web App viewer.
Supporting Screen Reader (or other assistive technologies)
A screen reader is software that interprets the visual output of a computer and presents that output in a non-visual way such as speech and/or Braille. This task can be very complex because the screen reader has to present interactive controls in a way that allows people to use those controls. There are several technologies that software developers can employ to make their software easier for a screen reader to interpret. As such, we focus on two key strategies for providing support for screen readers.
The first is careful use of HTML. The Word Web App editor uses both well-formed Strict XHTML and CSS for layout (while the Word Web App viewer use images – our accessibility solution for this is described below). We pay close attention to our use of XHTML elements such that elements are primarily used based on their semantic value as opposed to how they function or appear.
Another important new technology we used to provide screen reader support is WAI-ARIA (Accessible Rich Internet Applications). WAI-ARIA is an initiative of the W3C aimed at providing more robust mechanisms for exposing web application functionality to screen readers and other assistive technologies. The goal is to provide an experience that is comparable to a fully accessible desktop application. We have included ARIA markup in Office Web Apps so that browsers and screen readers that support the ARIA standard can provide a much clearer interpretation of our interface.
As mentioned above, the Word Web App viewer renders Word documents using images (or Silverlight if it is installed). To make perceivable by screen reader content that is presented as an image, it is important, as everyone should know, to provide a text-based version that truly reflects the content represented in the image. In this context, we considered several options. These included an HTML view of the document and XPS. Ultimately provide the ability to open the document as a tagged PDF because we wanted to use a standard format that would retain the richness of the document without requiring that the user has for example Office installed.
Of course, if users have the Office desktop applications installed, these provide the most accessible experience. We have made it very easy to transition from the Office Web Apps to the Office desktop clients when they are available.
Other Office Web App viewers may follow other directions for the best possible relevance. As an illustration, for PowerPoint presentations, we provide a structured outline view of the presentation. This outline contains the text content of the presentation organized by slide. It includes list hierarchy and tabular data in simple HTML that a screen reader can interpret.
Navigating with Keyboard
Efficiency is key for someone who doesn't use a mouse. With this in mind, we worked hard to enable the right set of keyboard shortcuts for the easiest and smooth navigation. Familiar shortcuts from the Office desktop applications such as CTRL+B, CTRL+S, and CTRL+C all work as expected. Also, we implemented the CTRL+F6 shortcut to make it easier to navigate between different areas in the Office Web Apps.
Handling High Contrast and High DPI
High contrast mode changes the colors of the UI to a color palette that is easier for some people with reduced vision to see. High DPI (Dots per Inch) mode makes the UI larger. In most browsers this is now called “zoom”. The Office Web Apps work well in both high contrast and high DPI modes.
When supporting high contrast and high DPI modes success hinges on what you don't do more than what you do. We are extremely careful not to hardcode colors, pixel values and font sizes such that changes scale or to high contrast will be appropriately respected by our HTML. We did have to make some adjustment to some of the icons we use because they were not visible enough in high contrast mode.
One interesting challenge Web developers face is taking high contrast mode into account. There is no consistent way of detecting when a system is in high contrast mode from a browser. This means that we can't change the way we render our interface in high contrast mode, which meant we had to tread carefully since some HTML is not rendered at all in high contrast mode (for example, background images).