- From: Alastair Campbell <alastc@gmail.com>
- Date: Wed, 3 Apr 2013 14:42:17 +0100
- To: Bryan Garaventa <bryan.garaventa@whatsock.com>
- Cc: WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <CAC5+KCFfxMTFF6bEm2_zFizB4qpqWJV4n8_4wZ1+MVW+JMmfwA@mail.gmail.com>
"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 Wednesday, 3 April 2013 13:42:46 UTC