W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2015

Re: Understanding How Focus Behavior Works For VoiceOver On IOS and TalkBack On Android

From: Jennifer Sutton <jsuttondc@gmail.com>
Date: Fri, 10 Apr 2015 14:25:21 -0700
Message-Id: <>
To: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Jamal and others:

The question I wondered about, Jamal, is what are you using to read?

Is it safe to assume you are referring to reading in Safari?

I honestly rarely read articles with Safari because I find 
stand-alone app.s much faster and more predictable (with IOS), much 
as I'd prefer to support the open Web.

If you'd like suggestions for app.s, Jamal, feel free to write me off-list.


At 12:06 PM 4/10/2015, David hilbert poehlman wrote:
>this is across-the-board behavior therefore it is an Apple call
>Jonnie Appleseed
>With His
>Hands-on Technolog(eye)s
>touching the internet
>reducing technology's disabilities
>one byte at a time
>On Apr 10, 2015, at 13:53, Jamal Mazrui 
><<mailto:Jamal.Mazrui@fcc.gov>Jamal.Mazrui@fcc.gov> wrote:
>Hi Jonathan,
>Do you have thoughts on the following problem?
>When using VoiceOver on iOS, I find that the VO cursor often loses 
>focus when in a list of items that may individually be active.  For 
>example, in almost every newspaper or magazine app that I use, after 
>I open an article to read and then return to the table of contents 
>via a Back button, the VO cursor loses its place in the list and 
>instead leaves me at the top of the list again.  So, when I am 
>selecting articles to read, I have to keep swiping through the 
>titles of articles I have already encountered before I swipe to new 
>titles.  I find this to be a significant drain on efficiency.
>How can iOS developers code so that the VO cursor maintains the 
>focus that a user would expect?  Could a change in the accessibility 
>API solve this problem so that developers do not have to 
>deliberately address it?
>Jamal Mazrui
>Director, Accessibility and Innovation Initiative
>Federal Communications Commission
>-----Original Message-----
>From: Jonathan Avila 
>Sent: Thursday, April 09, 2015 2:43 PM
>To: Jim; <mailto:w3c-wai-ig@w3.org>w3c-wai-ig@w3.org
>Subject: RE: Understanding How Focus Behavior Works For VoiceOver On 
>IOS and TalkBack On Android
>Jim, it depends on whether you are talking about native apps or web 
>apps.  For web apps you can use the standard practices for web 
>accessibility.  Regarding native apps, when screen readers are 
>activated both platforms change how interactions work and place 
>additional items into the swipe/focus order.  Essentially under iOS 
>if an element has isAccessibilityElement set to YES it is focusable 
>with swiping.  On android set the element to be focusable (e.g. 
>android:focusable) to make it swipable or accessible with the keyboard.
>Jonathan Avila
>Chief Accessibility Officer
>703-637-8957 (o)
>Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>-----Original Message-----
>From: Jim [<mailto:jhomme1028@gmail.com>mailto:jhomme1028@gmail.com]
>Sent: Thursday, April 09, 2015 2:30 PM
>To: <mailto:w3c-wai-ig@w3.org>w3c-wai-ig@w3.org
>Subject: Understanding How Focus Behavior Works For VoiceOver On IOS 
>and TalkBack On Android
>I'm trying to advise some developers how to sensibly help mobile 
>screen readers land in user-friendly places when screens come up.
>Before I have specific questions, I was attempting to wade through 
>the draft accessibility API document, and because I am only a 
>dangerous coder, and like things in non-technical language, at least 
>to start with, can anyone point me to somewhere that I can read to 
>understand this so that I can go from a high level and then drill 
>down to technical things?
>If building your own web site is holding you back, I can help.
Received on Friday, 10 April 2015 21:25:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 May 2017 01:54:15 UTC