RE: Voiceover detection in JavaScript

Amending a user's experience of using a webpage depending on whether voiceover is running is making assumptions about their preferences. Accessibility should be geared towards allowing a user to impose their own preferences on pages - if they are running Voiceover, the page works with Voiceover, for instance. Providing a different experience for VoiceOver users means that later on, if content or functionality is changed on a page, it has got to be changed for the VoiceOver specific content\functionality on the page as well. 

If you start providing specific, alternate functionality for even a few types of assistive technology, then making a simple change to the layout\functionality of a page might translate to many times more work in adapting the specific functionality aimed at AT users. This is one of the reasons that separate, text only sites, whilst often accessible, were the poor cousins to the main website they supported - site owners found that they had to maintain two separate sites, often leading to the text only site becoming out of date compared to the main site.  I would also be concerned about rich functionality being replaced with basic functionality purely because it's easier to make it accessible; after all, rich content can be made accessible using ARIA. 

A more passive approach would be to use VoiceOver\Screenreader detection to insert content into the page "It seems you are using VoiceOver, if so, you may benefit from reading our accessibility page which details how certain aspects of this site work". Even then, it would be dangerous to assume that all the users who would benefit from this message would receive it. 

Joe 


> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
> Sent: 03 April 2013 06:56
> To: Jonathan Avila; Alastair Campbell
> Cc: WAI Interest Group
> Subject: Re: Voiceover detection in JavaScript
> 
> 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 07:30:09 UTC