Android Compatibility

How to Make your App Compatible with Tecla (and every other input device)

Making your Android app compatible with Tecla will not only ensure people with mobility impairments will be able to use it. It will also benefit all users in contexts where Android devices are controlled through alternative input devices. That is, anything other than the touchscreen. Examples include: access through physical and external keyboards, control through game pads, joysticks, hands-free kits, steering wheel controls in cars, and networked appliances over ad-hoc networks (e.g., WiFi, UPnP, DLNA, etc.). Want to future proof your Android app? By making it compatible with Tecla you will be way ahead of the pack, ready for the day when we all start controlling our smartphones with brain-implanted chips!

Summary of benefits

  • Enhance the usability of your app for everyone, not just users with mobility impairments.
  • No need to implement switch access on your own, let Tecla do the heavy lifting!
  • Implement compatibility with current and future alternative input devices (e.g., external keyboard, hands-free accessories, remote controls, etc.)
  • Full input device compatibility can be achieved in four easy steps.

Step 1: Complete Focus Highlighting

The Android platform is incredibly adaptable. This means developers like you have the power to completely change the look & feel of your application to anything that suits your branding and design preferences. However, like the wise uncle Ben said once, “with great power, comes great responsibility”. Which is just another way for uncle Ben to tell you that, in the process of customizing your application’s look & feel, you should not break the built-in keyboard accessibility that Android developers have worked so hard to maintain.

When a user is navigating a user interface with an alternative input device, it is necessary to give focus to actionable items (that is, any element of the application that does something when tapped) so the user can see what will accept input. In any Android application, a UI control (also called a “widget”) is accessible to an alternative input device when it’s “focusable” property is “true.” This means that users can focus on the widget using directional controls and then interact with it. Widgets provided by the Android APIs are focusable by default and visually indicate focus by changing the widget’s visual appearance in such a way that it stands out from the rest of the widgets on the screen. We call this “focus highlighting”.

The problem is that when these widgets are customized, many application developers forget to provide the resources (e.g., button images) necessary to render the widgets in their focused state. This makes the widgets, and ultimately the application, completely incompatible with alternative input devices.

Most applications use a combination of built-in and custom widgets. This means that, unless you are rendering every single element of your app from scratch, making it compatible with alternative input devices shouldn’t take too much work (sorry game developers).

The specific way in which you can implement focus highlighting on a widget will depend on the particular way in which the widget was created, so detailed instructions on how to achieve this for every possible widget out there is definitely out of the scope of this guide, however, some general principles can be applied:

  1. Try as hard as possible to use the built-in widgets provided with the Android SDK
  2. If you must use a custom widget (I know, Android widgets aren’t the best looking things out there), try not to override their default background (e.g., make the background of your widget overlays transparent). This may still allow the view to solve focus highlighting for you.
  3. If you must also override the default background of the view (granted, those can be hideous too), then provide your own focused state resource. This will typically be another image based on the original widget (e.g., with inverted colors).
  4. Please make sure the focused state is clearly distinguishable from any other state. Don’t just saturate the image a bit or shade the border, really make it stand out.
  5. Last, but not least, make your highlight consistent. In other words, use the same highlighting strategy for all your widgets.

The code snippet below shows a sample drawable selector resource that can be used to implement focus highlighting on a custom ImageButton widget. ImageButtons are the most commonly broken widgets due to a lack of focus highlighting.

Step 2: Respond to Keyboard Events

When developing mobile applications, we typically focus on touch access. This is because we assume all of our users can and prefer to interact with their device by touching the screen, but this could not be further from the truth. While for a lot of people interacting with a screen directly by touch is more natural than through an external device like a keyboard, many users still prefer the latter. Moreover, there are about 5 million people in North America alone who because of disease or disability, find it impossible to use their hands to interact with their devices. There is yet another user group to consider: the increasing number of drivers with remote input devices embedded on their steering wheel. All of these users will benefit (and use your app more often) if all of the active elements in your application respond to keyboard events.

On most devices, clicking a view using an alternative input method sends a KeyEvent with KEYCODE_DPAD_CENTER to the view currently in focus. Make sure this event has the same effect as touching the view on the touchscreen. All standard Android views already handle KEYCODE_DPAD_CENTER appropriately but you may need to do this manually if you created your own custom view.

If possible, also treat the KEYCODE_ENTER event the same as KEYCODE_DPAD_CENTER. That makes interaction much easier from a full keyboard.

Step 3: Tweak Inaccessible Pop-Ups

The Android team has been pretty good at implementing alternative input device compatibility for the entire operating system. However, there are still a few kinks that require mending. The folks over at the Inclusive Design Research Centre have created a library that will help your application overcome the last few hiccups once the previous two steps have been taken care of.

The first of these hiccups relates to pop-ups (typically AlertDialogs) that are rendered on top of the soft input method (i.e., the on-screen keyboard) and thus are inaccessible to many alternative input methods. Making such pop-ups accessible to input methods simply requires fixing their z-order so that they appear below instead of above the on-screen keyboard. Here is how to do it:

  1. Download the Input Access Library from https://github.com/idrc/InputAccessLib
  2. Import the code and add it as a library for your Android application.
  3. Search your application code for “.show” calls on every Dialog and AlertDialog instances.
  4. Make the static call InputAccess.makeAccessible(Dialog) after every ‘show()’ call made on every Dialog and AlertDialog in your app

The code snippet below shows an example of how makeAccessible() method can be used to make an AlertDialog accessible to any alternative input device on Android. Note that besides the import statement for the InputAcess class, only one line of code per “show()” call is required.

Step 4: Tweak Inaccessible Options Menu

Coming soon!