Archives for posts with tag: Talkback

I’ve always felt that making native apps accessible is slightly easier than websites partly because they’re more streamlined in terms of their UX but also because you’re only dealing with one programming language. If you’re looking for an easy place to start making your app accessible you can give it a boost by adding text alternatives for images, buttons and other meaningful UI elements.

Text alternatives have a dual benefit as they’re not only the hook that Talkback users need to understand your app but also the hook needed for automated testing  with tools such as Lint.  For this reason it’s not unusual to see apps where the alternatives are written for devs and testing purposes – such as ‘app_button’ rather than being human readable text alternatives such as ‘Submit’. This should be avoided; text alternatives are for users not testers.

To add text alternatives on Android use contentDescription:

<Button
    android:id=”@+id/submit_button”
    android:src=”@drawable/submit”
    android:contentDescription=”@string/submit”/>

For elements that change state such as an add/remove button use setContentDescription method to edit the alternative at runtime:

String contentDescription = "Select " + strValues[position];
label.setContentDescription(contentDescription);

For decorative images the contentDescription should be set to ‘null’:

android:contentDescription=”@null”

contentDescription should not be used for labelling form inputs – editText fields. The description is only read before the text field is populated by the user and lost altogether if the field is populated or cleared by the user. The next best option is to use the android:hint attribute. Like contentDescription, android:hint will be announced when the field is empty but ignored when the field is populated. Unlike contentDescription however it will be announced if the user clears the form input.

This is still not an ideal user experience and can be confusing for Talkback users who want to verify what form input is what when checking a form before it is submitted. A more robust technique is to use the LabelFor property which allows a visible label to be associated with an EditText box. This will be announced regardless of whether the input field is empty or populated with text. If a visible label is not possible (although I’d recommend against that) you can make the label invisible so it doesn’t change your visual layout.

Resources

 

I published my first tutorial in .Net Magazine this week: Making Android apps voice output accessible. Android accessibility get’s less press than iOS accessibility so it’s nice to see it get an airing alongside the lovely Leonie Watson’s tutorial on making your iOS app accessible with VoiceOver.

Big thank you to .Net.

Good news for mobile voice output users as this week the guys over at Mozilla released further accessibility enhancements for Firefox in a nightly build. In addition to this Chrome was released into the Apple App store and also comes with accessibility baked in complementing it’s counterpart on Android which also recently became more accessible.Continue Reading Accessible Firefox and Chrome on Android and iOS

I’ve been playing around with ways of expanding abbreviated text on mobile using both <abbr> and <span> specifically to see how well supported voice output is. I ran a few mobile browsers and voice output software over a  test case for abbr and span listing abbreviated days of the week using <abbr>, <span> and as is (i.e. Mon, Tue etc).

The results in the table below lists what is ‘spoken’ by each browser / voice output pairing:

Mobile Safari / iOS VoiceOver Opera Mini / iOS VoiceOver Opera Mini / Android / Talkback Android/ Talkback Android/ IDEAL Web Reader Nokia/ Talks
Uncoded Monday, Tuesday, Wed, Thursday, Friday, Sat, Sun NA NA NA Mon, Tue, Wed, Thu, Fri, Sat, Sun Mon, Tuesday, Wed, Thursday, Friday, Sat, Sun
ABBR Monday, Tuesday, Wed, Thursday, Friday, Sat, Sun NA NA NA Mon, Tue, Wed, Thu, Fri, Sat, Sun Mon, Tuesday, Wed, Thursday, Friday, Sat, Sun
Span Monday, Tuesday, Wed, Thursday, Friday, Sat, Sun NA NA NA Mon, day, Tuesday, sday, Wed, nesday, Thursday, rsday, Friday, day, Sat, urday, Sun, day Mon, day, Tuesday, sday, Wed, nesday, Thursday, rsday, Friday, day, Sat, urday, Sun, day

 

Note: Android’s browser and Talkback  (from the Google EyesFree Project run by TV Raman) still don’t support ‘web view’ so was not included in the test case. Equally, Opera Mini does not support speech output either on iOS with VoiceOver or Android with Talkback so was not included. I will revisit this if things change. The IDEAL Web Reader is a self voicing browser available for free on in the Android Market place.

Conclusions

  • It looks like text-to-speech (TTS) engines for VoiceOver and Talks expand words they know (i.e. Mon to Monday) but ignore text that are words in their own right (i.e. wed, sat, sun). Nuance, the speech engine for VoiceOver, has the strongest support for automatically expanding words whereas the Nokia TTS has slight inconsistencies.
  •  <abbr> and <span> don’t seem to be supported by mobile Safari, the IDEAL Web Browser or the Nokia browser as all three failed to expand the days of the week that were not already expanded by TTS.
  • Using <span> results in the hidden text being read out in addition to the long and short forms of the days of the week.

If looking for a solution that works seamlessly across desktop and mobile browsers it looks like <abbr> and <span> is not it. What works best for screen readers on desktop browsers is <span> however this seems to have the worst support on mobile.

At least two screen reader users (@blindgeek and @kirankaja12) have mentioned that TTS expanding text can be quite annoying, presumably because it gets things wrong and confused. As a developer I’m not sure there is much that can be done about it especially given it can not be over ridden with <abbr> or <span>. The best advice is to avoid abbreviations where possible and keep written text plain and simple on mobile,

WordPress SEO