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: Tue, 2 Apr 2013 22:56:01 -0700
Message-ID: <39F711CF0BA34F0FBA0FC189642E8E39@WAMPAS>
To: "Jonathan Avila" <jon.avila@ssbbartgroup.com>, "Alastair Campbell" <alastc@gmail.com>
Cc: "WAI Interest Group" <w3c-wai-ig@w3.org>
Yes, my point however stands, the more options that are available for 
developers to make web technologies more accessible, the easier it will be 
to accomplish.

If the argument here is that this is a bad idea, please explain why.


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


> Bryan, all the things you mention scrollable divs, carousels, and videos
> that play automatically are issues for other users with disabilities
> including those with motor impairments, low vision, and cognitive
> impairments.  Any WCAG conformant solution would require the ability to
> control these for all users not just users of VoiceOver.
>
> Jonathan
>
>
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
> Sent: Tuesday, April 02, 2013 1:35 PM
> To: Alastair Campbell
> Cc: WAI Interest Group
> 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
>>
> 
Received on Wednesday, 3 April 2013 05:57:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:48 UTC