Google Accessibility Update – Live Blog Post 7 – Accessibility Guides for End Users

Brand New Accessibility Guides for end users announced:  goo.gl/ge5HV

  • Best practices
  • Keyboard shortcuts – not in table format, so it’s easier to navigate

Product managers specifically asked the audience to provide feedback on these guides, they will update based on your feedback!  Contact them here:  accessibilityguidefeedback@gmail.com

AUDIENCE QUESTIONS:

  • How often will this document be updated?  Pretty much all the time, but definitely when there are new feature releases.
  • Where do we find this published?  Help Center, Google list serves.
  • Can changes to this document be announced to organizations rolling out Google Apps?  (I think this was a GREAT question).  We will review this with our deployment teams.
  • Any other screen readers beyond ChromeVox?  We’re working on it.
  • Are keyboard shortcuts specific to ChromeVox?  Those with a ChromeVox keys are noted in help guide.
  • Use of “Shift-Question Mark” key will provide list of keyboard shortcuts

TV Raman commented on use of online help:  it should be available BEFORE user begins using the tool.  We will do our best to keep this documentation as up-to-date as possible.

“FIRESIDE CHAT Q & A”

  • What does near and long term mean?  Near = now.  Longer term = we’re working on it, 6-12 months.
  • What about Calendar updates?  This was not covered earlier. These updates fit into the longer term bucket.

Betsy Roman introduced – runs the literacy program at Benetech, and described the Bookshare reader tool.  Helps commercial industry make textbooks accessible.  In short, it’s a reader tool.  I have to admit that I was completely unaware of this effort. There is work coming out of the W3C about adding speech APIs to HTML.  As this is “baked” many exciting new features and technologies will be made available into Google products. Chrome is only browser thus far to have implemented any of these APIs.  Demonstrated a biology textbook using the Bookshare web reader (Chrome extension).  Still working on MathML.

Questions:

  • How many titles are available?  All Bookshare titles (apparently a thousand-ish).
  • Is there voice search?  Not yet.
  • Is there rich text navigation?  Yes
  • Can you change speed of reader?  Yes
  • Are there bookmarks available?  Not yet
  • For Betsy:  how well has this BookShare tool been embraced by the publishing industry?
  • Can email be deleted in Gmail with one keystroke?  Yes, it’s the pound key, or A for archive.
  • Will ChromeVox be built as a desktop app?  No, it will probably not be built as a standalone screen reader app.
  • Which combination of OS / browsers are tested?  Last 2 versions on Windows, Mac, and Linux.  Including screen readers Jaws, NVDA and most recently WindowsEyes.  We work to make Chrome and ChromeVox most accessible first.
  • Is there a mode that can spell out words?  Reading level can be changed on both phones and desktop.
  • How do you avoid keyboard shortcut collisions?  We try to use same shortcuts other productivity software uses.  Trouble is that we compete with a lot of different things on your computer.  We sometimes have to deviate from “standards.”
  • Can you talk about standalone Google forms?  It’s accessible in the same way as our 3 editors.
  • Can you talk about App Engine?  Can a blind developer develop accessible apps using this platform?  Yes.  However, content creators still have the ability to make content that’s NOT accessible.
  • Is accessibility only for core apps?  Google is committed to building accessibility into all apps.  For practical purposes, it seems that the answer now is yes.  Engineers are now building in automated testing into build process.

TV Raman:  in the web app world, we need to standardize on keyboard combinations.  Which web app will want which keys?  This is an important question.

UPDATE:  Shawn from Google Docs tweeted this while he was sitting two chairs away from me: “Clarification: we also support and test with VoiceOver, not just JAWS, NVDA, ChromeVox.”

 

 

Google Accessibility Update – Live Blog Post 6 – A Couple Questions

TV Raman continues…

Quotes:  “Building accessibility for the web platform” and “we’re getting close to an inflection point” where things will get much easier to use.

A couple of my questions for the planned “fireside chat” with the Google crew later:

  1. Do all the features described today require use of Chromebook hardware, ChromeOS, and ChromeVox?
  2. Are keyboard shortcuts consistent across OS and browser platforms?

Google Accessibility Update – Live Blog Post 5 – Drive and Docs Suite

Drive and Docs Suite

Ajay Surie and team (slide went by too quickly)

“These are rich web applications that allow creation of rich content within a web browser”

TEXT FROM SLIDE:  “Building accessibility for complex web applications is still hard.  Docs is built on JavaScript; working with ChromeVox has allowed us to iterate rapidly and identify challenges with today’s accessibility toolset.  Goal is to learn from our implementation and evolve current web accessibility standards where necessary.”  Also want to make apps work with NON-CHROMEVOX screen readers.  Building in dictation features.

Document editor cursor is drawn and positioned dynamically.  Traditional screen readers don’t really work with these kinds of web apps.  We have a way to have the app talk to the screen reader (this was not specifically described).

Dev team put out another call for feedback on Docs.  Docs team has Incorporated a process during development where accessibility is built-in from the start.

