RE: UIPickerViewAccessibilityDelegate
RE: UIPickerViewAccessibilityDelegate
- Subject: RE: UIPickerViewAccessibilityDelegate
- From: Pratik Patel <email@hidden>
- Date: Fri, 01 Feb 2013 16:14:40 -0500
I'll try to do some research for you. Can you ask them what they believe is
violated by including this information?
Regards,
Pratik
Pratik Patel
Founder and CEO, EZFire
T: 718-928-5529
M: 718-249-7019
E: email@hidden (or email@hidden)
Follow me on Twitter: @ppatel
Follow me on LinkedIn: http://www.linkedin.com/pub/pratik-patel/9/985/882
Skype: Patel.pratik
-----Original Message-----
From: accessibility-dev-bounces+pratikp1=email@hidden
[mailto:accessibility-dev-bounces+pratikp1=email@hidden] On
Behalf Of Kenny Carruthers
Sent: Friday, February 01, 2013 4:09 PM
To: email@hidden
Subject: Re: UIPickerViewAccessibilityDelegate
While I'm agreement that including this accessibility information is
helpful, we've yet to be able to convince the testing group.
One of their data points is that in Apple's clock application, when
adjusting timers and alarms, this additional information is not present. I
suspect this is because Apple might be using a UIDatePicker in the Clock
application, which doesn't inherit from UIPickerView.
In our application, we use a custom UIPickerView class to display various
types of items the user can choose, one of which happens to minutes and thus
looks (and acts) very much like a UIDatePicker (though with a "minutes only"
mode).
So in some parts of the application, we use a genuine UIDatePicker where
appropriate, but in other parts we use our UIPickerView. Both controls look
almost identical, but in the case of the UIDatePicker, it doesn't read back
the current selection's location and range, whereas in the use of the
UIPickerView it does.
This apparent discrepancy between UIDatePicker and UIPickerView is at the
root of our problem and, for better or worse, the 508 testing group
certifying this application is (for now) requiring that we find a way to
remove the extraneous range information that UIPickerView is adding.
If there's a way to do that, I'm open to anything...
Sincerely,
Kenny
On Jan 31, 2013, at 7:52 PM, "Pratik Patel" <email@hidden> wrote:
> Kenny,
>
> In this case, I would respectfully suggest that your tester is not doing
an
> adequate job of testing. I do not aim to criticize but as someone who uses
> this technology, tests it, trains developers, designers and other
testers,
> I see nothing in the additional information to prevent the certification
> from being granted. The additional information is necessary. In fact, the
> lack of minimum value and maximum value of the picker (range) would be
> considered a failure by our testers. Accessibility hint--" Swipe up or
down
> to adjust the value"--can be turned off by the user. It's the default
> accessibility hint given to a commonly used component.
>
> Pratik Patel
> Founder and CEO, EZFire
> T: 718-928-5529
> M: 718-249-7019
> E: email@hidden (or email@hidden)
> Follow me on Twitter: @ppatel
> Follow me on LinkedIn: http://www.linkedin.com/pub/pratik-patel/9/985/882
> Skype: Patel.pratik
>
>
>
> -----Original Message-----
> From: accessibility-dev-bounces+pratikp1=email@hidden
> [mailto:accessibility-dev-bounces+pratikp1=email@hidden] On
> Behalf Of Kenny Carruthers
> Sent: Thursday, January 31, 2013 9:47 PM
> To: email@hidden
> Subject: UIPickerViewAccessibilityDelegate
>
> UIPickerViewAccessibilityDelegate allows users of a UIPickerView to set
the
> accessibility label and the accessibility hint for a component in a
> UIPickerView.
>
> However, it appears that Voice Over injects additional information
regarding
> the possible range of component items when reading back the accessibility
> state of a UIPickerView component.
>
> For example: I have a UIPickerView with a component that represents the
> numbers 1-20. When Voice Over reads back this component, I get the
following
> (Assuming '11' is selected):
>
> "11. 11 of 20. Picker Item. Adjustable. Swipe up or down to adjust the
> value."
>
> Is there anyway to have Voice Over *not* inject "11 of 20"? No amount of
> playing around with the label, value or hint of the components or labels
> inside of those components seems to disable that injection.
>
> (Side note: In applications like "Clock", this additional information is
not
> read back.)
>
> Any help would be appreciated as this issue is causing an application to
> fail a 508 compliancy test that it is required to pass. (The reported
> failure is due to that information causing confusion to the tester/user.)
>
> (Ideally a solution that is iOS4 compatible would be ideal, but I'll
settle
> for anything right now.)
>
> Thank you.
>
> Sincerely,
> Kenny
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Accessibility-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> om
>
> 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:
om
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