Office Application Accessibility Review: Google docs: Spreadsheet | Accessible Digital Office Document (ADOD) Project

Version
Date of Current Version: 16 February 2011
Latest Version (HTML): http://inclusivedesign.ca/accessible-office-documents/googlespreadsheet-review

Contents
Usage Notes
Review Results
Screen Reader Test 1. Accessing an Existing Test Document
Screen Reader Test 2. Creating a New Document
Acknowledgments

Usage Notes

Overview

At the time of testing (February, 2011), Google docs: Spreadsheet was found not to be very accessible using keyboard navigation. In addition, screen reader testing appeared to show important limitations.

Testing Details

Screen reader testing was performed on Firefox 3.6.13 using two popular screen readers for Windows 7, JAWS 11 and NVDA 2010.2.
Keyboard navigation testing was performed on Windows 7 using Opera 11.01.

Disclaimer

This document is provided for information purposes only and is neither a recommendation nor a guarantee of results.
If errors are found, please report them to: adod-comments@idrc.ocad.ca.

Review Results

This table summarizes the result of our reviews using the “ADOD Assessment Framework: Success criteria for assessing the accessibility of office application user interfaces”

ADOD Assessment Framework: Success criteria for assessing the accessibility of office application user interfaces	Result
[ADOD-Office-Applications-UI 7.1] Use all applicable operating system and accessibility standards and conventions that are important or essential to accessibility. The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications. ADOD Note: The Checkpoint is very general, and includes: Supporting relevant accessibility API(s); Web-based tools conforming to WCAG; Keyboard access; Providing keyboard shortcuts where recommended for a platform; Respecting platform settings (such as “high contrast” modes); and Providing documentation.	No. Screen reader support is confirmed by testing (see below). Not all features are keyboard accessible. Does not respect platform settings including Windows “high contrast” mode.
[ADOD-Office-Applications-UI 7.2] Allow the author to change the presentation within editing views without affecting the [office document]. This allows the author to edit the document according to personal requirements, without changing the way the document is rendered when published.	No. Does not have “Zoom” feature and does not support for Windows platform high contrast settings.
[ADOD-Office-Applications-UI 7.3] Allow the author to edit all properties of each element and object in an accessible fashion.	No. Not all features are accessible via keyboard shortcuts. Keyboard shortcuts do exist for some of the menu commands, but not for many others.
[ADOD-Office-Applications-UI 7.4] Ensure that the editing view allows navigation via the structure of the document in an accessible fashion.	No.
[ADOD-Office-Applications-UI 7.5] Enable editing of the structure of the document in an accessible fashion.	No.
[ADOD-Office-Applications-UI 7.6] Allow the author to search within editing views.	No. No “Find and Replace” feature.

Screen Reader Test 1. Accessing an Existing Test Document

In this test, the evaluator used a screen reader to explore a pre-existing test document that had been created by a sighted colleague, following the “Authoring Techniques for Accessible Office Documents: Microsoft Word 2007”. The test document included the elements in the left-hand column (i.e., heading, table of contents, etc.).

Able to Access?	JAWS 11
Image with “alt” text	No. However, the alternative text for the image was in the correct cell of the table, it was not reported as an image.
Data table	Yes.
Bar chart with “alt” text	No.
Formatted text	No. The text was available, but the JAWS text attributes command (JAWS key + f) did not report the proper attributes.
Cell with a note	No. The text in the cell was available, but it did not provide access to the note.
Search function	Yes. Using the standard JAWS search for a web page (control + f).

Screen Reader Test 2. Creating a New Document

In this test, the evaluator used a screen reader to create a new test document which was to include the elements in the left-hand column (i.e., two levels of heading, an image, etc.).

Able to accomplish?	JAWS 11
Add and then edit regular text (e.g. do a select-cut-paste)	Yes. It was necessary to find a cell in the table, to activate the cell (see section 3), to find the Formula edit field, to edit the text and press enter. The text did not always show up in the correct cell, and the formula edit field did not always appear. It was highly inconsistent.
Insert an image	No. After selecting Insert > Image… a dialog would sometimes appear and sometimes would not. When the dialog did appear JAWS was unresponsive to the point of not being able to navigate the dialog or easily switch between application / forms / virtual buffer modes.
Insert a 3-by-3 data table and fill it with content	No. See “Add and then edit regular text” (above), the inconsistency in adding text to the spreadsheet was too great.
Create a chart from a data table	N/A
Use text formatting (bold, text colour)	Yes. After activating a cell with text (confirmed by the text being present in the Formula edit field), use Format > Bold to apply a bold format. Attempting the same process with Text color appeared to do nothing other than to put focus in the Formula edit field. Confirmed by downloading the spreadsheet and viewing in Excel.
Save document	Yes. Using the Save Now button. It took more than one attempt for the dialog to come up in a form that was accessible. Navigating the dialog with tab gave slightly inconsistent results, but an edit field, Ok, and Cancel buttons were available.
Other Comments by the Screen Reader Tester:	When the spreadsheet loaded JAWS entered ARIA application mode. No amount of using the arrow keys to navigate appeared to announce any contents. After exiting application mode it was possible to find a table on the page that represented the contents of the spreadsheet. Unfortunately the row and column headers (cell coordinates) were in separate tables from the contents, so JAWS did not announce location while using standard table navigation keys. All results in section 1 are based on the static table, and not on the ARIA enabled editor. Activating a cell: Upon clicking on a cell in the table (JAWS key + 8), or pressing enter on a cell, the contents did populate a text field. Finding the Formula text field with the JAWS quick navigation key (e) provided the opportunity to enter forms mode. While in forms mode in the cell the value could be modified and pressing the enter key saved the value into a cell in the table. The value did not always appear to be entered into the correct cell; the Formula edit field did not always appear. There was a great deal of inconsistency. See also Google Apps accessibility documentation at http://www.google.com/accessibility/resources.html Worth noting is that unlike Document, there is no screen-reader documentation for Spreadsheet.

Acknowledgments

This document was produced as part of the Accessible Digital Office Document (ADOD) Project (http://inclusivedesign.ca/accessible-office-documents).
This project has been developed by the Inclusive Design Research Centre, OCAD University as part of an EnAbling Change Partnership project with the Government of Ontario and UNESCO (United Nations Educational, Scientific and Cultural Organization).

Partner logos: UNESCO-United Nations Educational, Scientific and Cultural Organization, the Government of Ontario and the Inclusive Design Research Centre (OCAD University)

(a) the reproduction is offered at no cost to the recipients; and
(b) the reproduction must preserve the "Version" section; and
(c) the reproduction must preserve the "Acknowledgments" section; and
(d) the reproduction must preserve this copyright notice.