| With a custom text input solution, you will have trouble providing a high level of accessibility. It is a known bug that this does not work already.
On May 15, 2012, at 12:08 PM, Melissa Dominguez wrote: I'm building a custom text input implementing UITextInput. I made my view have the adjustable a11y trait, and implemented my own methods for accessibility increment and decrement with navigation at the word level. I was about to expand to other granularities when I realized the rotor was already there with options of word, character, section, and heading. The word and character settings work only within the first word of my document, and heading and section not at all. Once you have done the rotor gesture, the custom code I wrote doesn't get called at all.
If I set the trait direct interaction, that makes the rotor go away, but also gets rid of accessibility increment and decrement. Very frustrating.
Thanks, Melissa
On Tuesday, May 15, 2012, Henny Swan wrote: Hi Melissa,
While frustrating that the rotor is breaking your app I think the
negative impact of disabling it (if indeed that's possible) will me much
bigger. Web Rotor is essential for VO
users as it enabled people to jump between types of content rather than
be forced to swipe and navigate in a linear fashion or tap arbitrarily.
We have a set of guidelines that we work towards in my organisation and
one that states 'content must not break or disabled device accessibility
settings or assitive technology'. Disabling Web Rotor would do that.
What's the specific issue you're up against?
Henny
On 15 May 2012 19:16, Melissa Dominguez <email@hidden> wrote:
Is it possible to disable the accessibility rotor? It is really breaking my app's a11y, ironically.
Thanks, Melissa
_____________________________
|