Often within differing professions there is a need to collaborate with other team members, classmates, and associates, in order to work on a shared document project. This may involve programmers working together on the same design specification at the same time from different locations around the world, classmates working together on a school project at the same time from differing locations, associated professionals working together on the same spreadsheet at the same time from any location, or equal collaboration for any other purpose by any other type of group to achieve a common goal.

As with all such implementations accessibility is a significant challenge to address, and at present, Google Docs is no exception.

Google Docs and Accessibility

The way that Google Docs works is with an edit field for user interaction. This edit field consists of a body tag that uses the contenteditable attribute to simulate the functionality of an edit field, and includes the ARIA role=textbox attribute to provide the correct feedback to screen reader users. The problem however, is that this edit field is used as an interface only, and nothing typed within this field is actually written within this container. Instead, the text that is typed is programmatically intercepted and formatted elsewhere within the DOM structure, and then ARIA is used to provide auditory feedback for screen reader users. Since the textual data is not directly interacted with however, screen reader users cannot detect critical information related to the data, such as differences between upper and lower case letters, punctuation symbols, and so on.

This also means that when screen reader users attempt to read content within the Google Doc editor using the arrow keys for standard navigation, unexpected feedback is experienced.

For example, when using JAWS in IE, ‘blank’ and ‘space’ is announced with every press of the arrow keys, capital letters are not distinguished from lower case letters, and many punctuation symbols are not properly announced. This makes it extremely difficult to write and format content appropriately within a Google Docs editor when using a screen reader, since it is impossible for assistive technology users who are blind to recognize and identify formatted content written by others within the same document correctly, often leading to mistakes and unintended formatting breakages.

Though improvements will likely be made in the future as development continues, it is not currently feasible for the majority of screen reader users who are blind to accurately or reliably author collaborative documents using Google Docs for these reasons.

Exporting to MS Word and PDF

Google Docs does provide the ability to export documents into mainstream file types such as MS Word and PDF, which is a good option for providing more accessible content for Assistive Technology users, though this is typically only useful after a Google Doc is already complete.

There are some important aspects that must be noted when doing this however.

Firstly, when a PDF is directly exported from a Google Doc, it does not contain any tagging for accessibility, meaning that formatting features such as tabular data, lists, headings, labeled images, and so on, will not be reliably conveyed by screen readers as a result.

The most reliable method for creating a PDF from a Google Doc document is to first export it as an MS Word document, then convert the Word document into a PDF. This will preserve the majority of formatting elements that are present within the Word document.

It’s also important to note that, when exporting a Google Doc document into an MS Word document, some additional editing needs to be done to ensure accessibility. For example, alt text needs to be added for images, and column header mappings need to be added for data tables.

Importing from MS Word and PDF

Google Docs does provide the ability to import MS Word and PDF documents, as well as other file types, into Google Doc format. (Source: https://support.google.com/drive/answer/2407404?hl=en)

However, as with many other features related to Google Docs, this is only possible through the Google Drive interface, which is not accessible for screen reader users due to many ARIA and focus related accessibility issues. For instance, the help documentation in the preceding link refers to functionality that is not accessible for screen reader users who are blind (“Right-click the item in your Google Drive”).

A Google Doc document can be set as Readonly, which does provide more accessible interaction for screen reader users when directly linked to, however creating a Google Doc document from scratch and setting it to Readonly status is nearly impossible for screen reader users to accomplish without sighted assistance.

In Summary

The majority of screen reader users who are blind cannot, at present, accurately or reliably create or edit collaborative documents while preserving correct formatting and content flow using the Google Docs web editor interface. Accessible PDFs can be exported from Google Doc documents, but these must first be exported as MS Word documents and then converted into PDF format afterwards to preserve accessibility tagging. When MS Word documents are exported from Google Doc documents, some element types and formatting structures such as images and data tables need to be manually edited to ensure accessibility. Though more accessible file types can be imported into Google Docs, the Google Drive interface is nearly impossible for screen reader users who are blind to navigate reliably, making many Google Doc features impossible to utilize effectively.

This post primarily focuses on screen reader accessibility, but other assistive technologies such as screen magnification and voice navigation software should also be taken into account.

For example, the toolbar buttons within the Google Docs interface consist of div tags that use ARIA to provide ‘button’ feedback for screen reader users. Since voice navigation software such as Dragon NatuallySpeaking does not include any support for ARIA, common commands such as “list buttons” will not work, making it vitally important for standard keyboard navigation commands to be supported properly within Google Docs.