W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2013

Re: Voiceover detection in JavaScript

From: Bryan Garaventa <bryan.garaventa@whatsock.com>
Date: Fri, 5 Apr 2013 01:30:57 -0700
Message-ID: <90518E7EDB0A4147A7D26F1C3C77A184@WAMPAS>
To: "Phill Jenkins" <pjenkins@us.ibm.com>
Cc: "WAI Interest Group" <w3c-wai-ig@w3.org>
I understand, and agree that this would best be solved by the AT manufacturer.
The problem I've had is that, when bugs are filed, it may take years for them to be addressed, and there is no certainty that they will be.

For example, I filed a bug regarding the scrollable div issue with Apple last year, so too regarding the inability of Voiceover to use ARIA Slider controls which cannot be gripped when Voiceover is running, and an issue where, if you add role="combobox" to an edit field, it makes it impossible to interact with for Voiceover users, where only a bonk noise occurs when you try to type into or read the content. I've tested these using an iPhone with build 6 I believe.

I would be interested to know if they actually have been fixed, but when I revisited them back in January, none were when I tested them.

You can see an example of the scrollable div at
on the Scroll tab, which uses the following syntax:

<div class="accScrollable">
Scrollable content here.

I've tested this in both IE and FF successfully.

I've already programmed the carousel to be accessible using focus to stop animation.

The slider can be seen at

The example of role="combobox" can be seen at

This is all part of a larger project I'm releasing on the 15th for the UC System, which is a technical style guide for developers and engineering students, which covers 20 top level interaction design categories that are specifically built to be keyboard and screen reader accessible out of the box, including a Coding Arena where approximately 100 specific implementation types can be tested using Assistive Technologies, and precise HTML and JavaScript coding guidance for each , and all of the ARIA related pitfalls to be aware of during the process. I've been building this for months.

This is why I asked the initial question, because I wanted to know if I could shore up these inconsistencies before the release date.

  ----- Original Message ----- 
  From: Phill Jenkins 
  To: Bryan Garaventa 
  Cc: WAI Interest Group 
  Sent: Wednesday, April 03, 2013 8:15 PM
  Subject: Re: Voiceover detection in JavaScript

  I believe you may be raising three use cases that should really be investigated to determine if the deficiency in "accessibility as experienced by the end user" is best solved by improving the assistive technology as opposed to hacking the web/app code with undesirable browser or AT detection.   

  1. Scrollable Divs 
  2. Carousels 
  3. Auto Playing videos 
  In other words, for each of the three use cases (scenarios or widgets) why does a desktop browser with a screen reader "work" but not VoiceOver?  Should VoiceOver behave differently?   How so? 

  I'm not advocating for the Assistive Technology (AT) to try to compensate for poor accessibility compliance from the web page/app, or poor support from the browser, but there is often a lot of support from the AT itself that is needed.  For example, the ability of the AT to automatically reduce the volume of the auto playing video is critical for the ability of the screen reader user using audio (not a braille display) to be able to find and control the player volume controls.  There have been a couple of papers presented by IBM  at CSUN regarding this problem of two simultaneous audio inputs to the end users - the screen reader and video trying to talk over each other at the same time - who trumps who?  Well, it depends on when and what the end user wants to hear and so its the user that needs to decide - not the web developer, not the player developer, but the AT developer with support from the player and/or platform OS that needs to provide that choice.  A very different problem than supporting a keyboard only user, or just trying to increase the volume for a hard of hearing user.  In my opinion the AT in this case has more of the responsibility to solve the problem, often referred to as more usable and feature rich AT.   

  Could you send URLs that we can test and compare ATs with to determine if it is in fact your scrollable DIV and Carousels that are "fully WCAG compliant" and therefore enabled so that an AT could do its job? 
  Phill Jenkins, 
  Senior Accessibility Engineer
  IBM Research - Human Ability & Accessibility Center

  From:        "Bryan Garaventa" <bryan.garaventa@whatsock.com> 
  To:        "Alastair Campbell" <alastc@gmail.com>, 
  Cc:        "WAI Interest Group" <w3c-wai-ig@w3.org> 
  Date:        04/02/2013 04:27 PM 
  Subject:        Re: Voiceover detection in JavaScript 


  "It might be easy, but it's unlikely to be a good idea for web
  sites/apps. That line of thinking leads to user-agent specific apps
  and sites, rather than making things accessible to the widest

  Actually that's incorrect. Limiting the resources that are available to 
  developers to solve basic and simple accessibility issues by requiring full 
  UI changes makes it more likely that such accessibility issues will be 

  Here are three simple examples of this.

  Scrollable Divs are present all over the web, however they are extremely 
  difficult to use with Voiceover running. The simplest solution for this is 
  to provide two buttons, Scroll Up and Scroll Down, so that Voiceover users 
  can simply tap them to scroll the content. However this is highly 
  undesirable for visual UI designers and will never be included.

  Carousels with dynamically rotating content are also present everywhere, but 
  can be very confusing for Voiceover users, when the content keeps changing 
  as you try to read it.

  Videos that play automatically when a page loads are another issue, which is 
  fine for sighted users, but is very difficult for Voiceover users who can't 
  hear Voiceover reliably when trying to read the content of the page to find 
  the player controls when the video keeps playing.

  So here is a simple solution

  Add an event, such as 'voiceoverStateChanged' to Safari, which when 
  triggered, updates a global Boolean in the browser, such as 
  window.isVoiceoverRunning. When True, Voiceover is running, and when False, 
  it's not.
  As a state change event, this can be tapped into in the same way that touch 
  events are, so that this detection can be automatic.

  Now, if this were the case.

  Scrollable Divs could have navigation buttons dynamically added when 
  Voiceover is running, and removed when it is not.

  Carousels can be automatically stopped when Voiceover is running, or 
  continue when it is not.

  Automatically playing videos can be stopped onLoad when Voiceover is 
  running, or play when it is not.

  There are an infinite number of ways where this would be beneficial for 
  accessibility, and none that I can see where this would cause negative 
  issues to occur.

  ----- Original Message ----- 
  From: "Alastair Campbell" <alastc@gmail.com>
  To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
  Cc: "WAI Interest Group" <w3c-wai-ig@w3.org>
  Sent: Tuesday, April 02, 2013 1:54 AM
  Subject: Re: Voiceover detection in JavaScript

  > Bryan Garaventa wrote:
  >> That's quite a deficiency, since it should be fairly easy to implement 
  >> the
  >> checker in Safari by querying the objects within the native iOS platform, 
  >> in
  >> the same way that Windows browsers do for COM objects.
  > It might be easy, but it's unlikely to be a good idea for web
  > sites/apps. That line of thinking leads to user-agent specific apps
  > and sites, rather than making things accessible to the widest
  > audience.
  > If you share what it is you're trying to achieve, perhaps there is a
  > web-friendly way of doing that?
  > -Alastair
Received on Friday, 5 April 2013 08:31:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:44 UTC