[toc]Making your iOS® app or game compatible with Tecla will not only ensure people with mobility and/or visual impairments will be able to use it. It will also benefit all users in contexts where iOS® devices are controlled through alternative input devices (that is, anything other than the touchscreen). Examples include: access through external keyboards, game pads, joysticks, hands-free kits, automotive steering wheel controls, and networked appliances over ad-hoc networks (e.g., WiFi, UPnP, DLNA, etc.). Want to future proof your iOS® 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 devices with brain-implanted chips!
How to Make your App or Game Compatible with Tecla (and VoiceOver)
The context of switch access in iOS has been extremely inconsistent. Most currently available switch interfaces can only control apps that have been specifically designed to understand their commands. There is also little agreement on the specifications these interfaces should follow and, in most cases, developers are forced to code awkward work-arounds to read switch events. Tecla leverages the accessibility features built into iOS devices to provide universal switch access for people with mobility impairments. This not only means you can provide switch access to your applications using the standard features of the iOS platform, but you will also ensure your app can be used by millions of people with visual impairment.
Summary of benefits
- No need to buy a Tecla Shield to test switch access to your application, any external keyboard will do the job!
- Avoid using a hidden text box to intercept keyboard input.
- Integrate the Tecla Shield with your current scanning methods or use the built-in scanning feature.
- Let VoiceOver manage switch interaction for you.
Step 1: Make your app usable with an external keyboard
By far, the best way to ensure compatibility with the Tecla Shield for iOS devices is to make sure your app is fully usable with an external keyboard (e.g., Apple Wireless Keyboard) when VoiceOver is ON. VoiceOver is one of many in-built accessibility features of the iOS. Developers can learn about how to ensure their apps work well with VoiceOver on the accessibility section of the Apple developer portal. If you are not familiar with using VoiceOver with an external keyboard, please consider reviewing one of the many tutorials available online (e.g., Using an Apple Wireless Keyboard with VoiceOver on the iPad). The Tecla Shield uses the VoiceOver keyboard shortcuts listed below to achieve universal switch access to the iPhone and iPad. Make sure all features of your application can be reached using only these shortcuts when VoiceOver is ON:
- [Ctrl+Alt+Left] or [Ctrl+Alt+Right] focus prev/next element
- [Ctrl+Alt+Space] Activate highlighted element
- [Eject] Toggle on-screen keyboard on/off (when inside a editable textbox)
- [Esc] Go back a level or dismiss a pop-up
- [Ctrl+Alt+H] Home
- [Ctrl+Alt+S] Toggle speech output on/off
- [Ctrl+Alt+Up] or [Ctrl+Alt+Down] move to next/prev rotor option
Note: The last pair of commands (i.e., rotor-based navigation) are only available to users with 3 or more switches, so their use should be limited as much as possible.
Step 2: Review navigation consistency
When navigating iOS devices with a keyboard, the system displays a highlight (black bounding box) indicating which user interface control or view has the keyboard focus. This focus highlight allows keyboard users to explore the user interface without activating any controls. However, if your development has focused exclusively on a touch-based interaction, it is possible that, over time, a few kinks have been introduced preventing a smooth user experience for keyboard users. This is particularly possible if your app has custom views. In most cases, simple code tweaks will allow you to recover the full keyboard compatibility that all the built-in iOS controls and views offer. The most common issues with keyboard navigation consistency are:
- Scroll views that do not track the keyboard focus and respond accordingly, preventing keyboard users from accessing content not currently on the screen.
- Custom views that contain other views may be unnecessarily grabbing keyboard focus. An example of this may be a custom button where a container view is only used to draw a border while another view inside it is used to render the button’s label and perform the button’s action. In this case, the container view should not be keyboard focusable as it is only used for visual effect.
- Custom views that display pop-ups and other menus can disrupt the keyboard focus order, thus requiring keyboard users to cycle through the entire user interface before making it possible to focus on the elements displayed by the menu or pop-up.
Step 3 (Optional): Provide better focus highlighting
Step 4 (Optional): Review scanning consistency