Category: google

Categories
facebook google jobs mobile web youtube

Accessibility Jobs, April 2015 (all in California!)

Wow, many technical accessibility jobs open in Silicon Valley in Northern California!

Thanks @a11yJobs and @a11yBay

Categories
captcha forms google

Google’s No Captcha Shows Some Progress

It sure was exciting when Google’s new reCaptcha was announced last week. Dubbed “No Captcha”, the goal of course is to provide a service that determines a human from a bot in order to prevent spam and abuse of online forms.

Derek Feathersone (@feather) from Simply Accessible was one of the first to report its accessibility impact in the blog post On the Accessibility of Google’s No CAPTCHA. The tone of the post is very positive, but the testing cited excludes JAWS with IE (still the most popular screen reader combination) where I found the No Captcha failed miserably. On the bright side, it passes with keyboard-only, Dragon Naturally Speaking, NVDA and the latest VoiceOver.

Two fundamental problems with No Captcha is that it requires JavaScript and it doesn’t work with touch devices.

You can try the No Captcha yourself on a test page hosted by Alastair Campbell (@alastc).

checkbox with label "I am not a robot"
Google’s “No Captcha” reCaptcha

At best, No Captcha simplifies the Captcha experience. At worst, it excludes some users even more than the previous version. Hopefully Google will fix the current issues, especially support for JAWS.

My recommendation is to continue using non-Captcha security techniques; two great articles on how to do so are Spam-free accessible forms by WebAIM and 10 Things to Check Before Using a CAPTCHA by SitePoint.

Related:

Categories
android conference google presentations review

Google IO12 Review and Accessibility

I was fortunate enough to attend the Google I/O conference again this year (last year’s I/O blog). It was again held at the Moscone Center in downtown San Francisco, California. The opening keynote was a smash hit, and in addition to product announcements, featured skydivers wearing Google Glass!

On the second floor, it was a pleasure to meet Phil Strain (@pstr) in person; we’ve followed each other on Twitter for a couple years. He now works for Google and was helping out in the accessibility developer sandbox (booth). He demonstrated the latest ChromeVox. Also at the sandbox, Peter Lundblad demonstrated to me the braille output support using a new Nexus 7 tablet and a Humanware braille display.

Google announced the release of Android Jellybean (4.1) to be released through over-the-air updates to the Galaxy Nexus, Nexus S and Motorola Xoom in July. The announcement came with several Android accessibility enhancements including:

  • Speech recognition is now local to the device, no longer requiring the device to be connected to the Internet in order to use it.
  • Gesture support allowing for greater nonvisual control of the device using the touch screen.
  • Native support for refreshable Bluetooth Braille displays.
  • Source: The Mobile Accessibility Landscape

Session videos

Making Android Apps Accessible with T.V. Raman, Charles Chen, Alan Viverette, Peter Lundblad. Session description:

Android 4.0 introduced platform-level accessibility APIs so that you don’t have to be an expert to make an app that’s accessible to people with disabilities. Come learn how APIs for accessibility make your job easier. We’ll provide code examples covering touch exploration, speech synthesis, multiplatform support through use of a DPAD, magnification for low vision, braille, and more.

Advancing Accessibility for the Web with Rachel Shearer, Dominic Mazzoni, Charles Chen. Includes announcement and demo of the new Chrome Accessibility Developer Tools. Session description:

This session will help you learn through code samples and real world examples how to design and test your web apps for complete accessibility coverage. We will review APIs such as the Text-to-speech (TTS) API, tools like ChromeVox and ChromeShades and how Google products implement solutions today for users with disabilities.

Related links

Tidbits

  • I ran into Peter Hazelhurst, former VP of two of my past employers. Turns out he now is Global Head of Payments, Product Management at Google. He presented on “Introducing Google Wallet Cloud APIs”.
  • It was neat to run into Isabelle Olsson, a lead designer on the Google Glass project, outside the conference center. She had presented in the keynote.
  • The line to get the “free” devices on the first day was incredibly long; wrapped around the entire first floor! I would say it was “unbelievable”, but not too surprising considering three cool toys were being handed out including the new Nexus 7″ tablet.
  • While attending on Wednesday, my wife, kids, and parents (who were visiting from Michigan) had a great time touring downtown San Francisco!
Photo of accessibility sandbox (booth) at Google IO 2012
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.

Categories
analysis google socialmedia

Google Plus Keyboard Accessibility

Social media in general has major accessibility problems. Twitter, LinkedIn, and Facebook all certainly need improvement.

Google’s latest attempt at social media, Google Plus, launched a short time ago. This time, Google says they “considered accessibility of Google+ from day 1“. Although it’s a much better attempt at accessibility than the ill-fated Google Wave, Google Plus still has a lot of room for improvement.

I’ve only come across one Google+ accessibility review, Will Blind Users Be +1ing?, by a visually impaired user. So I decided to do some more testing myself. Once I got started, it quickly became apparent that only keyboard access checks were needed to determine how much more work needs to be done, as there were many, unfortunately.

Below are some of the web accessibility issues I found on Google Plus, all keyboard access issues.

Home/stream page

  • Tab into “Share” flyout but couldn’t get out without mouse. Strange since you can use Escape key to close the Notifications and Options flyouts.
  • In right column under “Suggestions”, can tab to “Add to circles” button but can’t activate it. Also, unable to tab to “Show all” link.
  • Under stream in left column, the circles links do not have visual focus state.

On a profile page

  • Unable to open Circles options.
  • Can open “Send an email” dialog, but upon closing, focus is lost and returned to top of page.
  • The text and image links in left column have no visual focus indicator, (how frustrating!): People in common, In [username] circles, Have [username] in circles.
  • On posts, no visual focus on “limited” link.
  • On posts, options are not keyboard accessible.

Photos page

  • After selecting a page number or prev/next, focus is lost and returned to top of page.
  • Image hover event not available with focus.
  • Can open image view, but upon closing, focus is lost and returned to top of page.
  • After opening image view, no visual focus on almost everything, I’m lost.
  • After opening image view, unable to select arrows to go to prev/next image.

Circles page

I give up. None of the main content on this page is keyboard accessible. No wonder why screen reader users can’t add people to circle; requires mouse-only drag-and-drop. I guess Google missed Opera’s article on accessible drag-and-drop using ARIA.

Global

  • No visual focus on footer links: Terms – Content Policy – Privacy

Summary

Google+ is more accessible than most Google apps, especially for a new one. But that’s not saying much; there are still many issues to resolve. And again, the list of problems on this post are only a subset of issues. It’s sad the such a huge, powerful, rich technology company can’t get the basics of web accessibility, even when they planned it from the start.

PS: When setting up Google voice and video chat, I quickly came across two “click here” links, yuck!