Categories
google screenreader visual

Response to Accessibility in Google Docs

Read Write Web recently published the article Google Announces Sweeping Accessibility Improvements for Visually Challenged Users. On one hand, this is great news. But on the other hand, Google’s accessibility efforts have been inconsistent, and mostly within their own technologies; as we’ll discover below, not implemented for universal use.

The Google Docs updates have been tested by a screen reader user, Kevin Chao. With permission, the following is taken (and slightly edited) from his web post Google announced and took the wraps off what’s been dubbed “enhanced Accessibility in Google Docs”.

Google announced and took the wraps off what’s been dubbed “enhanced accessibility in Google Docs”

Applaud, Thank, and Appreciate

I certainly applaud, appreciate, and praise Google in their accessibility efforts, but there seems to be this level of accessibility, which includes efficiency, effectiveness, and equal access that Google is far from with all attempts, which Docs is no exception.

Dumbed Down Accesssibility limited UI/Look

Visiting Docs.Google.Com using Firefox and NVDA, either classic or new Look/UI, latter is much worse from an accessibility point, but all is relative, including “enhanced accessibility”. Google is always in in a race with itself, changing elements, such as looks/UI. Often there are different views to pick from, and it’s often the one that is “basic” or “classic” that is more accessible, which leaves screen readers with a dumb-downed experience than an equal experience Compared to the full “standard” or “new” UI/look that everyone else who does not need to use a screen has the luxury of using. There should not be more than one view, if there has to be an experimental/enhanced view, it should be accessible, and it’s very degrading that Google by only putting accessibility resources into the dumbed UI/Look implies that all blind screen reader users are unable to perceive, understand, and work with advance, complex, and rich UI/Looks.

Now, let’s move onto the main focus, which is the enhanced Accessibility in Google docs.

Using Firefox, NVDA, and looking at Docs.Google.com in classic view.

Main UI/Look
  • Navigating by form fields or line will reveal lots of unlabeled Controls, such as “button”, clickable, expanded, checkboxes, and clickable list. It’s bad enough from a user interface, experience, and accessibility standpoint that all these controls do not have proper labels, making them accessible, but there’s more.
  • Instructions indicate to get started, activate create new or upload button, but these are identified as clickable, which do not do anything when pressing ENTER. However, with enough attempts of everything under the sun such as NVDA+CTRL+SPACE, SPACE, mouse click, etc.; it will be possible to activate these buttons. It should not be this difficult, frustrating, and require all these work-around to activate buttons (no, no, they are not buttons, but clickable).
  • When navigating to the expand button, pressing ENTER, NVDA is silent. The new status, which is collapsed, is not conveyed from Docs via ARIA or any accessibility event. In addition, arrowing down does not show any additional content. ARIA Live-regions should be used to alert user of updated dynamic content.
  • Navigating to unlabeled button, pressing ENTER, reviewing contents on screen does not show that anything changed.
  • Lots of items are identified as menus and submenus, which when activated do not work as ARIA jQuery menus, but instead do not do anything, cannot track focus/read, and/or it’s not possible to exit menu/submenu.
  • Effective and efficient navigation is lacking greatly, which could Be improved by use of ARIA Landmarks and headings.
Creating/Editing Docs
  • Browse/upload process does not work by simply using arrows/TAB and ENTER/SPACE, but requires the same level of fighting, frustration, and work-around that was required to get into the upload page.
  • Creating a new doc/opening an uploaded one will open it in a new Tab, which is identified with: document title, app, JavaScript, file type, and editable”. While all this is great, arrowing in document reads absolutely nothing and same goes for tabbing around.

Conclusion

Google has optimized Google Chrome, ChromeVox, and Docs to work very well together. This locked-in and non-universal design towards accessibility should be avoided at all possible cause, which results in not as many people using it due to the need to use a different environment for particular task. One of the many benefits to a cloud solution, such as Docs is the anywhere access on anything, which ranges from desktops to mobiles, which Docs accessibility is far from.

Please, Google, there really needs to be real accessibility present, which includes effectiveness, efficiency, and equal level of access. No more of this Google accessibility, which is half-baked at best.

One reply on “Response to Accessibility in Google Docs”

Hi WebAX. Though I don’t personally disagree with Kevin on various points he makes, I do take exception to his general tone as some of the observations he asserts are half way correct or just flat out wrong.

Please see the reply to his official post on this thread
http://t.co/IvT0hPaf

I understand advocacy in the blindness community usually takes a hostile tone because doing it any other way does not yield any sort of response. However, with Kevin, who does work in industry (QA), I expect him to provide feedback in more official channels rather than ambiguous prose and unverified observation. I would urge the owners of this blog to read through my personal response above and have a look for themselves when reposting content like this.

Leave a Reply

Your email address will not be published. Required fields are marked *