Mobile Accessibility Challenges
From Mobile Accessibility Task Force
What challenges do companies face with mobile accessibility and what mobile accessibility information is not available?
Contents
Challenges
- Libraries are large and takes a lot of bandwidth
- Custom widgets are challenge
- Different interaction paradigm (no longer keyboard focused)
- Touch area (size)
- Testing is complex - many combinations and variations
- Baseline needs to be defined and whether or not this is sufficient
- Consider browsers, OS version, AT and combinations of AT usage
- Keyboard interfaces are built into iOS, Android (dPad), and Windows Phone (starting with 8.1) / Windows 8
- Developers are forgetting that they are there
- Even if it is keyboard accessible, touch vs. mouse cause usability problems
- Also speech control is not really available
- Developers need requirements and guidelines to code apps to
- Actual devices are required for testing as virtual device emulators (DeviceAnywhere, etc.) do not support gestures or Bluetooth keyboards
- iOS Read all from current location or from top read things differently than touch and explore
- Many developers are unfamiliar with Accessibility coding requirements
- 3rd party development tools that allow "one code" for multiple native apps often do not support accessibility constructs for the supported OS's
- Companies feel WCAG 2.0 is only for web and are not on board with Mobile APP Accessibility as just as important
- Development for separate platform, and identification of what the features of the different mobile platform are, so people can make good choices
- Feature Conflict
- The browsers may want to implement things ahead. When do you remove a feature that has been put into the OS?
- The 3rd party suppliers say that there are no standards for mobile, so they feel that WCAG doesn't apply to mobile devices, and therefore they don't have to do it.
- Lack of call from disability groups for mobile apps to be made accessible. That lack of call from the market, makes vendors think there is no need.
- Lack of data on the use of mobile devices for people with disabilities
- Zoom functions usually lead to views with blurred edges (of text)
- What do you support – make sure people with disabilities can develop, enable themselves
- Color contrast not well supported across platforms
- Cannot increase font size to 200% on iOS and Android (or only for those elements within apps that support dynamic text)
- No conventions exist where and how to set the visible frame when changing between views/screens in apps
- Platform zoom defaults when changing views often not optimal ('zoom out' on Android requiring new zoom in, 'leave at same position' at Windows Phone with often sub-optimal results such as 'sea of black' views)
- Built-in zoom functions on mobile platforms often lack intelligent re-framing (such as resetting the position of the visible frame to include focused element) - currently only available in iOS 7.1 with VoiceOver on
Customisation Options
- Zoom customisation
- Lack of customisation options regarding the handling of zoom (zoom state, frame position) when calling up apps or screens/ views within apps or refocusing via swipe gestures or keyboard
- Lack of customisation options for follow-focus when using screenreader and zoom simultaneously
- Text customisation
- Existing text size customisation options such miss crucial elements on system views (app icon legends) and in apps
- Bold text option currently only available on iOS 7
- Contrast customisation
- User selectable high contrast colour schemes currently only available on Windows 8 touch devices
- Available contrast settings such as inverted views on iOS and some Android skis such as Touchwiz (Samsung) ) cannot compensate poor text contrast
- Inverted views not intelligent as they include elements that should usually not be inverted (images) - should be customisable to restrict inversion to text
- Virtual keyboard customisation
- No option to exclude keyboard from zoom on iOS ? Windows Phone 8, Windows 8
- No option to include keyboard in zoom on Android
- No independent settings for increasing text size, weight or contrast of keys in virtual keyboards (sorely needed on some Android skins)
- Screen readers
- Turning the screenreader on / off dependent on situated need is cumbersome on Android (no two-way shortcut as on iOS)
Missing Information
- Conflicting information: developing for the different platforms/devices have different guidelines. There are no standards across all platforms.
- For example, touch size differs in their recommendations. MIT did a touch study
- Problems getting a Bluetooth keyboard to work
- Blind users do not have information on how to set up the phone to get it to work
- Needs to be guidance on how to set up the AT and other keyboards etc.
- Information difficult to find
- Very few examples
- Not a lot of examples of sites and applications that are accessible
- ARIA is mature on the desktop but not on mobile
- Landmarks are not specified
- Some ARIA not supported at all (e.g. grid)
- Mobile gestures and the changes when AT is enabled
- Different from keyboard and Bluetooth keyboard support is an issue
- Keyboard events do not exist; may be due to touch interface
- Need to have different widgets for different contexts
- Key is to have items in sequential order; apps are easier than responsive/mobile websites
- Developers do not see standards for mobile therefore they don't think it applies
- Websites vs. mobile apps
Mobile Accessibility Challenges Discussions Elsewhere
- CSUN 2013 Mobile Accessibility Challenges Panels Source: IBM
- Research Report on Mobile Web Accessibility Source: W3C
- Android Accessibility Interest Group Source: LinkedIn