TalkBack Actions on Android vs. Rotor Actions on iOS: A Tale of Google’s unfulfilled Vows

Google develops more accessible apps for iOS!

On the face of it, the allegation sounds uncanny and subjective. How can Google which controls Android and claims to be committed to its accessibility develop more accessible and standards-compliant apps for its rival OS, the iOS operating system? After all, if you rival Apple – which Google does, you definitely want to grab the attention of users, including visually impaired customers, to make them gravitate toward your very own operating system, Android. Ironically, though, Google doesn’t do that, either willfully or unintentionally, and actively shirks this responsibility. Let’s elaborate.

The VoiceOver Rotor and actions

The Rotor has long been a staple of VoiceOver on iOS. It allows users to perform many tasks without having to alter the position of the cursor or move to the Settings window to execute them.

You can use the VoiceOver rotor to change how VoiceOver works. You can change the VoiceOver volume or speaking rate, move from one item to the next on the screen and more.

For more on the VoiceOver Router, check here.

The Rotor has become even more powerful by incorporating what users tend to call Rotor actions. So, apart from the typical choices of moving by character/word/line, altering the language, enabling/disabling picture descriptions, moving by heading/link/landmark, etc., the Rotor offers extra context-aware options in its Actions section. These are mostly app-specific or scenario-specific items which make the task of interacting with the currently focused control or item easier. Users, for instance, can initiate a deletion operation in the Messages app, delete an item from the Phone log, or move items on the Home screen via Rotor actions. Almost all Apple apps utilize Rotor actions, and when they are present in a third-party app, it’s a sign that the developer is taking accessibility more seriously.

The TalkBack actions

Google added TalkBack actions as a reading control in TalkBack 13.1:

To easily access contextual options, use the new actions in the reading controls.

They can also be brought up from the TalkBack menu, or assigned to a gesture. The idea is to replicate the way Rotor actions make life easier for visually impaired iOS users. TalkBack actions, or what many developers know as accessibility actions, are also well documented here under the “Add accessibility actions” heading.

So what’s wrong?

The so-called can of worms is actually two-fold: most Google apps on Android don’t have TalkBack actions, and, perhaps to add insult to injury, their Google-developed counterparts on iOS have proper and fittingly useful Rotor actions. Now the question is if Google knows how to add Rotor actions to iOS apps and does it quite indulgently, why can’t it treat its own Android apps with the same degree of care and love? To further prove the point, let’s focus on a couple of important Google apps on both platforms.

Google Maps on iOS, vs. Google Maps on Android

While Google Maps on Android offers no accessibility or TalkBack actions, its counterpart on iOS offers the following useful VoiceOver Rotor actions for each item – like a restaurant or any location one might come across:

• Activate (default),
• Save,
• Directions,
• Menu,
• Call,
• Share,
• Explore image.

One might argue that the “Explore image” option is a standard VoiceOver Rotor item, but Google has included it in its Rotor actions for Maps.

Youtube on iOS vs. Youtube on Android

Again, Youtube on Android has zero TalkBack actions, but Youtube on iOS offers the following Rotor options:

• Action menu,
• Go to channel,
• Activate.

Gmail on iOS vs. Gmail on Android

This time around, the Gmail app on Android does indeed offer some actions. On iOS we get the following actions:

• Activate,
• Archive,
• Toggle star,
• Toggle selection.

With Android, Gmail offers the following TalkBack actions:

• Add star,
• Archive,
• Delete,
• Activate.

How about other Google apps?

Google Phone, Google Messages and Google Meet offer no TalkBack or accessibility actions on Android. And, in passing, Google Meet on iOS offers actions for VoiceOver users.

Conclusion

To play devil’s advocate, I might say that TalkBack actions aren’t a big deal and once people get used to the so-called actionlessness on Android, things will be fine. What’s more, Android users who’ve not worked with iOS and VoiceOver shouldn’t have huge issues to begin with. But, to be frank, this argument is faulty in many ways.

1. Google should be the role model for other Android developers, big or small. If Google doesn’t take its own accessibility standards on Android seriously, how can we expect smaller developers to do that? Yes, What’sApp and Instagram don’t have TalkBack actions on Android unlike their iOS counterparts, but Google is arguably a more important player in the field by virtue of its prowess and status.
2. When you don’t have TalkBack actions in an application, users should either flick left or right several times to reach their desired option, or press and hold the control which has the focus to bring up a relevant context menu. The former makes navigation quite time-consuming and laborious, similar to how navigation currently works in Google Maps on Android, and the latter is problematic in that locating the proper context menu on the screen might not be easy for many users, similar to What’sApps context menu options which are crammed into a small area of the screen. If you use Google Maps on Android, you’ll notice that jumping from place to place in the Search results takes a lot of time and flicking whereas, by virtue of VoiceOver actions, each result is just a flick away on iOS. Proper TalkBack actions take care of both issues mentioned above.
3. And, last but not least, I keep asking myself, once again, why it should take so long for Google to execute its own accessibility standards on Android whereas it swiftly embraces accessibility standards on iOS? And this shoddy execution isn’t limited to actions. The same page I mentioned above talks, among other things, about what it calls “Headings within text”:
   

   … Some apps use headings to summarize groups of text that appear on screen. If a particular View element represents a heading, you can indicate its purpose for accessibility services by setting the element’s android:accessibilityHeading attribute to true. Users of accessibility services can choose to navigate between headings instead of between paragraphs or between words. This flexibility improves the text navigation experience.

   While Google makes extensive use of headings in its iOS apps, finding Google apps with headings on Android would take a lot of time and effort.

To put it in a nutshell, what Google does in this regard serves to disgruntle users especially those who have prior experience of using iOS. It also serves to stave off the possibility of more visually impaired users making the ultimate switch to Android as, for many people, relinquishing the luxury of VoiceOver Rotor actions would be a hard pill to swallow.