My name is Larry Waldman -- I am a Program Manager on the Office User Experience team and have been working in this role to make Office more accessible for almost 5 years. When users of Office hear that Microsoft has many people working specifically to make our products more accessible to people with disabilities, many express surprise. With such a broad customer base, we recognize the importance of considering accessibility impact in every feature we build. For example, check out this article I wrote about Accessibility and the Ribbon in Office 2007.
Upon starting our research for the 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. Not only are accessibility improvements garnering increasing attention from governments, but 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:
Providing detail on all of Office 2010’s accessibility improvements can’t be done in a single blog post, so I’m going to focus today’s discussion on Office 2010’s new document Accessibility Checker feature. I’ll end the post with a few high level bullets of other accessibility features that we might discuss in the future.
While user interface accessibility has been well understood for years, the accessibility of Office document content is a burgeoning new area. In particular, we’ve seen many requests from companies and governments who have been wondering how to help their employees create accessible content. To solve this problem in Office 2010 we created a document Accessibility Checker (like a spell checker, but for accessibility issues) as a core feature of Word, Excel, and PowerPoint.
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:
Based on these three categories, we came up with a set of issues our checker looks for (described in more detail below) – when presented to the user, they are bucketed into “Errors”, “Warnings”, and “Tips” – these buckets correspond to the above three descriptions.
One of our key principles for Office 2010’s 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 Info place, accessibility information will be provided under the Prepare for Sharing header. Prepare for Sharing is described more generally in this Backstage view blog post, but this is the place in the UI where authors go to ensure their file is ready to be shared with other readers; they can check for hidden information, metadata, and now accessibility issues.
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.
The task pane has two main UI sections.
The top section is a tree view control (with each tree item navigable via arrow keys). Each “violation type” (missing alt text, no table header row, repeated blank characters, etc…) is an item that is collapsible.
When showing, each violation type contains one or more violations – these are represented to screen readers as children of the parent “tree items”. Each leaf is key focusable. For example, if you have two pictures that are missing alt text, they will be two violations under the “Missing Alt Text” node – each can be selected. When a violation is selected, the document will scroll to and select the problematic content.
Where possible we try to name each violation with a meaningful name (for example “Picture 1”) – And in PowerPoint or Excel you’ll find that we also try to provide what slide/sheet the object is on. Note – the violation types are grouped into “Errors”, “Warnings”, and “Tips” – These headers separate the tree items in the view, but they are not collapsible themselves. The group headers are also not key focusable.
When you select an issue in the top part of the pane, the bottom of the task describes how and why to fix it. Just above this bottom section is an “expand/collapse chevron” that allows a user to collapse the bottom pane.
All of the text in the bottom pane section is represented to a screen reader as one big pane with static text. When focus is on the pane, it can be scrolled using ctrl+up/down and pageUp/pageDown. Finally, there is some explanatory text and a more info link at the bottom of the pane if users need more help.
When Office 2010 ships there will be full documentation provided that details each violation the checker will scan for. In the meantime, here is a quick list of what we check for in each Office application – you can download the Beta and try out the Accessibility Checker with your files to see more details for the issues your content has. The top box for each application contains Errors, the middle contains Warnings, and the bottom contains Tips.
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 this release, please feel free to leave us a comment on this post and let us know things you’d like us to consider for the next version.
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 their users.
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.
While this post has drilled deeply into the new document accessibility checker, here are a few other highlights we’ll be considering blogging about in the future. Feel free to leave comments and we’ll be sure to drill into what you’re most interested in.
The release Office 2010 is groundbreaking on many levels. Not only are we delivering features to users that provide a great accessibility experience across the PC, the Web, and the Phone, but we have continued to enhance our platform interoperability and commitment to AT Vendors. Hopefully this look at accessibility is useful – please let us know via the comments if you have questions or would like more information on a particular topic.
Larry Waldman, Program Manager, Microsoft Office
Update: Nick Simons just blogged about accessibility and the Office Web Apps. Check it out at http://blogs.msdn.com/officewebapps/archive/2010/01/18/9949907.aspx.
Another update: Diana Kimball just published a quick blog about accessibility and PowerPoint. Check it out at http://blogs.msdn.com/powerpoint/archive/2010/01/26/behind-the-scenes-accessibility-in-powerpoint-2010.aspx.
I wanted to know if there are any updates to the other questions that I posted earlier?
Any information on what Office 2010’s built-in Save as Accessible PDF supports for the tagged PDF rendered compared to Adobe Acrobat word plug-in?
Are there any plans to make a Save as DAISY for PowerPoint?
@sogami - Sorry for the delay. We are currently evaluating what our next version of Save as DAISY should take on and PowerPoint is certainly being considered but nothing is finalized.
The project site on source forge is the best place to log all bugs. Also, please feel free to share them here on the blog.
We'll respond to your PDF question shortly.
We haven't currently done any feature by feature comparison with Adobe Acrobat's tagging capabilities, but if such a comparison would be helpful, we can consider looking into it in the future.
Tagging has not changed substantially in Office 2010 from what was provided in Office 2007. We've made updates to support new features, as well as making selected fixes to the existing behavior. If you'd like me to provide an overview of our tagging support in general, I can address this in an additional blog post.
Janet Schorr [MSFT]
@Siddhartha -- This is not the appropriate blog post for general questions. As mentioned above, please use the newsgroups or other related blog posts for that.
However, I did check -- assuming you mean the Windows Live Mail desktop application (as opposed to the web client), it should work with Office 2007 and Office 2010 as long as the Mail application is registered as the default e-mail client. With Office 2007 you may run into an error a few times due to a bug that we later fixed, but if you keep dismissing the error and trying again it should eventually work.