search

wordpress-mobile / WordPress-Editor-iOS

⛔️ [DEPRECATED] A reusable iOS rich text editor component.
GNU General Public License v2.0
1.06k stars 210 forks source link

Visual editor is randomly futzy with VoiceOver #608

Open astralbodies opened 9 years ago

astralbodies commented 9 years ago

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 commented 9 years ago

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

bummytime commented 9 years ago

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

aerych commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

I will do this.