The operating system Google Android is one of the most striking developments in the world of mobile technologies in their entire history, thanks to a unique marketing policy and a powerful technological base. In a short period, she captured one of the leading positions in the entire industry of mobile devices, having gone from an unknown novice to a trendsetter in several years.
It so happened that for various reasons, support for accessibility for users with physical disabilities at the start of Android was frankly failed, which subsequently forced the developers to implement this functionality using non-standard methods, which is why at the initial period it was seriously inferior to alternative operating systems in a number of aspects. systems. Nevertheless, from the very beginning, Android attracted interest, including blind people, therefore, by the time the relatively mature functionality of accessibility was established in this system, a significant, albeit heterogeneous, user experience had already been accumulated, which influenced, among other things, the development technological solutions.
All this led to the situation when the Android operating system, in the context of its non-visual use, went along two development paths, which can be conditionally called “isolation” and “integration of a” blind user “.
The opposition of these two concepts is generally characteristic of the field of adaptive technologies and not only them, therefore Android, in this case, only became a vivid illustration of the opposition of the existing paradigms of rehabilitation of persons with disabilities.
It is no secret that in the case of low technical literacy, a blind user, as a rule, prefers the isolation path, because with a superficial approach it is easier, and he does not have enough knowledge to assess the serious advantages of the integration option. But, unfortunately, many people who are formally professionals in the field of high-tech rehabilitation and who work in state and public structures that have the status of educational institutions for visually impaired people are adherents of the isolation path and actively promote this point of view to the masses of inexperienced users, not capable of “separating the wheat from the chaff”.
This material is devoted to a comprehensive coverage of both approaches to working in the Android OS environment and is intended to provide a comprehensive view of the use cases for this system. The information below is aimed at those real or potential Android users who want to have objective data without imposing one of the two technologies, which unjustifiably seemed to someone unambiguously more convenient or better because of his inability to master both.
The root cause of the problem
As noted above, the road to accessibility in Android was very thorny in the beginning. In essence, it was implemented on a leftover principle and at a rather leisurely pace, and in many respects on the basis of outsourcing, when the implementation was given over to the competence of third-party projects. For example, the TalkBack screen reader and the non-visual home screen Eyes-Free Shell were developed by almost the same team, but TalkBack is marketed under the Google brand. Inc. and integrated into the system, and Eyes-Free Shell is promoted under a separate brand Eyes-Free Project and actually has nothing to do with the built-in accessibility functions, although the ultimate goal for them was generally the same, namely, to ensure the non-visual accessibility of the common platform, only now it is completely in different ways.
Moreover, if we compare the technical solutions in the field of accessibility under the Google brand. Inc. and Eyes-Free Project, they are in many ways competing.
The principles of interaction with the device of a blind user are somewhat different from the generally accepted ones, therefore, to ensure acceptable accessibility of the operating system, it should be developed taking into account the concept called “universal design”. As Android experienced significant design versatility issues early on, there was a split in the technological concepts of accessibility.
On the one hand, attempts were made to ensure an acceptable level of accessibility of the standard interface of the system and its basic functions. On the other hand, without waiting for the universalization of the design, efforts were made to develop specialized solutions that were designed to replace the standard Android elements, providing the blind user with the same or even less functionality, but with a focus on his special needs.
The first path, user integration, assumed the development of the so-called accessibility layer, that is, a set of system-wide APIs and specific functional solutions focused on ensuring accessibility for users with disabilities. This area includes accessibility settings, global screen readers, and the UI automation models they use in their work, such as accessibility events or touch browse.
The second way, user isolation, assumed the development of the industry of local solutions designed to duplicate the standard functionality of the system, offering instead separate programs designed specifically for the blind and solving some particular problems. This area includes alternative home screens, often with a completely absent graphical interface, isolated working environments that duplicate the functionality of several basic system applications, as well as a set of separate application programs to compensate for some of the user’s physical dysfunctions.
As a result, two approaches to the use of the Android system were formed: work with the use of integrated solutions, when the principles of interaction with devices are as close as possible to the generally accepted ones, and work with the use of isolated solutions, when completely different principles of interaction with a device are used, and fundamentally inaccessible to sighted people.
Isolation approach
The user isolation approach is fairly straightforward.
A certain abstract blind user is taken with average statistical needs, which, for obvious reasons, are extremely basic. Further, the developer releases a product or several products that are designed to provide such a user with an adapted redundant solution for performing the indicated basic tasks.
As a result, the user gets, indeed, an affordable solution, but different from the standard approach to using Android, and, as a rule, with reduced functionality, in particular, with a missing or primitive graphical interface. In addition, such solutions cover only basic user tasks, without offering any solutions for using advanced functions.
The undoubted advantages here are adaptation to the needs of a blind user, ease of learning, bordering on primitivism, and also often familiarity, since solutions, in many cases, are developed taking into account the user experience of previous platforms.
Among the disadvantages is the lack of a universal design, when a solution available for a blind person may not be available (in whole or in part) to a sighted person, a radically different user experience, which makes all existing standard instructions and recommendations useless for a blind user, as well as a huge gap in functionality and often even performance, because specialized solutions cover only the most primitive functions of the system, plus not always in the optimal way.
Integration approach
The approach based on the principle of integrating a user with special needs is more complex, but objectively has great potential.
Within its framework, the standard interface and functionality of the operating system is developed taking into account their use in several ways, due to possible restrictions or simply human habits. And in cases where this is not possible, a functionality called “Accessibility” is built into the system, which is designed to compensate for the existing limitations of the user, for example, to provide him with the functionality of sounding the screen, outputting data to a tactile display, and so on, but in a way that minimally enters contrary to standard user experience.
As a result, the user also gets the accessibility of the device, but realized on the basis of the standard functions of the system, which makes it possible for him to get as close as possible to standard interaction scenarios and without significant efforts to work in cooperation with sighted colleagues, and to get access to the maximum number of system functions, in including high-tech.
The undoubted advantages here are the integration of the blind into the environment of ordinary users, which makes it useful (in whole or in part) for standard documentation and recommendations, for the blind to gain access to a significant amount of high-tech system functions, as well as an economic benefit, since he is often relieved of the need to purchase third-party specialized solutions.
Among the disadvantages can be called the often great difficulty of mastering, the different level of accessibility of the same tasks on different devices, due to the significant fragmentation of the Android OS, as well as the low level of design universality on relatively old versions of the system.
Typical interaction scenarios
Now let’s look at typical scenarios for interacting with a device within each of the two approaches. Basic tasks such as navigating menus and dialing a phone number will be discussed as examples.
Menu navigation
One of the more popular isolationist Android menu navigation solutions is the Eyes-Free Shell alternative home screen, which requires a separate installation. In addition, another solution of this kind is the Mobile Accessibility workspace.
Consider the task of launching the “YouTube” application.
- In the Eyes-Free Shell menu, set your finger to the center of the screen, move it to the “Applications” shortcut and lift your finger to open the list of all applications installed on the system. (taking into account the uncontested three movements with an amplitude of several centimeters, approximately 1.5 seconds are spent).
- On a physical or virtual keyboard, enter the letter “Y”, although many inexperienced users prefer to scroll through the entire list. Next, we find ourselves either on the “YouTube” item itself, or in its vicinity, where it is necessary to additionally set the focus to the desired shortcut by moving down. (depending on different implementation options, the time is from 3 seconds to 30 seconds and more).
- Double-tap to open or press Enter to activate the item. (about 0.5 seconds).
For Mobile Accessibility, the situation is similar, since it requires expanding the “Applications” item in the menu list, selecting “YouTube” from it, and activating the shortcut. Moreover, in the Mobile Accessibility menu, hotkeys for accelerated navigation of the Android system are not supported.
Thus, performing such an elementary operation with an isolationist approach requires an average of 5 seconds or more.
If the same problem is solved using standard system tools, then the performance is several times higher:
- We launch the “Search” function, which can be done either by pressing the appropriate key, or immediately by starting typing. (Depending on the Android shell, this can take anywhere from 0 to 0.5 seconds).
- We enter one or several first letters of the desired label and, by pressing down, go to the list of results, where we launch the desired item. (On average, one or two letters of the label name is enough, which generally takes about 1.5-2 seconds).
Thus, performing the same operation using standard Android interface elements will require an average of 1.5-2.5 seconds, which is 2-3 times more productive than the option using special solutions.
Dialing a number
Another popular solution among technical isolationists is Talking Dialer, a third-party dialer. An analogue of which is also included in Mobile Accessibility.
In general, the essence of this solution is to touch the screen with your finger, thus always hitting the number 5, then respectively move your finger to the adjacent virtual buttons and, releasing your finger, enter the numbers. In addition, since the first touch under the finger is always the number 5, it is advisable to return the finger on the next touch to the center of the screen.
Thus, the entry of each digit involves four movements with an amplitude of about 1-3 centimeters each.
The Mobile Accessibility option is generally similar, except that if you turn off the “Dynamic Keyboard” function, you can tap in the upper left corner to get straight to the number 1, not 5.
In addition, Talking Dialer is characterized by rough integration into the system, replacing other Android functions that are not at all related to dialing a number, for example, just the “Search” function.
If we consider the dialing alternative within the framework of the integration approach, then it is important to note that there are two options here:
- When using the touch screen (on Android 4.0 and higher), the difference in performance is not fundamental, and there is some gain only due to the fact that without installing Talking Dialer the user will definitely not lose other system functionality due to incorrect integration of this application into the system …
- However, when using a hardware keypad for dialing, the performance gain is more significant, since numbers are dialed not in four, but in three movements (touch, press and release), which, moreover, require less amplitudes of movement and provide tactile feedback. …
Thus, the difference in performance in this case exists only in the case of using a hardware keyboard, but it, in turn, also amounts to an increase of 2-3 times.
Conclusion
The Android operating system has gone through a difficult path of accessibility development, which has given rise to an alternative direction of accessibility, consisting in isolated low-functional solutions that were supposed to ensure the availability of its basic functions in the initial period, when the implementation of a universal design was openly stalled.
Each of the two approaches to working with Android has its own pros and cons, the acceptability of which for each user is determined individually, depending on his needs and ability to master highly functional technology.
However, it is important to understand that the way to isolate the user was only a consequence of the poor implementation of accessibility tools in older versions of Android (1.6-2.0), when the foundations for products such as Eyes-Free Shell or Talking Dialer were laid. Against the background of relatively modern editions of the system, they are only rudimentary functionality, since in most cases they do not have an objective need for use.
However, these solutions have the right to exist, but not in the general context of technical accessibility, but in the context of purely psychological accessibility, that is, if and only if their use is conditioned by the difficult susceptibility of a blind user to innovations.
Nevertheless, you should always consider both approaches and, moreover, tell the new user about their existence. Unfortunately, colossal problems arise with this in the Russian-speaking environment, since many people, some of whom carry out their “educational” activities even under the auspices of organizations officially involved in training blind people in information technology, clearly have insufficient qualifications, promoting only one of the approaches to work in the Android environment, moreover, it is isolationist, which is generally less functional and justified in a minority of cases.