Some Drive changes highlighted:

  • Completely redesigned keyboard interaction model in Drive
  • Keyboard navigation across the list easier and more consistent
  • Document list is a single focusable elements:  shortcuts to navigate document list
  • Improved focus management
  • Better verbalization of instructions and application state

Like Alex with Gmail (see post 4), they’re looking at making navigation more consistent.

  1. Search area at top
  2. Folder list area on left
  3. Document list in the middle
  4. Details pane (right side of the page for sighted users, basically a preview area with editable settings such as sharing)

Demonstrated “starring” a doc using ARIA within the Document list, then listing all starred items.  A lot of the keyboard accessibility features and new keyboard model is useful for people without disabilities as well.

Google Slides

Made slide editor “completely accessible.”  This demonstration should be interesting…

Opened presentation inside a new tab; on open, it reads # of slides, title, text, and a lot of other details.

  1. Canvas view is where slide content is created.  Items on slide are tab-navigable.  Opening a slide makes ChromeVox verbalize what’s on the canvas.
  2. Filmstrip is where organization of slides happens.
  3. Notes panel

Slides Demo

  • Demo’ed selection of text on a slide and bolding
  • Added a slide in filmstrip by control-n
  • Control-shift-backspace to activate context menu (equivalent of right-click), selected a slide layout

Docs Editor

  • Showed a ton of keyboard shortcuts (I didn’t catch all of them, unfortunately)
  • Comments feature
  • “Alt-forward slash” key combo brings up search features within the documents editor, i.e. any feature in the visible menus
  • Move between headings: “Control-Alt-P” and “Control-Alt-H”
  • Demonstrated moving back and forth between footnotes

Google Sheets (Excel-alike product)

Focus has been on giving user more contextual information about what they’re working on.  Moving around a sheet’s rows and columns provides a verbalized summary of what’s on the sheet (this demo had a minor glitch with verbalization).

Selecting range of cells provides details on cell content as well (this could get interesting if selecting a large number of cells…this was not demonstrated).

PAUL’S QUESTION:  are keyboard shortcuts consistent across OS and browser platforms?

Google Accessibility Update – Live Blog Post 4 – Gmail

Next up:  Gmail

Alex Gawley, Director, Product Management

Original product was loaded with JavaScript and designed for sighted users.  Last couple years, we’ve been focused on adding much better support for blind users.

  • We now have extensive support for ARIA labelling
  • Manual testing for new features
  • Automated tests for regressions (tests addition of new features to make sure it doesn’t break old features)

Many users still use HTML UI, so still al ong way to go.  Reconciling JavaScript UI model versus browser UI model.

We didn’t spend a lot of time on the navigation model until recently.

  • Complete redesign to inbox and conversation view navigation
  • Clearer model for regions of the UI
  • Navigation labels
  • Main – inbox and conversations
  • Use of arrow keys, N/P and Enter to navigate between and within regions
  • Rational model for managing focus

Alex gave a short demo of how this works now.

  • Focus is given to 1st message in the inbox
  • Jumped into navigation section (inbox, sent, trash, etc.)
  • Jumped back to “thread list” (using the 1st message list in the inbox)
  • Used “N” and “P” keys to jump to messages within a thread
  • Anytime in the main view, you can jump into navigation area by pressing the left arrow
Near term plans
  • Incorporating accessibility design and testing earlier in the development process (ie new compose).
  • Integration testing to prevent regressions

Long term plans:

  • Building in accessibility for all next-generation Gmail interfaces from the outset.

BIG QUESTION:  does this require use of Chromebook hardware?

Google Accessibility Update – Live Blog Post 3 – ChromeOS and Chromebooks

Min and Kenji of Chrome OS team:  Chrome OS and Chromebooks

Leans on speed, simplicity and security of ChromeOS

They’re cheap.

Boot in under 8 seconds, hassle-free, maintenance-free. Just sign in with Google account…all your stuff is “in the cloud.” Idea here is that your stuff is not tied to a specific machine, which is particularly important for people with disabilities who have settings “just so.”

Reviewing features of Chromebook, walked through setup:

  1. Accessibility is built-into OS at setup; spoken feedback provided via ChromeVox.
  2. Select language, keyboard, network.
  3. Email
  4. Select a picture ID
  5. Tutorial

SHARABILITY:  Kenji then walked through how different people can use a Chromebook by logging on with his account in “guest mode,” enabling accessibility features.

Min then asked for detailed feedback via the “Chromebook accessibility trusted test program.”  This is a program where Google will provide a Chromebook to qualified “trusted testers” on a first-come, first-serve basis.  Each participant will be provided with a Chromebook, with the expectation that users will be active testers.

Apply for Chromebook Accessibility Trusted Tester Program:  www.chromebook.com/accessibility

Program application is open until March 15

This program is available for individuals, not large organizations or federal, state, or local government organizations.

Continuing Adventures in Higher Ed & Technology