Visual editor is randomly futzy with VoiceOver

[astralbodies]

Original issue: https://github.com/wordpress-mobile/WordPress-iOS/issues/3468 Reported: https://twitter.com/TheBlurredNerd/status/581207539741753344

edit/new post text fields are erratic, can't always access them.

[astralbodies]

A bit more detail after watching a blind user interact with the app:

• Title and Body fields are not labeled for VoiceOver
• Switching to HTML mode (plain text mode?) doesn't have an audible confirmation on what happened (and focus doesn't shift for selected VO control)
• Options button in Plain (legacy) editor isn't labeled

[bummytime]

Good idea from @astralbodies: instead of making the editor webview "accessibility friendly", perhaps automatically launch the legacy editor if voiceover is enabled.

[aerych]

perhaps automatically launch the legacy editor if voiceover is enabled

Is the legacy editor considered deprecated? Should we be adding more dependency on it at this point?

[bummytime]

@aerych. Good question. The issue we are running into with UIWebView/WKWebView as the foundation for the new editor is less than ideal accessibility (as compared to our previous 100% native implementation). So to me, the options are:

1. Keep the legacy editor around so blind users can have a functional editor (to them).
2. Deprecate and remove the legacy editor and do what we can with the new editor knowing it will be less than ideal (in visual mode).
3. Consider forcing voiceover users into the HTML mode of the new editor (which is native) and improve that experience for them.

@astralbodies do you have any thoughts here based on your chats with sight-impaired users?

[astralbodies]

I want to say HTML mode was doable but there was some problem with there being no distinction between the title and the body of the post. The legacy editor wasn't also terribly accessible due to the Options being at the bottom of the post and it didn't announce what it was for.

If we can confirm the accessible nature of the new editor I say we stick with it and HTML mode.

Here's what I'm thinking:

1. User edits or creates a new post.
2. VoiceOver is detected and the editor isn't HTML already and a UIActivityView is presented asking them to choose HTML mode explaining its a better VO experience. 3a. User chooses Yes and HTML mode is selected. 3b. User chooses No and the editor remains the same. Popup never reappears.

This assumes the HTML mode state is retained on the device.

[bummytime]

If we can confirm the accessible nature of the new editor...

I will do this.