Re: UIPickerViewAccessibilityDelegate
Re: UIPickerViewAccessibilityDelegate
- Subject: Re: UIPickerViewAccessibilityDelegate
- From: Chris Fleizach <email@hidden>
- Date: Fri, 01 Feb 2013 13:18:56 -0800
It looks like if you overrode the accessibilityValue of the UIPickerView (in your custom subclass) you could avoid the row/range information.
However that information is usually very useful. Your mileage may vary depending on your application
On Feb 1, 2013, at 1:09 PM, Kenny Carruthers <email@hidden> wrote:
> 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:
>
> 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