Re: Reading order in iOS VoiceOver
Re: Reading order in iOS VoiceOver
- Subject: Re: Reading order in iOS VoiceOver
- From: Chris Fleizach <email@hidden>
- Date: Wed, 10 Aug 2011 08:42:52 -0700
On Aug 10, 2011, at 6:52 AM, Bruno Ultisoft wrote:
> In iOS VoiceOver, If I have an editable text view with an accessibility label (or an html text area), it seems as if it always reads the potentially very long text it contains before ever informing the user that it's an editable text field, or whether it's dimmed, like they would in Mac VoiceOver. I understand that this allows for a certain degree of consistency between editable text views and simple text fields, but I can't help but think that the Mac implementation makes more sense. Is this a bug, or a deliberate design decision?
>
Please file a bug if you think this behaves incorrectly
> On a related note, is there any documentation anywhere about the order in which VoiceOver reads things (in Mac or iOS)? I have to craft an accessibility strategy for an in-house application framework, and it would be invaluable.
>
There is no such documentation. Generally it's not something a developer should have to worry about (unless you believe the order is wrong). On the Mac side, a VoiceOver user is also able to choose and re-order the items that are spoken for an element by going to the VoiceOver utility application.
> Thanks! _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Accessibility-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden