Communications of the ACM
Why Is Accessibility So Hard?
I sometimes think that, of all the disciplines, ours ought to be the most effective at adapting to the varied needs of users, including those that are challenged to interact with computing systems in one way or another. From low to no vision, deafness or hearing loss to carpal tunnel syndrome and various other physical limitations, we really should be able to configure our software to adapt. And in many cases, some very useful, clever, and general-purpose software adaptations have been achieved. But the problem persists, and it is still not the case that one can hold high expectations of accessible adaptation for a random application that happens to become necessary or, at least, of high interest.
I think I understand some of the problem, but this column is an attempt to begin a dialogue about improving the state of accessibility in our field. This is not only important from the purely ethical perspective, but it is also pragmatic given the demographics of our society and the increasing incidence of need for accessible applications. We are an aging society and we are welcoming home many wounded warriors with the need for assistive response, to mention only two obvious beneficiary groups. One reason this seems to be so hard is that software has unlimited variations and interfaces to applications can take virtually any form. Moreover, we are extending the modalities of interaction to include speech, gestures, mice, touchscreens, other "pointers," keyboards, and so on. We have Web-based applications that take advantage of a wide range of presentation and interaction choices. Not all applications take into account the need to offer distinct and configurable user interfaces and even when some or many such adaptations are offered, some work a lot better than others. The other side of this equation is that the users also manifest unlimited variations in their abilities and it seems unlikely that programmers can be fully cognizant of the nuances of each.
Another theme is the proliferation of platforms through which we may interact with computer-based services and applications. It becomes increasingly difficult to design in detail every mode of interaction, including accessibility variations, for every platform and application imaginable. And even if our imaginations were that good, someone is bound to invent a new application requiring assistive responses that we have not thought about before.
One popular tactic has been to try to create general-purpose tools such as screen readers to assist blind users or automatic captions to help deaf users. Another tactic is to "parameterize" the interfaces so users can pick and choose the variations best suited to their needs. In my experience, the range of parameters devised is fairly large and it is easy to get lost in selecting configurations or even anticipating how well they will fit user needs. Still, these tactics seem important for practitioners to apply when appropriate. The challenges strike me as fundamental, given the range of needs and potential interface designs.
This is by no means a new problem. There cannot be much debate that programmers and user interface (UI) and experience (UX) experts need to think fairly broadly and deeply about potential use cases before settling on an interface design. While the use of libraries intended to confer "accessibility" on arbitrary applications may be helpful, it seems to me that no amount of automatic adapting will make a poorly designed interface accessible. For some of the same reasons that security ought to be "built in" to the initial design, so should accessibility. If UI designers had to try their designs while blindfolded or use their applications with the sound off, they might gain insights into the nuanced demands that accessibility places on good design.
One feature of good interface design is anticipating what the user is likely to need to do next and to prepare for that. A similar notion might inform thinking about accessibility. One is struck by the seemingly impossible challenge faced by blind users and UI designers for them. In the Web-based world, two-dimensional displays, touchscreens, popup windows, drop-down menus, color highlighting, and other signals seem utterly out of reach. One must think how a user interface will behave when it is serialized for audible presentation. In addition, consistency of format and audio feedback from screen to screen also seems like a helpful philosophy.
I would like very much to hear from ACM members, SIGs interested in this space, UX design experts, as well as users of accessibility features about their experiences and their ideas.a Somehow we must find ways to approach this problem with a richer combination of design principles, pragmatic tactics, and artful implementations than we have in hand today.
©2012 ACM 0001-0782/11/01 $15.00
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.
Comments
Samuel Thibault
Dear Vinton,
We (Sbastien Hinderer and Samuel Thibault) are two computer scientists involved in promoting accessibility and developing accessibility-related tools in the context of free software. Samuel is sighted and Sbastien is blind. Among other things, we work on BrlAPI, a client-server based protocol that lets applications take control of braille displays, and the accessibility of the Debian distribution.
We fully agree with your claim that computer science should be the field where accessibility works best. Indeed, there is no technical reason that makes it impossible, unlike in other fields, so that, according to us, if acccessibility does not occur, it is mostly for non-technical reasons. And that's where, in our opinion, things should start: making people understand that accessibility is both necessary for everybody and may even become a source of profit. Regarding its necessity, we think it is important to make people realize that accessibility is not only a matter of charity or ethics. Indeed, our experience shows that people often feel that accessibility is just a good action done by valid people towards handicaped people. We believe this to be naive, because those who don't need accessibility tools today will need them tomorrow, because of aging as you mentionned or because of temporary disabilities. Regarding accessibility as a source of profit, two points can be emphasized. First, at the commercial level, a company will obviously benefit from showing that it takes accessibility into account. Second, at a more technical level, experience shows that taking accessibility into account right from the beginning when building software or websites leads to results that are more structured and thus much easier to maintain on the long run. From this point of view, we believe that the great variability of interfaces you mention is not necessarily a problem and may even be a richness, provided that all the interfaces use standard protocols and file formats so that user can freely choose, among all the available interfaces, the one that fits best for her. That's why, along the accessibility of applications mentioned in your communication, we would add the accessibility of file formats and web sites and more generally accessibility of content. An application can indeed be seen as a bridge between user and content, so it won't be useful in any way if the content itself is not accessible. Coming back to the `plenty of interfaces' issue, we believe that a link can be established with maintainability. Indeed a software designed from the beginning to have several interfaces will naturally be designed in a much more structured way.
We do also agree with you about the tremendous diversity of users' needs and the impossibility for programmers to foresee and be aware of all of them. This is another argument in favour of well-structured applications based on a core able to communicate with several kinds of interfaces that can be combined, so that users can themselves build their solutions. In addition, we believe that a clever way to fill the users-pogrammers gap is to help those people who need accessibility to become programmers themselves. Here the example of BRLTTY (the Linux console screen reader) is interesting: many of its developers are blind and the tool turns out to be very adapted to the users' needs, in my experience more than tools developed with a bigger proportion of sighted programmers. To make it possible for users to also become programmers and designers of their own solutions, it is obviously required to also work on the accessibility of computer science courses, books, etc., which leads to working with publishers both at the technical and legal levels.
Regarding the generic screen readers you mention: we think they have both advantages and weaknesses. Indeed, they allow users to use applications which have no particular accessibility support, which is a strength. At the same time this can't always work this way and it seems suitable to provide a way to be accessible for those applications that want to do so, for instance Adobe has made this effort for his PDF Reader. This is precisely what has lead us to imagine and develop the BrlAPI protocol and architecture. On another hand, generic screen readers often include scripting facilities to change their behavior according to the application. This proved to be a very good idea, because it makes it possible for them to adapt to applications that would not be accessible otherwise. Such applications exist and are, as you underlined, rather widespread today and it is unfortunately unlikely that they will cease to exist in the near future. At least scripting allows to overcome the issue and permits to use these applications, which is much less work than reimplementing another, accessible version, of the application.
We think it is true that providing many settings to make an interface adapt to various needs may lead to cumbersome situations, but we also think there can't really be any other way. One remedy here could be to create a new area of expertise: helping users to build solutions best adapted to their needs. That could become a commercial service, which could be based on free software for instance.
We of course agree that accessibility can't be achieved in a completely automatic way and that automation will never manage to make a poorly-designed application accessible. Actually, making an application accessible consists for a fair part in designing it logically, without sticking the structure of the content to the rendering layout, which is actually good for general developement and maintenance too! We believe this message to be of crucial importance and, should we have to choose one to broadcast widely, that would definitely be this one, plus the motivations behind accessibility developed at the beginning of this e-mail.
It would certainly be a great thing if UI designers could test their interfaces in users' conditions. It is, however, often not very simple to achieve. In the case of a blind user, for example, this would indeed require the UI designer to master a screen reader, to have access to a braille device, etc. There are however some tools which already exist to check that at least the application content is available for instance. These should be advertised to developers. These things seem difficult to achieve, but there could be easier tests such as using an interface only with keyboard which seem both adequate and more realistic.
As you have written, the very notion of a 2D graphical interface poses accessibility issues, and should be serializable for e.g. speech synthesis. This should be done right from the widgets design, to make sure that each widget can be made representable other ways, at least linearly for instance. Then, an application is usually a 2D combination of these widgets, which would again need a to be serialized. This actually boils down to structuring the application in a logical way, as explained above.
Finally, there are a few points we would like to add to what you have said.
First, we think one should absolutely avoid the development of specific applications. They indeed prove to be not maintainable on the long run, because of the lack of ressources and people to do so. As a consequence, accessibility must as much as possible be integrated to the software used by everybody, rather than built in dedicated software that runs besides to mainstream software. This may sound obvious put that way, but our experience shows that many specific developments have happened in the past and all these specifically-developped applications happened to have died. If accessibility is properly integrated into existing operating systems, i.e. not only implemented, but also included in regression tests, documentation etc., the maintenance is handled by the operating system maintainers, and becomes sustainable. We have seen that happen in Debian.
Second, computers should as much as possible be accessible out of the box, without an administrator having to configure accessibility features. As surprising as it may sound, it is not uncommon that enabling accessibility for a blind user requires sighted assistance, which is of course not a good thing. As an example of this, a few years ago when Sbastien was using Windows, its installation program was not itself accessible. Windows had to be installed by a sighted person, and for several years even the installation of the screen reader needed to be done by a sighted user. Now this second step can normally be performed by a blind user, but that still feels uncomfortable given that, if something goes wrong, most probably the error messages won't be returned to the user. In comparison, the Debian installer is completely accessible, meaning that a blind user can be completely autonomous to install and use Debian.
This accessibility-from-startup line should also include boot loader accessibility (there is ongoing work on a GRUB+BRLTTY integration) and, even further down, BIOS accessibility which is unfortunately completely inexistent at the moment, except for servers which permit to access it through a serial console.
Accessibility out of the box also means for all systems. Ideally anybody should be able to use any computer. For instance, in a library or a computer science practice room, but also at home (who knows whether one would have to provide access to one's computer to a blind guest), the computers should be all ready to easily enable accessibility for any user who would need them. Just as an idea, there could be a standard way of storing accessibility parameters on a USB key, which the user would just have to insert into the computer to get accessibility features enabled just the way she needs it. Actually the very insertion of the USB key needs to be accessible, we have heard that the ISO is currently trying to write a standard about hardware accessibility.
Third, given that, as said earlier, it will always be difficult for a programmer to really understand the difficulties a user may encounter, one may bypass this "accessibility of accessibility" issue by trying to develop application accessibility guidelines similar in spirit to the Web Content Accessibility Guidelines created by the W3C. They would for instance include "the UI has to be usable without a mouse", which is easy to test.
And finally: the user-programer relation is already difficult when there is no handicap involved, the typical issue being that the programmer uses technical words that the user does not understand, and the user describes her issues in a vague way that the programmer does not understand. This becomes even more difficult in the presence of an handicap, since the user might not even see what she is doing, so there are even more words that she does not understand (icon? window?), and the description of the issue is typically even more vague. This situation is actually an argument against applications specially crafted for handicaped users: when it comes to getting help, it is difficult to find people who have already used these applications. This is also an argument if favor of a quite important point: even if the handicaped user uses a dedicated interface (e.g. braille), this interface should be very tightly synchronized with the standard interface, e.g. the focus should be the same, and browsing should be very similar and synchronized, so that a handicaped user and a non-handicaped helper or programmer can actually understand each other. For instance, the BRLTTY Linux console screen reader has a way to highlight on the screen the text portion currently shown on the braille display. This have proved to be extremely useful to be able to converse, a sort of "accessibility of accessibility".
In the end, people having both technical skills and a good understanding of accessibility issues are scarce and thus precious. The challenge is managing to establish a few-to-many knowledge transmission between developers.
CACM Administrator
The following letter was published in the Letters to the Editor in the July 2013 CACM (http://cacm.acm.org/magazines/2013/7/165490).
--CACM Administrator
We agree with Vinton G. Cerf's President's Letter "Why Is Accessibility So Hard?" (Nov. 2012) that computer science should be one field where accessibility is a given. Indeed, there is no technical reason accessibility should be impossible, and any lack of accessibility is likely due to non-technical reasons. People in and out of computer science should appreciate that accessibility is both necessary (people growing old is justification enough) and may also be a source of profit, as well as inspiration. Though an average programmer cannot anticipate all user needs, accessibility typically boils down to structuring the application logically rather than graphically, as in the structured Web pages of Cascading Style Sheets. Accounting for accessibility from the beginning of a development project is more likely to yield better, more maintainable software, a principle all programmers should learn.
Generic screen readers involve both advantages and weaknesses but permit access even to applications not designed to be accessible. However, such access does not always work as intended, especially with graphically designed applications, though scripting engines in screen readers make it possible to tune reader behavior; advanced users can write and share such scripts.
Multiple accessibility settings may be overwhelming for some users, despite their usefulness, in light of the diversity of user needs, but coping with them could constitute a completely new profession involving discussions with users and proposing and testing solutions in the search for optimal combinations.
Moreover, developing accessible substitutes for existing applications from scratch is not effective, as they are not sustainable over time due to lack of resources; we have seen several projects starve to death this way. Accessibility should be integrated into the entire user software stack, not just alongside it; accessibility would thus be sustainable, as with internationalization and security. When an API is available, users themselves would be able to write dedicated interfaces to access shared software. We have seen such arrangements work very well, though having users write their own code depends on making computer science education itself more accessible.
Finally, accessibility should be delivered out of the box, on all computers in the wild, waiting to be triggered, including their hardware, BIOS, boot-loader, and OS installer; for example, the Debian Linux installer includes a speech synthesizer that should be generalized to all operating systems.
Sbastien Hinderer
Nancy, France
Samuel Thibault
Bordeaux, France
Displaying comments 21 - 22 of 22 in total