meta data for this page
Table of Contents
Mobian has great potential as an accessible mobile operating system. It is user-modifiable, and based on the Debian distribution (which is reasonably accessible).
Accessibility on Mobian is currently poor. Mobian has not yet developed a policy on accessibility standards or tests (manual or automated), and much of the software shows no evidence of accessibility design or testing. In some cases, programs that are accessible on desktop have had their accessibility broken when adapting for mobile use. Responsibility for accessibility seems to lie with developers of individual programs.
If Mobian can be made accessible enough to attract users with disabilities, it will also attract developers with an interest in accessibility, including developers with disabilities. This will make it easier for Mobian to stay accessible and develop new ways of using mobiles.
The biggest group of people currently acquiring cellphones are poorer people in the developing world, many of them illiterate. Free software has major advantages here: there's a strong interest in low-cost and non-exploitative software (see the debate in India over Facebook Zero). If interfaces can be made usable to those with low or no literacy, they can teach literacy and give access to education.
However, people who need these features are unlikely to contribute to Mobian until they've learned enough that they don't need them anymore. People developing Mobian may have difficulty designing for those who can't read. A mojibake/text-garbling tool might help with testing, but changing the language to one with a character set the tester can't read will work to the extent that the UI has been translated.
Useful techniques include screenreading (with syllables highlighted as they are read), good cut-and-paste facilities, culturally-neutral icons, and dual encoding (for instance, standard textual messages or menu items that can be identified by their color or an accompanying image). These also help those who can read but have difficulties recognizing words. Voice assistants can also be helpful.
There is strong overlap between vision-disability and low-literacy accessibility. Parallel sound and text also improve comprehension in those with full sight and excellent literacy, and make audiovisual content accessible to those with impaired hearing.
Clarifying visual elements
Screen magnifiers exist on Debian, and text-size adjustments have been improving rapidly (probably partly because of the increased range in screen sizes and distances). Accessibility for those with impaired vision (fuzzy vision, very narrow field of view, etc.) often overlaps with the modifications needed to make software work on mobiles. Doing both these adaptations simultaneously will make both easier and cleaner.
Colorblindness is mostly reasonably-well accommodated, with the default colors being colorblindness-safe. Icons need testing to ensure that they are intelligible and distinct with all the common varieties of colorblindness. As over one in twenty developers of Mobian are expected to be colorblind, user testing should be fairly easy, but bear in mind that no-one is going to spontaneously inform someone of the presence of some feature they can't see. Colorblindness-mimicking filters can also be a useful development tool.
To be tested: low-vision accessibility of Mobian with an external keyboard.
Replacing visual elements
You can, of course, type “sudo apt-get install orca” in the King's Cross terminal, and the screenreader will install. Unfortunately, most of the apps do nothing with it. There is no way to browse the app drawer; launching or closing an app is completely silent. Most of the apps are also silent (or the parts that were modified for mobile are). Even the flashlight, which would only need to say “flashlight on” and “flashlight off”, operates in utter silence. The terminal itself is almost functional; it does screenread its contents (and there are other, specialized screenreaders available for terminals).
The Squeekboard keyboard likewise almost works; it does speak aloud each button as you press it, but for most, not all buttons, and there is no sound indication when you change to the numeric or control-character mode. While the terminal-style keyboard has things like arrow keys (very narrow and hard to hit) and a tab key, it is impossible to use these to navigate between fields in an application, as you can do on desktops. The button to launch and hide the keyboard in the bottom-right corner is excellent and can easily be located by touch alone, but there is no sound indication when the keyboard launches or closes.
Handwriting/gesture recognition is an alternative to a keyboard. See the section on motor disabilities below. Voice assistants can also be use for command and text entry.
To be tested: no-vision accessibility of Mobian with an external keyboard (and with external Braille readers, though many people can't afford those).
Better Debian-licensing-compatible synthesized voices would be useful, especially for those who have hearing impairments and find some types of voices unintelligible. More diverse voices, with a variety of formant frequencies, languages and dialects, are needed. For instance, female voices and voices speaking Indian English or non-English languages are rare in FOSS software.
The Festival and Festvox speech synthesis programs release their synthetic voices and software under Debian-compatible licenses, and likewise their instructions for making your own synthesized voice (overview). The GPL2 Praat does speech analysis and synthesis, too. More recently, the company VocaliD was working on a phone app that will allow people to donate their voices for blending into synthesized voices; unfortunately, their “The Human Voicebank Initiative” seems to be closed-source and proprietary.
Gamifying the voice-model recording and/or voice-creation process for mobiles, which have good microphones, would improve speech synthesis on all Debian systems, and allow people with speech impairments to design their own voice and carry it on their mobile. It is currently common for people to choose prosthetic voices from a small set that do not match even their gender and national dialect. Conversations between people using copies of the same synthetic voice are less intelligible.
The UI of Mobian is predominantly visual, so accessibility here is fairly good. The ability to adjust the sound output could be very useful. For instance, being able to adjust the output frequency curves, in the same way you can adjust the brightness curves in a graphics-editing program, can compensate for frequency-specific losses of hearing acuity. Losing the ability to hear some pitches is common with age and some forms of injury and congenital hearing loss.
Many of the messaging apps can do video calls as well as sound-only calls and text communications. Would TTY integration with the conventional phone network be useful?
A larger variety of synthesized voices would also be useful (see section above).
It can be difficult to touch small-area buttons even without a motor disability. Alternate versions of the keyboard and some apps are required for accessibility here. The ability to plug in any external keyboard is very useful. Accepting a broad range of unusual and non-standard keyboards, mice, and other character- and spatial-entry tools is important. More-portable input devices are practical for actual mobile use.
Gesture recognition is already used in the UI (for instance, for closing apps). The use of the front camera as a a head-direction mouse is possible using Eviacam, but adaptation may be needed for the small screen (not tested – TODO). Handwriting recognition, as on the old Palm Pilots, is a keyboard alternative which may be easier for some people. The “wayv” package may be useful here.