Re: Voiceover detection in JavaScript

hi Bryan,
sounds like a nasty bug in VoiceOver that needs to be fixed.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 4 April 2013 02:23, Bryan Garaventa <bryan.garaventa@whatsock.com> wrote:

> **
> Alright, since it's so clear cut, perhaps you can give me the solution to
> this problem?
>
> I have a scrollable div.
>
> I have programmed it to be fully keyboard accessible.
>
> It is accessible in all Windows based screen readers, and it is accessible
> to all keyboard only users. I know this, because I've tested it.
>
> The only place it is not accessible is on iOS because of Voiceover, since
> Voiceover doesn't read content that is scrolled off screen.
>
> So, since there is no way to detect Voiceover usage, I literally have no
> way to make this accessible for iOS touch screen users who use Voiceover.
>
> So apparently, what I'm hearing here is that this is actually desirable,
> because the potential of developers screwing things up is greater than the
> actual benefit of providing accessible features.
>
> Sort of like saying, blind people are not allowed to use this feature, for
> their convenience.
>
> Is this correct?
>
>
>
>
>
>
>
>
>
>
>
> ----- 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:* Wednesday, April 03, 2013 6:42 AM
> *Subject:* Re: Voiceover detection in JavaScript
>
> "the more options that are available for developers to make web
> technologies more accessible, the easier it will be to accomplish."
>
> Sure, for *one* or perhaps two technologies. That doesn't cover even a
> small fraction of what people use.
>
> Are you going to optimise for VoiceOver, Jaws, Windows Eyes, NVDA, SA to
> go, Zoomtext, Dolphin's screen reader & magnifier, Dragon Naturally
> Speaking... and on an on. How will you deal with the inevitable conflicts
> between them?
>
> Hopefully you can see that "more options" is really too many options. That
> is why we have guidelines, because there are too many things to test. The
> rational approach is to create core guidelines/standards so the a regular
> developer doesn't have to know all the technologies.
>
> Be zen about it: use the most basic approach that works, across
> everything. Don't create barriers in the first place, enhance an accessible
> page carefully with the more complex features.
>
> That might sound rather vague, but as I asked before, what is the problem
> you are trying to solve?
>
>
>
> On Wed, Apr 3, 2013 at 1:25 PM, Jonathan Avila <jon.avila@ssbbartgroup.com
> > wrote:
>
>> Bryan, the only place where I see being able to access/query VoiceOver
>> would be in embedded web content within an iOS native application.  In
>> non-native web apps customizing just for one assistive technologies seems
>> like a slippery slope and would likely take away resources and fixes that
>> would benefit other users with disabilities.    Many times I have seen
>> apps that are customized for a screen reader view, a low vision view,
>> etc..  These applications are almost always not friendly to people with
>> other disabilities and pigeon whole people into one category.  For
>> example, people with motor impairments are told to use the screen reader
>> view which has tiny text and no graphics.  People with low vision are
>> forced to use the low vision view which may have harsh colors and locked
>> in large font sizes.  This attitude goes back to the days of sight saving
>> classes that people with visual impairments were put in instead of the
>> mainstream classroom.  Please, let's not return to the 1950s.
>>
>> Jonathan
>>
>> -----Original Message-----
>> From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
>>  Sent: Wednesday, April 03, 2013 1:56 AM
>> 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
>> >>
>> >
>>
>
>