- From: Bryan Garaventa <bryan.garaventa@whatsock.com>
- Date: Fri, 5 Apr 2013 01:30:57 -0700
- To: "Phill Jenkins" <pjenkins@us.ibm.com>
- Cc: "WAI Interest Group" <w3c-wai-ig@w3.org>
- Message-ID: <90518E7EDB0A4147A7D26F1C3C77A184@WAMPAS>
I understand, and agree that this would best be solved by the AT manufacturer.
The problem I've had is that, when bugs are filed, it may take years for them to be addressed, and there is no certainty that they will be.
For example, I filed a bug regarding the scrollable div issue with Apple last year, so too regarding the inability of Voiceover to use ARIA Slider controls which cannot be gripped when Voiceover is running, and an issue where, if you add role="combobox" to an edit field, it makes it impossible to interact with for Voiceover users, where only a bonk noise occurs when you try to type into or read the content. I've tested these using an iPhone with build 6 I believe.
I would be interested to know if they actually have been fixed, but when I revisited them back in January, none were when I tested them.
You can see an example of the scrollable div at
http://whatsock.com/bootstrap
on the Scroll tab, which uses the following syntax:
<div class="accScrollable">
<div>
Scrollable content here.
</div>
</div>
I've tested this in both IE and FF successfully.
I've already programmed the carousel to be accessible using focus to stop animation.
The slider can be seen at
http://whatsock.com/modules/aria_slider_module/demo.htm
The example of role="combobox" can be seen at
http://whatsock.com/modules/auto_suggestion_search_field_module/demo.htm
This is all part of a larger project I'm releasing on the 15th for the UC System, which is a technical style guide for developers and engineering students, which covers 20 top level interaction design categories that are specifically built to be keyboard and screen reader accessible out of the box, including a Coding Arena where approximately 100 specific implementation types can be tested using Assistive Technologies, and precise HTML and JavaScript coding guidance for each , and all of the ARIA related pitfalls to be aware of during the process. I've been building this for months.
This is why I asked the initial question, because I wanted to know if I could shore up these inconsistencies before the release date.
----- Original Message -----
From: Phill Jenkins
To: Bryan Garaventa
Cc: WAI Interest Group
Sent: Wednesday, April 03, 2013 8:15 PM
Subject: 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
>
Received on Friday, 5 April 2013 08:31:29 UTC