Go to previous article
Go to next article
Return to 1999 Conference Table of Contents
M. F. Cabrera
6COCEMFE, Ríos Rosas 54 - A- Bajo Ctro, 28003, Madrid, Spain
tel: + 34-1-535 06 19, fax: + 34-1-535 02 86
This article presents the two new Spanish standards on hardware and software accessibility. It outlines a brief explanation of the main ideas contained in over 140 individual requirements that indicate conditions to be fulfilled by hardware and software vendors to make their products accessible to handicapped people. It explains the importance of using formal standards and the approach used to develop them.
As we move closer to the 21st century, our society has evolved from industrial technology to information technology. This change is deeply affecting our society, our politics and our economy and people of all kind and origin should be ready to embrace, use and enjoy this new paradigm. In order to avoid the same error committed by architects, who have unconsciously confined handicapped people along the 20th century building all kinds of physical barriers, computer hardware and software vendors and developers should be aware of the accessibility problems their technology is introducing for people with disabilities.
A group of Spanish experts has been working during the last years to compile and study the different accessibility problems that computer platforms pose to people with every kind of disability.
Usual accessibility problems for blind people are derived from not being able to obtain information provided by visual presentation. They are therefore obliged to use "screen readers", an assistive software capable of reading the screen content and status to a Braille system or to a speech syntethizer.
People with low vision have, on the other hand, color perception problems, impaired contrast sensitivity, and loss of depth of perception. Their accessibility solution comes from being able to change the size, colors and contrast of the screen contents.
Hearing impaired people are not able to discriminate frequency changes, locate sounds and distinguish sounds on a background noise. Using visual clues to represent sounds on the screen is sometimes enough to overcome their problems.
Deaf people, in addition to the problems of the hearing impaired, may not able to produce speech recognizable by voice recognition systems, and usually have their countries' language as a second language, since the sign language is their first. This causes learning problems and hinders interaction with computer systems.
Accessibility problems commonly faced by users who have physical impairments are often a consequence of physical limitations such as poor coordination, weakness, difficulty reaching, and inability to move a limb. Their problems and solutions are too broad to be stated here, but a good tip is to have as many parts of the system software controlled, so that no direct manipulation of physical devices is needed, except for user standard input (e. g keyboard). That way, once the keyboard is replaced by an appropriate solution, the user can manage the whole system.
People with learning impairments typically face a rather complex system interface that prevents a better use of the system. Using simplified interfaces is thought to be the best solution to eliminate this barrier.
Traditionally, accessibility solutions have been oriented to assistive external devices that could be connected to standard computer systems to overcome accessibility issues. Nowadays, following the design for all principles, efforts are mainly directed towards including accessibility aids in standard systems (hardware and software) in a way that every person will be able to effectively use an off-the-shelf computer system regardless of his/her disability.
This Spanish working team on computer accessibility used this approach as a base, and together with a strong user interface orientation (versus a computer systems orientation) have been the lead on case studies and document generation. This means that efforts have been directed to stating what has to be done to improve accessibility in system user interfaces, and not to how this has to be done, in order to allow and promote different solutions to the same problem.
Several technical documents have been written in different places of Europe and US, and some of them have been quite successful in providing vendors with the right accessibility rules, but these documents lack a formal structure needed to grant feasible compliance.
In order to achieve this feasibility, formal procedures must be established so that requirements are not subject to changes very often, making it impossible to fulfill them at a given time. Nevertheless this set of requirements should be "alive" in order to cope with every possible accessibility problem that may appear on the ever moving computing world.
On this basis, an Experimental Standard of a national standardization body has been found to be the best solution combining formal frame steadiness and periodical review.
Furthermore, a formal standard can be used as basis for legal regulations if these were needed, and can be propagated to international and world wide level, guaranteeing the participation of all parties affected by the process (vendors, user organizations, developers, etc.) in any place, any time (provided it's time for a review).
Accessibility to computers has traditionally been achieved through special hardware devices, such as headsticks, special keyboards, modified mice, etc. Although quite effective this approach is limited by the intrinsic accessibility problems generated by the software itself. For example, a user of a special keyboard, who cannot use the mouse, will never be able to use a drawing program that uses an "only mouse" approach to some of its features. This problem can be overcome by installing a mouse emulation program that can be used with the adapted keyboard, but in many cases compatibility issues make this approach fail.
The Spanish standards deal with accessibility issues related to computer platforms built-in features, such as operating system's keyboard and mouse emulation, show-sounds features, keyboard configuration, hardware controls, etc. External adaptive technologies, as explained before, are not considered in the standards
After a few tryouts, it became obvious that a better, easier to read, and more compact document would be achieved if accessibility problems would be treated separately, and the various disabilities affected by the accessibility problems would be designated in each entry. Therefore, each standard entry or element states a requirement to overcome an accessibility problem and indicates the disabilities affected by the requirement.
Disabilities contemplated in the standard include blindness, visual impairment, deafness, hearing impairment, and physical and learning impairments.
In the hardware standard, requirements are stated for the different physical devices that usually conform a computer platform:
There are also accessibility requirements for the accompanying documentation.
An exhaustive description of the 47 accessibility requirements is out of the scope of this article, therefore just a brief overview of the ideas contained in the standard is given below.
The set of requirements states that most hardware controls (switches, regulators, etc.) are hard to operate, specially for people with physical impairments, and should therefore be software controlled, allowing full equipment control from the standard input. All controls should be placed in the front part of the equipment, making them easier to reach, and they should avoid complex operations, such as holding two controls pressed at the same time. They also should be large enough and provide tactile feedback. Labels associated to controls should be readable for people with vision impairments, both providing Braille and big font alternatives and by making them distinguishable by touch.
All elements such as screen, keyboard and mouse should be independent from the central unit, allowing their substitution for adapted ones, such as bigger screens for the visually impaired or trackballs instead of mice for people with trouble in their hands.
For deaf people, regular systems sounds such as printer, disk or startup noises should be visually displayed to make sure they can react to them. Speakers should be located in the front part of the computer and should allow volume regulation.
Printers and scanners should allow easy paper feeding, avoiding unnecessary lids that make the task of extracting and inserting paper difficult.
The first problem encountered when facing the software standard was how to divide the software multiple layers in order to obtain an effective approach. The following division was made, trying to obtain a clear division for software vendors and developers to know what would affect them, rather than to establish a standard division that could be used for other purposes on general computing.
The division is as follows:
An exhaustive description of the 106 accessibility requirements is out of the scope of this article, therefore just a brief overview of the ideas contained in the standard is given below, with a very scarce rationale due to space constraints.
The operating environment is the base for the rest of software, and therefore is required to provide as many mechanisms and services as possible that can make accessibility an easy to build task. Some of this mechanisms and services include keyboard emulation by mouse, mouse emulation by keyboard, voice command and control, switch control, audio output services, user interface status and data structure memory representation, etc.
All these services and mechanisms can and must be used by other applications to attain better accessibility, although the use of special accessibility services (e. g. voice output) should be selectable by user and easily deselected.
All messages issued by the system should be consistent in position, layout and semantics, should be simple and should always wait for user validation. Information presented in the screen should have no semantics supported by colors, to avoid problems with color blind people. Furthermore, text messages should also be sent via audio, and vice versa.
Texts should be drawn in screen using text drawing services, avoiding the use of graphics to embed them. This way blind users with screen readers will always have access to information.
Menus should be circular (first item selected after last, and vice versa), keyboard accessible, and provide consistent shortcuts where possible. Consistency must be maintained in every application (e. g. Alt-F should always display the File menu).
Help systems should also come in deaf sign language, granting equal access to the computing learning process.
Windows environments should allow independent window moving, resizing, minimizing, closing and switching between different windows, and all these should be feasible using just the keyboard. Keyboard only management of all resources and options should be provided.
The keyboard driver provided by the operating environment must allow many different keyboard settings such as sequential use of special keys (Meta, Shift, etc.), key repetition time, key accept time, etc.
In the same way, the mouse driver must provide button function switching, blocked dragging, and aspect, orientation, acceleration and speed selection by user. Double click and click acceptance time should also be user selectable.
Software applications should use accessibility services and mechanisms provided by operating environments. They should also be keyboard accessible and provide keyboard use consistent with the operating environment. They should follow operating environment requirements when applicable (e. g. color usage, circular menus, etc.) and should always provide a way to end the application.
Concerning access to hypermedia information networks, two aspects should be considered. Browsers should be completely accessible as any other software application and must provide keyboard only access to every relevant information in a web page (links, frames, window sections, menus, etc.). On the other hand, the contents of a web page (mostly in HTML) must be fully accessible and therefore provide text alternatives to graphics, sound alternatives to texts, text alternatives to sounds, and video captioning.
Use of frames and tables should be avoided where possible, the same as blinking, scrolling and vertical texts.
Authors of web pages containing programs such as Java or CGI must ensure that these applications follow accessibility recommendations for software applications.
The two Spanish standards on computer access for handicapped people are thought to be the first de jure standards approved in the world concerning computer accessibility issues. They may not be too innovative, as they're a compendium of many recommendations spread out through different technical documents all over the world, specially in the US and EU, but they provide a formal framework on which it'll be able to develop further constructions, such as local accessibility laws and broader international standards. They can be used by computer hardware and software developers to obtain better products, knowing that requirements will not change the next day.
A working task will be started in order to use these standards as a base document for a CEN standard that would make these requirements extensible to all European countries.
Aplication Software Design Guidelines Trace R&D
Dpt. of Industrial Engineering (University of Wisconsin)
Compiled by Gregg C. Vanderheiden
Accesible Design of Consumer Products
Industry-Consumer-Researcher Work Group
Compiled by Gregg C. Vanderheiden and Katherine R. Vanderheiden
Considerations in the Design of Computers to Increase Their
Accessibility by Persons with Disabilities
Industry/Government Computer Accessibility Task Force
PC 97 Design Guide, Designing Pcs and peripherals for the
Microsoft Windows Systems
Design of HTML (Mosaic) Pages to Increase their
Accessibility to Users with Disabilities
Gregg C. Vanderheiden Ph.D.
Trace R& D Center, University of Wisconsin - Madison
Designing the World Wide Web for People With Disabilities: A
User Centered Design Approach
Lils F. Laux, Peter R. Mc Nally, Michael G. Paciell, Gregg C. Vanderheiden
ASSets '96, Vancouver, British Columbia, Canada - Unified
Web Site Accessibility Guidelines March 1997
Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm, Neal Ewers, Shannon M. Dunphy
Trace R and D Center, University of Wisconsin - Madison
People with Disablilities Can't Access the Web
Hypertext Markup Language - 2.0 September 22, 1995 T. Berners-Lee, D. Connolly (1) http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_toc.html
HTML 3.2 Reference Specification Dave Raggett W3C Recommendation 14-Jan-1997 http://www.w3.org/pub/WWW/TR/REC-html32.html
Go to previous article
Go to next article
Return to 1999 Conference Table of Contents
Return to Table of Proceedings