NoResults view controller VoiceOver: suggested improvements for root view, multiline descriptions, and first element read

[designsimply]

Steps to reproduce:

1. Go to Settings > General > Accessibility > VoiceOver and toggle the setting on.
2. Go to WPiOS > My Sites > [any site] > Blog Posts > Search, enter text until you see no results.
3. Are the contents of the screen announced properly? Try accessing the things on the screen.
4. Go to Trashed. Repeat step 3.
5. Go to Scheduled. Repeat step 3.
6. Go to Reader > Saved Posts. Repeat step 3. (Note the bookmark icon is not read aloud.)
7. Go to Notifications > Comments and Likes. Repeat step 3.
8. Go to Reader > My Likes. Repeat step 3.

Result: when using VoiceOver, screens with no results are difficult to work with. (2m2s)

Note: testing this is easier when using a newer site without very much content.

^{Tested with WP Internal 12.2.0.20190412 on iPhone 6S iOS 12.2.}

Suggested improvements noted by @etoledom:

• The root view should be a whole accessibility element to avoid VoiceOver from reading elements behind it. This element is used in many areas of the app and can be super confusing for a VoiceOver user.
• The description is not read properly by VoiceOver when it’s multiline.
• It would be great if the no results title is the first element VoiceOver reads when a new screen is accessed. (Not sure if possible)

_{(internal reference: p77Llu-bQ6-p2 h/t @etoledom)}

[designsimply]

Adding to Groundskeeping for review because it has a [Pri] High label and noting that it was labeled as high priority because it came up as one of the top problems in an audit of VoiceOver issues at p77Llu-bQ6-p2.

[shiki]

It would be great if the no results title is the first element VoiceOver reads when a new screen is accessed

I made a quick implementation of this. Please see this video. I'm not actually sure if selecting anything (i.e. the “No likes yet“ message) right after the user selected a tab is desirable. It moves the focus away from the tabs. Then again, they'd probably move the focus to “see/hear” the results anyway. 🤔

What do you think of this implementation, @designsimply and @etoledom?

If you think this will work, what should happen if the list is not empty? Should we auto-select the first item in the list? Or something else? 🙂

[etoledom]

@shiki - It looks good!

A couple of questions:

• Does it work without releasing the finger from the screen? (Usually the user will explore the whole screen with the finger without releasing).
• Will the focus go back to the tabs if the user continue dragging the finger around?

[shiki]

@etoledom

Does it work without releasing the finger from the screen? (Usually the user will explore the whole screen with the finger without releasing).

Unfortunately, no. The process looks like this:

1. Double tap on tab to activate
2. VoiceOver will focus on the empty list.
3. The user will have to keep their finger over the last tap (step 1) and then touch and move around again.

It seems difficult in terms of usage. What I'm more concerned about is when the user is navigating manually by swiping right and/or left. Since VoiceOver changes the focus, the user would most probably be confused about where they are. I tried to do this by closing my eyes and I was also confused. 😬

Here is a diff if you'd like to try it out: https://gist.github.com/shiki/0f61636e9117b453b2bab8654ca3bbf8

And here is a video showing how it works. Starting from 0:34s, you'll see me navigating by swiping to the left to go back to the tab buttons. It takes a while.

Will the focus go back to the tabs if the user continue dragging the finger around?

Yes. But they just have to keep their finger over the last button so they don't lose track of where they were. It seems like a challenge.

Using Announcement

Your question gave me an idea of using .announcement instead. So I tried this:

https://gist.github.com/shiki/1e7b71887288bdea433e46c5e63ca2fd

The idea was:

1. The user selects a tab
2. If the list is empty, announce “No likes yet”

Unfortunately, it didn't work well because VoiceOver ignores announcements if it's already dictating something. It went like this instead:

1. The user selects the Likes tab.
2. VoiceOver dictates “Likes. Button”
3. The user double taps. This filters the notifications to likes only.
4. VoiceOver dictates “Selected. Likes.”
5. App requests announcement “No likes yet”. VoiceOver ignored it since it was still dictating “Selected. Likes”

There are some instances where VoiceOver will successfully dictate “No likes yet”. But considering that it's not a reliable behavior, I think we'd rather not have it.

I wonder if making the whole NoResultsViewController view an accessibility element, as suggested above, would be good enough. 🤔

[shiki]

The root view should be a whole accessibility element to avoid VoiceOver from reading elements behind it.

I started implementing this for now (#12943).

[dangermattic]

Thanks for reporting! 👍