Re: Voiceover detection in JavaScript

Bryan,
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?
____________________________________________
Regards,
Phill Jenkins, 
Senior Accessibility Engineer
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
http://www.facebook.com/IBMAccessibility
http://twitter.com/IBMAccess
http://www.linkedin.com/in/philljenkins



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
audience."

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 
ignored.

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
>