Version
Date of Current Version: 16 February 2011
Latest Version (HTML): http://inclusivedesign.ca/accessible-office-documents/googledocument-review
Contents
Usage Notes
Review Results
Screen Reader Test 1. Accessing an Existing Test Document
Screen Reader Test 2. Creating a New Document
Acknowledgments
At the time of testing (February, 2011), Google docs: Document was found not to be very accessible using keyboard navigation. In addition, screen reader testing appeared to show important limitations.
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.
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.
This table summarizes the result of our reviews using the “ADOD Assessment Framework: Success criteria for assessing the accessibility of office application user interfaces”
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: Google docs: Document”. The test document included the elements in the left-hand column (i.e., heading, table of contents, etc.).
Able to Access? |
JAWS 11 |
Headings |
No. |
Table of contents |
Yes. Links were not indicated. |
Image with “alt” text |
No. |
Table |
No. The table contents were available, but they were not in a table. Note: viewing the page with ARIA application mode disabled there was a table containing the same content. |
Formatted text |
Yes. Not all attributes were announced. For example, JAWS did not read the 2 in superscript. |
Change tracking |
No. The text was available, but no changes were announced. |
Numbered pages |
No. There did not appear to be a way to access the headers and footers for the document. |
Search function |
No. The Find and Replace dialog was accessible, but the document frame was not reliably accessible enough to assess if the search had been successful. |
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 |
Create a new document |
Yes. From File > New > Document. |
Create two levels of headings |
No. |
Add and then edit paragraph text (e.g. do a select-cut-paste) |
No. The editor frame was not reliably accessible enough to perform this task. |
Insert an image |
No. It was possible to access Insert > Image, but the Insert Image dialog was not accessible enough to complete the task of inserting the image. After selecting the button to browse for an image to be uploaded, and selecting the local file, the dialog disappeared. |
Insert a 3-by-3 table and fill it with content |
No. It was possible to select Table > Insert Table, but the Insert Table sub menu was not accessible. |
Create a bullet list |
No. The editor frame was not reliably accessible enough to complete this task. The Bullets button did appear to be accessible from the toolbar. |
Use text formatting (bold, text colour) |
No. The editor frame was not reliably accessible enough to complete this task. Both the Format menu and options on the toolbar appeared to be accessible. |
Add page numbering |
No. This did not appear to be accessible from the menus or toolbar. |
Insert a table of contents |
Yes. Although there were no headings in the document to populate the table of contents with content. When the document was downloaded and opened in Word 2003 the following text was in the document “Add Headings (Format > Paragraph styles) and they will appear in your table of contents.” |
Save document |
Yes. Using the “Save” button. |
Other Comments by the Screen Reader Tester: |
The documentation for using Document with a screen-reader states that when a document loads ARIA application mode will be enabled and you will be in the editor frame. You should be able to edit and read the document by using arrow keys and standard keyboard commands. This was very inconsistent. There were times that the document would read, other times that it would not, times that edits took effect, and times that they did not. When reading the reading was not consistent, lines were often read out of order, when using left or right arrows to read by character some characters would repeat or not be spoken at all. |
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).
Copyright © 2011 Inclusive Design Research Centre, OCAD University
This material may be reproduced and distributed in print or electronic format only as long as:
(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.