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 firstname.lastname@example.org or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.
See also ACM's sigACCESS , the ASSETS 2012 conference (taking place this week) , the excellent work of the W3C's Web Accessibility Initiative , the W3C's Web Content Accessibility Guidelines , the User Agent Accessibility Guidelines , the Authoring Tools Accessibility Guidelines , the W3C R&D Working Group , the International Conference on Computers Helping People with Special Needs , the CSUN Conference on Technology and Disabilities , the US Government's Section 508 , etc.
There is significant research, standards, and development effort focused on accessibility, not to mention legal requirements. The real challenge is educating the IT community about accessibility, and in incorporating accessibility as a core component of the CS curriculum.
Markku, thank you for this excellent set of references to accessibility documentation and the references to groups active in this area.
Thank you for causing this conversation. I am responding from the perspective both as someone who works and lives in the digital accessibility space, and as someone who happens to also have a disability. The good news is, based on my interaction with designers, developers, UX and other folks, both over social media channels and at various events over the last number of years, there is definitely a want to make the web, mobile apps and other technology accessible. When I ask why accessibility was not implemented, What I often hear most are things like: "The client didn't want to pay for it," and/or "There was no time to do it."
I am a pragmatic person, so if you asked me what needs to happen, it would include, in no particular order:
- companies at the highest level need to publicly champion and articulate via policy that accessibility must be a requirement during design, development, testing, and maintenance phases of an initiative;
- accessibility needs to be explicitly baked into project management, requirements gathering, SDLC, procurement and any other relevant IT and business processes behind getting a product into production (and maintaining it over time) so that all parties involved have to own and account for accessibility based on their role, from the outset (shared responsibility);
- companies committed to accessibility need to invest in ongoing accessibility training for and research to support designers, developers, QA and other IT folks so that accessibility becomes a shared responsibility that everyone is knowledgeable about;
- accessibility must be naturally and necessarily included as part of the day-to-day strategic conversations that happen around drawing-up IT roadmaps, as well as decision-making when it comes to investing in and using the "next best" technologies/platforms so that informed decisions can be made;
- as best possible, users with disabilities need to be included as part of testing during the early prototype stage (when there is an opportunity to influence design choices), straight through to UAT;
- accessibility must be raised during early client conversations to educate and to sell it so that appropriate funding can be put in place; and
- teams/individuals need to be rewarded and recognized for excellence in accessibility, similar to how they are in other areas in order to provide incentive to raise the bar even higher.
I know that none of this happens over night. I also know that many designers and developers are ready and wanting to include accessibility, if they are given the appropriate time, support and tools to do it. That said, I firmly believe that accessibility injected into a company's people, processes, and technology is fundamental to moving things to the point where making digital accessibility is part of business as usual.
Dear Mr. Cerf:
Thank you for starting this topic and I hope this letter will at least partially answer to your question why accessibility is so hard. I am writing you as someone who played with computers since high school, who works professionally in the CS (primarily software development) and ICT fields in Serbia and US since 1986, and who deals personally and professionally with horror of gradually losing eye sight since 1994. Also I am writing you from a position of pro-bono Vice President of Foundation of Paralympic Committee of Serbia (http://www.paralympicfund.org), a non-profit organization that financially supports Serbian athletes with disabilities. My personal and professional experience makes me doubt that folks with disabilities will ever be accepted in the society as equal. However, this does not preclude me to run on wind mills like Don Quixote and promote accessibility wherever I can and whenever I can even with simple instructions on web accessibility (http://www.dragomirdimitrijevic.rs/accessibility) or my pro-bono work to help Serbian athletes with disabilities.
First, as some 2% of population is visually impaired, we have to accept a simple fact that people with disabilities are not economically viable group and development of accessible products is expensive for greed of today’s Wall Street bankers. For example, in 1996 I purchased for $9.99 a talking watch for my three-year-old son wit intention to teach him about time. Later, I found similar watches designated for blind people and they were some 10 times more expensive, probably because designation to blind people would detract visually abled buyers. Also, commercial screen readers are more expensive than software products of similar complexity, probably due smaller target group of customers. Products of such nature must be free of charge. So it remains to be seen at these trying times of austerity measures and budget cuts if needs of people with disabilities will become even greater collateral damage.
Second, 2% of visually disabled are not politically viable as a voting group. Politicians spend on them time just sufficient to finish foto-ops during election campaigns, the same amount of time they spend on patting pets on the next campaign stop. On the other hand, 2% of blind folks mean 5 out of 250 representatives in Serbian parliament, 2 out of 100 senators and 8-9 out of 437 representatives in the US Congress. Do you know anyone ever?
As the consequence of the above, people with disabilities are pushed on the margins of life and are left alone to handle their problem on their own. I have personally experienced uselessness of “Americans with Disabilities Act” in US and similar legal hoaxes in Serbia both in my personal and in my professional life. All of blind folks I know work either in some kind of governmental social services for the blind or are in ghettos of NGOs for the blind. Although if you are a software developer, having heart decease is more serious problem than being blind, you will have no problem to find the job with an ailing heart opposed to ailing eye sight. Just one of numerous examples in US is that, when prospective employer was excited how quickly I solved some stupid test, they asked my headhunter to find them somebody just like me. Of course the other unspoken requirement was that the person should not have problems with eyes. Or when I applied for a position at a university in Serbia, bringing with me numerous publications in respected international professional journals and conferences, the first question the professor who interviewed me was “I know this should not be asked but I am asking anyway. What is going on whit your eye-sight?” and that was the beginning and the end of interview. So the only remaining thing is to dig in and surround yourself with a small number of trusted partners who will treat you with dignity and respect and even send you for your review of graphic files and pictures that you will comment with a little help of your household members.
Years ago, I used JDeveloper and I contacted Oracle to help me to set-up IDE for accessibility. The person there was really helpful and cared and, although he did not tell me, I sensed he was blind and really understood my needs. I asked him how many blind people he is in touch with so I can get some feeling how many blind software developers are out there. As this department was supposed to be the focal point of interest of blind developers, the answer was disappointing although not surprising:
‘...Actually, you are only one of a couple of blind folks who have actually tried JDeveloper that I know of. I was in communication with a gentleman from the U.S. navy, but the security issues with getting jdeveloper upgraded and the accessbridge upgraded made it impracticle for him to use jdeveloper...”.
I have no problems with using JDeveloper and NetBeans and I am sure he would be in touch with many more blind software developers if their number is anywhere near 2% of all Java developers or users of JDeveloper in particular.
Recently I attended Nokia’s software development webinar. While demonstrating creation of menus with graphic buttons, the presenter orderly defined an array of images for graphic buttons while savagely assigning null to the corresponding array of strings that are used by screen readers to verbally announce presence of the buttons. I barked a complaint and I am sure this omission will not be repeated since the webinar organizer promised to pass comment higher up as it turned out that his wife is visually disabled.
How deep misunderstanding of visually abled developers is tells me an anecdote when one blind person helped as a consultant a company here in Serbia during development of a Serbian speech synthesizer. The visually abled developer was not able to understand problems wit usability of the software installation procedure and the blind consultant finally turned off the monitor and told the developer to complete the installation. The developer jumped and said “But I don’t see anything.”.
I served as an advisor during the redesign of web site of KBC Bezanijska Kosa Medical Center - one of the first Serbian web sites adjusted for the blind. I wrote detailed instructions for web designers with intention to educate them for the future. The site was opened with great media coverage. Years later, I found that accessibility was gone and all that love and care for people with disabilities was just a fake marketing ploy. I hope that my cooperation with web developers of IBSA - International Blind Sports Federation’s site (http://www.ibsasports.org) will have longer lasting effects as it is an organization specialized for the blind.
How far misconception of the blind goes tells my regular situation in public transportation when people insist to give me their seat as if I have problems with legs. Due my practice in the gym, my legs are in much better shape then most of theirs and I just want to hang on to the bar in the crowded bus until I arrive to my destination.
My personal and professional experience on the topic would probably fill couple of CACM issues. To cut the long story short, legal basis is cast in constitutions, of most countries, in “Americans with Disabilities Act” and other legal hoaxes. They just have to be applied. Technical basis like W3C recommendations and Java Accessibility Bridge are available. They just have to be applied. The real problem is in human heads and acceptance of people who are slightly different. The right place to start is kindergartens. We have to teach kids that the fact that their little friends next to them are blind is just one of many human features like hair color or height. Then may be, just may be, in 15 or 20 years we will have the first generation of people who will treat with dignity and respect their fellow human beings with disabilities. The only problem is how we, who do not treat them with dignity and respect, can teach our kids to do so.
Dr. Dragomir D. Dimitrijevic
It makes me very happy to see that you are becoming interested in accessibility.
In addition to those made by Markku, another important recommendation is WAI-ARIA: http://www.w3.org/WAI/intro/aria
And WCAG 2.0 is now an ISO / IEC 40500:2012: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=58625
And since Google provides authoring applications, it is important that these applications support accessibility preventing the user generated content inaccessible or at least alerting them to the possible consequences. For example, in the blog would be appreciated that when the user inserts an image interface alert you about the importance of adding an alternative text.
Regards from the Fundación Los Álamos and the Fundación Sidar ;-)
Emmanuelle Gutiérrez y Restrepo
Fundación Sidar - Acceso Universal
While on the topic of accessibility, there is room for improvement in the realm of communications from professionals in all fields, especially highly technical fields.
The use of passive-voice and using verbs as nouns creates writing that is a pain to read. There is brilliance in simplicity. Many topics are artificially(Intentionally??) more complicated than necessary. This alienate's the audience.
I think the major problem is that people think they sound "smart" when they mimic the writing style of 100 year old academic journals.
Accessibility is of little concern for many IT professionals. This should really be a top priority. Take a Marketing 101 course and learn how to adopt a customer(or audience) centered mindset. It will improve the quality of your work and your communications.
Absolutely agree with Dr. Dragomir Dimitrijevic that interest in accessibility was lost somewhere
in run for money driven by greed.
Amit Vujic, BSc
CEO & Software Architect
ePlus Systems LTD
We know you are most knowledgeable about this for so many years, and we can only add the obvious omission from all the good technology points made so far: the stigma of difference (disability) limits attention to and adaptation for access.
Stigma does not fade easily or gently. Most do not understand what or why accessibility is worthy, vital and right. The stigma (a group or societal dynamic) will not change significantly until "able" influential members of society, and "able" powerful corporations, champion difference and inclusion as a primary human value. Then access and technological innovation will follow.
I'm glad you started this dialog; it's an important one. I'm going to speak of web accessibility, because this is where my background is.
The answer is simple, education, which is at the root of all accessibility issues on the web.
When you say 'While the use of libraries intended to confer "accessibility" on arbitrary
applications may be helpful', this actually does more harm than good. This means that people who understand accessibility attempt to retrofit inaccessible applications that have already been made and released by people who don't understand accessibility, which is a never ending cycle of bad programming.
A huge part of this, is that many educational materials include advice that is totally contradictory to accessible user interface design, and often include best practices that are blatantly inaccessible. Developers learn these techniques, and then apply them within enterprise applications, and are then shocked when none of them are accessible. This also causes bad programming implementations to proliferate across the web in the name of accessibility.
Another problem is that there is a huge amount of contradictory information regarding accessible programming techniques circulating around the web, and they may or may not be accurate. When many developers realize that their applications aren't accessible, they Google it, typically land on ARIA, then start sticking ARIA attributes into the application and assume that this makes the feature accessible. It does not. If the scripting behavior doesn't exactly match the ARIA attributes for a particular widget, and if the correct ARIA attributes are not applied to the correct DOM nodes, the feature will not work accessibly regardless.
There is a perfect example of this very situation at
On this page is an ARIA Tree control, which is necessary to navigate between the various widget examples that are showcased on the page. This ARIA Tree control is not properly formed using the correct ARIA attributes on the correct DOM nodes, nor is the scripting used to move focus appropriately so that it matches the ARIA markup. As a result, the control is 100% inaccessible for both JAWS and NVDA users in both IE and Firefox.
This is important, because this ARIA Tree control is part of GWT (Google Web Toolkit), and is being promoted as an ARIA compliant widget for use in all enterprise applications that use the GWT framework. Meaning that tens of thousands of companies are using the same control in their applications, and assuming that it is fully accessible, which it is not. I've also seen this inaccessible control used on Google Groups, Google Profile, AdSense, AdWords, YouTube, just to name a few.
Another problem is lethargy. For example, I sent precise instructions to Google regarding this ARIA Tree control, detailing where the ARIA attributes were not properly applied and why the scripting wasn't in sync with the widget behavior, thus causing it to be inaccessible. This was months ago, and nothing was done. I'm not speaking hypothetically either, I even referenced the following ARIA Tree control that is 100% accessible in both JAWS and NVDA using both IE and Firefox, at
in the same message I sent to Google.
I realized four years ago, that the only way that the future of accessible web technologies would be assured, would be to quantify Accessibility as a programming discipline that engineers could learn while being educated.
So I educated myself, spent years researching Assistive Technology interaction in various browsers, and then built AccDC at
In order to provide a free resource for international businesses, organizations, and universities, to educate current and future developers regarding accessible programming practices, and to provide scalable functionality templates for all complex interactive component types. The goal, to establish reliable and fully accessible programmatic baselines for web technologies.
Also, AccDC and all of the WhatSock functionality templates have been thoroughly tested to ensure complete WCAG compliance, have passed full Section-508 compliance, and was awarded the Above and Beyond Accessibility Award by the United States Department of Labor.
Accessibility isn't hard. It takes discipline, knowledge, and comprehensive testing to get right, which are all part of the educational process.
I know all of these things from experience. In addition to being the Founder and only developer of WhatSock.com, I have also been totally blind since 1994, and have never physically seen a web page. I taught myself how to be a web developer using geometry, because it was the only option I had to do so.
Hopefully this information will be helpful to others in the future.
Great point about guiding users to provide accessible user-generated content, Emmanuelle. Blogger and Google Docs should have an "alternative description" field in the image inserting dialog, as WordPress has. But that's not enough: many WordPress users merrily leave that field empty, even when they insert text images, resulting in an empty alt attribute.
So maybe, when they attempt to do that, there should be a pop-up message saying: "You didn't give an alternative description for this picture. Are you sure it conveys no information?" with Yes and No links below. If they click No, the message changes to "Then go back to the image inserting and fill that description, please." If they click Yes, the message changes to "No go. I'm not going to let you clutter my server with meaningless pictures."
And there could be similar warnings for other inaccessible things that users may be tempted to do, like embedding a caption-less video or one of those zany flash viewers produced from a sane(r) textual PDF.