- From: Bryan Garaventa <bryan.garaventa@whatsock.com>
- Date: Fri, 5 Apr 2013 01:33:51 -0700
- To: "Joe Chidzik" <joe.chidzik@abilitynet.org.uk>, <w3c-wai-ig@w3.org>
- Message-ID: <DBE36D2E4DEF443DBC96CCEC13F78CF1@WAMPAS>
Is this using an iPhone, iPad, or Mac?
I've been trying to get this working on an iPhone specifically, where it would be both scrollable and announce that it was a scrollable div so that users would be aware of the functionality.
----- Original Message -----
From: Joe Chidzik
To: Bryan Garaventa ; w3c-wai-ig@w3.org
Sent: Thursday, April 04, 2013 12:40 AM
Subject: RE: Voiceover detection in JavaScript
I've created a div with CSS overflow: auto, with several paragraphs of text that are not visible without scrolling, and VoiceOver reads all of the content fine, without needing to scroll - just swipe onto the div and all content is read out. I'm assuming this is a non-standard div? Do you have an example online to look at?
Joe
From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
Sent: 04 April 2013 02:24
To: w3c-wai-ig@w3.org
Subject: Re: Voiceover detection in JavaScript
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
To: Bryan Garaventa
Cc: WAI Interest Group
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
>>
>
Received on Friday, 5 April 2013 08:34:28 UTC