Office Web Apps Accessibility

One of my core responsibilities during the development of Office Web Apps has been to ensure that the apps are accessible to people with disabilities. 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.

There are a lot of regulations (such as Section 508 of the Rehabilitation Act) and guidelines that pertain to making both software and web sites accessible. These standards and regulations are in place to ensure that software developers take the needs of all users into account. However, compliance with these standards is a means to an end; it is not our goal. Our goal is to make our products accessible to as many people as possible. I personally find it hard to get passionate about regulations. I am, however, a passionate advocate for the people who will be using Office Web Apps.

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:

• Enable screen reader support for people who can't see the screen.
• Ensure that all functionality is keyboard accessible for people who don't use a mouse.
• Ensure that we are functional in high contrast and high DPI modes for people who rely on these mechanisms to see the screen.

Screen Reader Support

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 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 even though they can't see them. There are several technologies that software developers can employ to make their software easier for a screen reader to interpret. However, when creating software using HTML and JavaScript the support for screen readers is less developed.

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, OneNote Web App and Excel Web App are XHTML Strict compliant and use CSS for layout (the PowerPoint Web App and Word Web App viewer use images – our accessibility solution for these is described below). We pay close attention to our use of HTML elements such that elements are primarily used based on their semantic value as opposed to how they function or appear. For example, tables are used to organize tabular data as opposed to layout.

Another important new technology we used to provide screen reader support is ARIA (Accessible Rich Internet Applications). 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.

The PowerPoint Web App and Word Web App viewers render documents using images (or Silverlight if it is installed). Content that is presented as an image presents a challenge when making software accessible because screen readers can’t “see” the image. To get around this it is important to provide a text-based version of the file that has both the text and the structure of the content represented in the image.

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.

For Word documents we provide the ability to open the document as a tagged PDF. This allows people to use a PDF viewer that is compatible with their screen reader to read the Word document. We considered several options here before choosing PDF. These included an HTML view of the document and XPS. Ultimately we chose PDF because we wanted to use a standard format that would retain the richness of the document without requiring that the user has 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.

Keyboard Accessibility

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. 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. For example, in OneNote Web App there is a ribbon, a nav pane on the left and an editing surface for content. CTRL+F6 moves between these areas.

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).

For a broader look at Office accessibility check out Office 2010: Accessibility Investments & Document Accessibility.

Nick Simons
Program Manager, Office Web Apps