E-mail List Archives
Thread: Issue with on-screen keypad in IOS
Number of posts in this thread: 17 (In chronological order)
From: Subhash Chhetri
Date: Thu, Sep 17 2015 12:24AM
Subject: Issue with on-screen keypad in IOS
No previous message | Next message →
Hi Accessibility Experts,
Today I'm stuck in one issue in IOS. - Actually I'm filling an html form in IOS with Voice over, and I'm using on-screen keypad not the physical one. So the problem I'm facing is that when I finish typing in any form field and pressing Hide keyboard button located at the right end of on-screen keypad, focus doesn't move directly to the edit field, it remains anywhere in application.
This is so frustrating that I have to go back to the form fields either by flicking left/right on screen or by selecting forms via roter.
Is there anything I'm missing? Or it's a behavior of IOS.
Thanks
Best Regards,
Subhash Chhetri
From: Paul J. Adam
Date: Thu, Sep 17 2015 9:02AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
These are bugs with iOS VoiceOver. Please file a bug report with Apple. They fixed a few of mine recently. I filed one not fixed related to <select> controls not sending focus to the picker view when you expand the select on iPhone and when you close the picker the focus is not returned to the triggering element instead the focus is lost to the top of the page and the user would have to swipe all the way back to where they were.
On iPad when you expand a select control the focus is trapped in the pop over view which is great, but the focus is still lost to the top of the page after dismissing the pop over.
I've not looked into manually sending focus where you want it to go with JavaScript.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Sep 17, 2015, at 1:24 AM, Subhash Chhetri < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi Accessibility Experts,
>
> Today I'm stuck in one issue in IOS. - Actually I'm filling an html form in IOS with Voice over, and I'm using on-screen keypad not the physical one. So the problem I'm facing is that when I finish typing in any form field and pressing Hide keyboard button located at the right end of on-screen keypad, focus doesn't move directly to the edit field, it remains anywhere in application.
>
> This is so frustrating that I have to go back to the form fields either by flicking left/right on screen or by selecting forms via roter.
>
>
> Is there anything I'm missing? Or it's a behavior of IOS.
>
> Thanks
>
> Best Regards,
> Subhash Chhetri
>
> > > >
From: Sailesh Panchang
Date: Thu, Sep 17 2015 3:00PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Subhash,
Sure this is an issue while filling out any form on a mobile platform
that I have always encountered as a screen reader user.
I am referring to forms with multiple text boxes one after another
including just a username and password field.
When the form has two or more fields, the application cannot guess
that one has finished entering data ... unless it is a standard
phone# or date field and such.
On an iPad one can dismiss the keyboard but not on an iPhone because
there is no dismiss keyboard key.
So when one dismisses the keyboard the focus should go back to the
field that had focus or the next focusable element.
Sailesh Panchang
On 9/17/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> These are bugs with iOS VoiceOver. Please file a bug report with Apple. They
> fixed a few of mine recently. I filed one not fixed related to <select>
> controls not sending focus to the picker view when you expand the select on
> iPhone and when you close the picker the focus is not returned to the
> triggering element instead the focus is lost to the top of the page and the
> user would have to swipe all the way back to where they were.
>
> On iPad when you expand a select control the focus is trapped in the pop
> over view which is great, but the focus is still lost to the top of the page
> after dismissing the pop over.
>
> I've not looked into manually sending focus where you want it to go with
> JavaScript.
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
>> On Sep 17, 2015, at 1:24 AM, Subhash Chhetri < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> Hi Accessibility Experts,
>>
>> Today I'm stuck in one issue in IOS. - Actually I'm filling an html form
>> in IOS with Voice over, and I'm using on-screen keypad not the physical
>> one. So the problem I'm facing is that when I finish typing in any form
>> field and pressing Hide keyboard button located at the right end of
>> on-screen keypad, focus doesn't move directly to the edit field, it
>> remains anywhere in application.
>>
>> This is so frustrating that I have to go back to the form fields either by
>> flicking left/right on screen or by selecting forms via roter.
>>
>>
>> Is there anything I'm missing? Or it's a behavior of IOS.
>>
>> Thanks
>>
>> Best Regards,
>> Subhash Chhetri
>>
>> >> >> >> >
> > > > >
From: Cliff Tyllick
Date: Fri, Sep 18 2015 3:34AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
That's interesting, Sailesh. I had noticed that the iPhone lacks a key for dismissing the keyboard, but I had never thought about it in this context.
I'm not a developer, and I'm certainly not an iOS developer, but I see that there is a hotspot of sorts at the top center of the keyboard, just above and between the "T" and "Y" keys. For sighted users, a quick swipe down in that area will dismiss the keyboard. Because it is such a narrow band, it's hard to make that hotspot take and hold focus. I have to hold my finger on the screen just right to make that happen. Actually it happens any time I hover my finger right over that very narrow band
Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.
> On Sep 17, 2015, at 4:00 PM, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> Sure this is an issue while filling out any form on a mobile platform
> that I have always encountered as a screen reader user.
> I am referring to forms with multiple text boxes one after another
> including just a username and password field.
> When the form has two or more fields, the application cannot guess
> that one has finished entering data ... unless it is a standard
> phone# or date field and such.
> On an iPad one can dismiss the keyboard but not on an iPhone because
> there is no dismiss keyboard key.
> So when one dismisses the keyboard the focus should go back to the
> field that had focus or the next focusable element.
> Sailesh Panchang
>
>
>> On 9/17/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> These are bugs with iOS VoiceOver. Please file a bug report with Apple. They
>> fixed a few of mine recently. I filed one not fixed related to <select>
>> controls not sending focus to the picker view whien you expand the select on
>> iPhone and when you close the picker the focus is not returned to the
>> triggering element instead the focus is lost to the top of the page and the
>> user would have to swipe all the way back to where they were.
>>
>> On iPad when you expand a select control the focus is trapped in the pop
>> over view which is great, but the focus is still lost to the top of the page
>> after dismissing the pop over.
>>
>> I've not looked into manually sending focus where you want it to go with
>> JavaScript.
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>
>>> On Sep 17, 2015, at 1:24 AM, Subhash Chhetri < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>> Hi Accessibility Experts,
>>>
>>> Today I'm stuck in one issue in IOS. - Actually I'm filling an html form
>>> in IOS with Voice over, and I'm using on-screen keypad not the physical
>>> one. So the problem I'm facing is that when I finish typing in any form
>>> field and pressing Hide keyboard button located at the right end of
>>> on-screen keypad, focus doesn't move directly to the edit field, it
>>> remains anywhere in application.
>>>
>>> This is so frustrating that I have to go back to the form fields either by
>>> flicking left/right on screen or by selecting forms via roter.
>>>
>>>
>>> Is there anything I'm missing? Or it's a behavior of IOS.
>>>
>>> Thanks
>>>
>>> Best Regards,
>>> Subhash Chhetri
>>>
>>> >>> >>> >>> >>
>> >> >> >> > > > >
From: Cliff Tyllick
Date: Fri, Sep 18 2015 3:52AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Sorry... Let me finish. (My big fat fingers hit "Send" too soon.)
That's interesting, Sailesh. I had noticed that the iPhone lacks a key for dismissing the keyboard, but I had never thought about it in this context.
I'm not a developer, and I'm certainly not an iOS developer, but I see that there is a hotspot of sorts at the top center of the keyboard, just above and between the "T" and "Y" keys. For sighted users, a quick swipe down in that area will dismiss the keyboard. Because it is such a narrow band, it's hard to make that hotspot take and hold focus. I have to hold my finger on the screen just right to make that happen. Actually it happens any time I hover my finger anywhere right over that very narrow band all the way across the top of the keyboard.
If Apple could make that band take focus more easily and then act like a button when VoiceOver is on, that might be a way to provide that action.
In testing the behavior of that region of the screen, I notice that there's almost no way to access it by holding a finger down and dragging it over the keyboard. I have to catch the area just right on first touching the screen.
Anyway, maybe that's a handle whose action could be improved by Apple from a couple of different approaches with respect to accessibility.
Cliff Tyllick
Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.
> On Sep 17, 2015, at 4:00 PM, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> Sure this is an issue while filling out any form on a mobile platform
> that I have always encountered as a screen reader user.
> I am referring to forms with multiple text boxes one after another
> including just a username and password field.
> When the form has two or more fields, the application cannot guess
> that one has finished entering data ... unless it is a standard
> phone# or date field and such.
> On an iPad one can dismiss the keyboard but not on an iPhone because
> there is no dismiss keyboard key.
> So when one dismisses the keyboard the focus should go back to the
> field that had focus or the next focusable element.
> Sailesh Panchang
>
>
>> On 9/17/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> These are bugs with iOS VoiceOver. Please file a bug report with Apple. They
>> fixed a few of mine recently. I filed one not fixed related to <select>
>> controls not sending focus to the picker view whien you expand the select on
>> iPhone and when you close the picker the focus is not returned to the
>> triggering element instead the focus is lost to the top of the page and the
>> user would have to swipe all the way back to where they were.
>>
>> On iPad when you expand a select control the focus is trapped in the pop
>> over view which is great, but the focus is still lost to the top of the page
>> after dismissing the pop over.
>>
>> I've not looked into manually sending focus where you want it to go with
>> JavaScript.
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>
>>> On Sep 17, 2015, at 1:24 AM, Subhash Chhetri < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>> Hi Accessibility Experts,
>>>
>>> Today I'm stuck in one issue in IOS. - Actually I'm filling an html form
>>> in IOS with Voice over, and I'm using on-screen keypad not the physical
>>> one. So the problem I'm facing is that when I finish typing in any form
>>> field and pressing Hide keyboard button located at the right end of
>>> on-screen keypad, focus doesn't move directly to the edit field, it
>>> remains anywhere in application.
>>>
>>> This is so frustrating that I have to go back to the form fields either by
>>> flicking left/right on screen or by selecting forms via roter.
>>>
>>>
>>> Is there anything I'm missing? Or it's a behavior of IOS.
>>>
>>> Thanks
>>>
>>> Best Regards,
>>> Subhash Chhetri
>>>
>>> >>> >>> >>> >>
>> >> >> >> > > > >
From: Jonathan Avila
Date: Fri, Sep 18 2015 7:07AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
iOS 9 on the iPhone appears to add a done button to the keyboard at top right for input fields on web pages in addition to the return button.
The focus position however is still lost after tapping the done button
Jonathan
Sent from my iPhone
> On Sep 17, 2015, at 5:01 PM, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
>
> Subhash,
> Sure this is an issue while filling out any form on a mobile platform
> that I have always encountered as a screen reader user.
> I am referring to forms with multiple text boxes one after another
> including just a username and password field.
> When the form has two or more fields, the application cannot guess
> that one has finished entering data ... unless it is a standard
> phone# or date field and such.
> On an iPad one can dismiss the keyboard but not on an iPhone because
> there is no dismiss keyboard key.
> So when one dismisses the keyboard the focus should go back to the
> field that had focus or the next focusable element.
> Sailesh Panchang
>
>
>> On 9/17/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> These are bugs with iOS VoiceOver. Please file a bug report with Apple. They
>> fixed a few of mine recently. I filed one not fixed related to <select>
>> controls not sending focus to the picker view when you expand the select on
>> iPhone and when you close the picker the focus is not returned to the
>> triggering element instead the focus is lost to the top of the page and the
>> user would have to swipe all the way back to where they were.
>>
>> On iPad when you expand a select control the focus is trapped in the pop
>> over view which is great, but the focus is still lost to the top of the page
>> after dismissing the pop over.
>>
>> I've not looked into manually sending focus where you want it to go with
>> JavaScript.
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>
>>> On Sep 17, 2015, at 1:24 AM, Subhash Chhetri < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>> Hi Accessibility Experts,
>>>
>>> Today I'm stuck in one issue in IOS. - Actually I'm filling an html form
>>> in IOS with Voice over, and I'm using on-screen keypad not the physical
>>> one. So the problem I'm facing is that when I finish typing in any form
>>> field and pressing Hide keyboard button located at the right end of
>>> on-screen keypad, focus doesn't move directly to the edit field, it
>>> remains anywhere in application.
>>>
>>> This is so frustrating that I have to go back to the form fields either by
>>> flicking left/right on screen or by selecting forms via roter.
>>>
>>>
>>> Is there anything I'm missing? Or it's a behavior of IOS.
>>>
>>> Thanks
>>>
>>> Best Regards,
>>> Subhash Chhetri
>>>
>>> >>> >>> >>> >>
>> >> >> >> > > > >
From: Sailesh Panchang
Date: Fri, Sep 18 2015 7:55AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Actually, there is a 'Next' button and a 'Done' button above the
keyboard even in 8.4 iOS.
In earlier versions I had not found these and had not looked again.
The Next button does move focus to the next form field and the button
is disabled when one is on the last form field and then only Done is
enabled.
Thanks Cliff for making me look at this again. I had looked at for the
dismiss /next button in iOS7 as well as iOS 8.1 and, not having seen
them had not looked again!
Sailesh
On 9/18/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> iOS 9 on the iPhone appears to add a done button to the keyboard at top
> right for input fields on web pages in addition to the return button.
>
> The focus position however is still lost after tapping the done button
>
> Jonathan
>
> Sent from my iPhone
>
>> On Sep 17, 2015, at 5:01 PM, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> Subhash,
>> Sure this is an issue while filling out any form on a mobile platform
>> that I have always encountered as a screen reader user.
>> I am referring to forms with multiple text boxes one after another
>> including just a username and password field.
>> When the form has two or more fields, the application cannot guess
>> that one has finished entering data ... unless it is a standard
>> phone# or date field and such.
>> On an iPad one can dismiss the keyboard but not on an iPhone because
>> there is no dismiss keyboard key.
>> So when one dismisses the keyboard the focus should go back to the
>> field that had focus or the next focusable element.
>> Sailesh Panchang
>>
>>
>>> On 9/17/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>> These are bugs with iOS VoiceOver. Please file a bug report with Apple.
>>> They
>>> fixed a few of mine recently. I filed one not fixed related to <select>
>>> controls not sending focus to the picker view when you expand the select
>>> on
>>> iPhone and when you close the picker the focus is not returned to the
>>> triggering element instead the focus is lost to the top of the page and
>>> the
>>> user would have to swipe all the way back to where they were.
>>>
>>> On iPad when you expand a select control the focus is trapped in the pop
>>> over view which is great, but the focus is still lost to the top of the
>>> page
>>> after dismissing the pop over.
>>>
>>> I've not looked into manually sending focus where you want it to go with
>>> JavaScript.
>>>
>>> Paul J. Adam
>>> Accessibility Evangelist
>>> www.deque.com
>>>
>>>> On Sep 17, 2015, at 1:24 AM, Subhash Chhetri < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>> Hi Accessibility Experts,
>>>>
>>>> Today I'm stuck in one issue in IOS. - Actually I'm filling an html form
>>>> in IOS with Voice over, and I'm using on-screen keypad not the physical
>>>> one. So the problem I'm facing is that when I finish typing in any form
>>>> field and pressing Hide keyboard button located at the right end of
>>>> on-screen keypad, focus doesn't move directly to the edit field, it
>>>> remains anywhere in application.
>>>>
>>>> This is so frustrating that I have to go back to the form fields either
>>>> by
>>>> flicking left/right on screen or by selecting forms via roter.
>>>>
>>>>
>>>> Is there anything I'm missing? Or it's a behavior of IOS.
>>>>
>>>> Thanks
>>>>
>>>> Best Regards,
>>>> Subhash Chhetri
>>>>
>>>> >>>> >>>> >>>> >>>
>>> >>> >>> >>> >> >> >> >> > > > > >
From: Jonathan Avila
Date: Wed, Sep 23 2015 8:42AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
>> So when one dismisses the keyboard the focus should go back to the
>> field that had focus or the next focusable element.
I emailed accessibility at Apple about this with steps to reproduce and a test page and got the following respond
"We are unable to reproduce any unexpected behavior in our testing. The issue that your having is either device or content specific".
Has anyone else had any luck?
Jonathan
--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Sailesh Panchang
Date: Wed, Sep 23 2015 1:39PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Jonathan,
I believe the issue is moot now.
Above the keyboard on an iPhone and my mini iPad now running iOS9.01
and iOS8.4 (respectively) I can navigate to a forward / Back or Next
and previous button pair that fairly reliably move focus to the next /
prev form field.
When on the first / last field, the back / next button is disabled respectively.
On the keyboard there is a Go / Done button via which one can submit
the form or one can activate the submit button on the form.
The iPhone never had a dismiss keyboard feature AFAIK.
In earlier versions of iOS on the iPad I had not seen the prev / next
button above the keyboard. So I'd dismiss the keyboard, move to
activate the next form control and step through the form.
Thanks,
Sailesh
On 9/23/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> So when one dismisses the keyboard the focus should go back to the
>>> field that had focus or the next focusable element.
>
> I emailed accessibility at Apple about this with steps to reproduce and a
> test page and got the following respond
>
> "We are unable to reproduce any unexpected behavior in our testing. The
> issue that your having is either device or content specific".
>
> Has anyone else had any luck?
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
From: Jonathan Avila
Date: Wed, Sep 23 2015 1:49PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
> I believe the issue is moot now.
Above the keyboard on an iPhone and my mini iPad now running iOS9.01 and iOS8.4 (respectively) I can navigate to a forward / Back or Next and previous button pair that fairly reliably move focus to the next / prev form field.
Regardless of buttons to move between fields I still consider it important for the user to be able to fill out a form field and then continue on reading the text after the field before going to another field. Some fields have instruction text and page's don't always associate the text with form fields.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Sailesh Panchang
Date: Wed, Sep 23 2015 3:49PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Jonathan,
Sorry, I do not think that is an Apple / iOS issue if the form / page is
poorly marked up from an accessibility viewpoint.
The next/prev button help one get back within the form.
Then one can swipe left/right to read content surrounding a form control.
My query is: why is there no dismiss keyboard with VO on the iPhone ...
Cliff says it is available visually.
Thanks,
Sailesh
On Wed, Sep 23, 2015 at 3:49 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:
> > I believe the issue is moot now.
> Above the keyboard on an iPhone and my mini iPad now running iOS9.01 and
> iOS8.4 (respectively) I can navigate to a forward / Back or Next and
> previous button pair that fairly reliably move focus to the next / prev
> form field.
>
> Regardless of buttons to move between fields I still consider it important
> for the user to be able to fill out a form field and then continue on
> reading the text after the field before going to another field. Some
> fields have instruction text and page's don't always associate the text
> with form fields.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>
From: Paul J. Adam
Date: Wed, Sep 23 2015 3:54PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Here's the text of the bug report I filed at bugreport.apple.com on 14-Aug-2015:
Summary:
When VoiceOver for iOS user opens a <select> input element it expands a pop up button menu picker dialog at the bottom of the screen BUT focus is not sent to the picker view so the user can't select an option unless they can see what part of the screen to touch.
Also when the user does find the open picker view and they select an option then hit the done button they lose their focus to the top of the page and have to start over again.
This should be treated like an accessible dialog where you trap the users focus inside the picker view until they close it then return focus to the triggering element.
Steps to Reproduce:
1. Install iOS 9 Beta 5 on iPhone 6 Plus
2. Turn on VoiceOver
3. Visit http://pauljadam.com/demos/mobileforma11y.html
4. Activate First Day* <select> (double tap)
5. Activate Done button
6. Swipe to the next element with VO
Expected Results:
Focus goes into the date picker view when activating the <select> button. Focus returns to the select button when activating the Done button.
Actual Results:
Focus goes nowhere when activating the <select> button. Focus is lost to the top of the page when activating the Done button and then swiping to the next element you are at the top of the page.
Version:
iOS 9 Beta 5 on iPhone 6 Plus
Paul J. Adam
Accessibility Evangelist
www.deque.com
From: Patrick H. Lauke
Date: Thu, Sep 24 2015 3:50AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
On 23/09/2015 22:54, Paul J. Adam wrote:
> Here's the text of the bug report I filed at bugreport.apple.com on 14-Aug-2015:
Is that bug reporter supposed to file a copy on https://bugs.webkit.org
? If not, perhaps worth posting it there too (though I've not had much
luck in the past getting these things seen unless I explicitly pestered
people about it)
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Jonathan Avila
Date: Thu, Sep 24 2015 6:58AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
> Sorry, I do not think that is an Apple / iOS issue if the form / page is poorly marked up from an accessibility viewpoint. The next/prev button help one get back within the form.
I used a poor example to describe the situation I am concerned about. Consider a perfectly marked up form with an text input field then some checkboxes and radio buttons and then another text input field. The next and previous buttons on the keyboard will only move you to input fields and not to checkboxes or radio buttons.
So as a VO user I would need to fill out the first input field then press the forward button then press the back button and then swipe right to get to the checkbox after the first input field. I would also have to know that the page contained non-text input fields which I might not be aware of.
I would expect the preferred steps would be to fill out the input field then press done and then swipe right to get to the checkbox. To me this is comparable access.
Jonathan
--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Sailesh Panchang
Date: Thu, Sep 24 2015 2:22PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
Jonathan,
The done button above the keyboard dismisses the keyboard but as you
noted unfortunately moves focus to page top. If it works right and
place focus back in the same text box, then one should be able to
navigate preceding / following content.
Sailesh
On 9/24/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> Sorry, I do not think that is an Apple / iOS issue if the form / page is
>> poorly marked up from an accessibility viewpoint. The next/prev button
>> help one get back within the form.
>
> I used a poor example to describe the situation I am concerned about.
> Consider a perfectly marked up form with an text input field then some
> checkboxes and radio buttons and then another text input field. The next
> and previous buttons on the keyboard will only move you to input fields and
> not to checkboxes or radio buttons.
>
> So as a VO user I would need to fill out the first input field then press
> the forward button then press the back button and then swipe right to get to
> the checkbox after the first input field. I would also have to know that
> the page contained non-text input fields which I might not be aware of.
>
> I would expect the preferred steps would be to fill out the input field then
> press done and then swipe right to get to the checkbox. To me this is
> comparable access.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>
From: Paul J. Adam
Date: Thu, Sep 24 2015 2:45PM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | Next message →
I don't think the bugreport.apple.com bugs go to the webkit bug tracker. Mine is marked as duplicate so I'm not the only one to file it there. I use bugreport.apple.com because I have an iOS developer account.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Sep 24, 2015, at 4:50 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 23/09/2015 22:54, Paul J. Adam wrote:
>> Here's the text of the bug report I filed at bugreport.apple.com on 14-Aug-2015:
>
> Is that bug reporter supposed to file a copy on https://bugs.webkit.org ? If not, perhaps worth posting it there too (though I've not had much luck in the past getting these things seen unless I explicitly pestered people about it)
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >
From: Jonathan Avila
Date: Fri, Sep 25 2015 7:16AM
Subject: Re: Issue with on-screen keypad in IOS
← Previous message | No next message
> I don't think the bugreport.apple.com bugs go to the webkit bug tracker. Mine is marked as duplicate so I'm not the only one to file it there. I use bugreport.apple.com
I don't think they do either. I've logged bugs related to Safari with VoiceOver on iOS before and they have asked me to log them on the WebKit site.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter