Vous consultez : Le Typhlophile / Participation à la conférence CSUN - Annexes
Accès au contenu | Accès au au menu | Touches d'accès rapide du site

Participation à la conférence CSUN - Annexes

Quatre cannes blanches.

Mardi 22 septembre 2020 à 10:39:44 HaE

Tournois d'échecs pour déficients visuels

Chercher sur le site

Interroger Google

Logo de Google.

Photographie d'une calculatrice scientifique.
Une calculatrice scientifique parlant français. Celle-ci a été inventée par un québécois, Gaston Ozilot, durant les années 1980 et jusqu'à ce jour, elle est la seule à avoir ces caractéristiques.

Partager la page sur Facebook

Typhlophile écrit en braille.
Une vitrine virtuelle à l'attention des AMIS DES AVEUGLES

Le Typhlophile / Participation à la conférence CSUN - Annexes


par Jean-Marie D'Amour


The Non-Visual web: Information Surfing with pwWebSpeak

Markku Hakkinen & John De Witt

Developments in non-visual, self-voicing software applications continues, making web surfing easier for visually and print disabled users. Rather than focusing on mastery of screen readers, graphical user interfaces, and visually oriented web browsers, alternatives that provide efficient access to web content are now available. pwWebSpeak provides an alternative, easy to master on-ramp to the internet's world wide web, designed from the ground up to be accessible to users with a visual disability or others who prefer uncomplicated, yet efficient access. New developments extend the power of non-visual access to e-mail and to users without PCs, using the telephone. Accessible web multimedia, such as streaming audio and SMIL also be demonstrated.

This session will introduce the concept of non-visual browsing and present the simplified command structure of the browser. After a brief introduction to the keyboard commands, the audience will be able to actually get on line and surf the web. Users will learn how to fill in web-based data entry forms, perform searches using the popular services like InfoSeek and Altavista and send e-email. In addition, a demonstration of web access using the most ubiquitous internet device, the telephone, will be included.

This session is suitable for the computer novice, though a basic familiarity with the computer keyboard is desirable.

IBM Home Page Reader: The Voice of the World Wide Web

Catherine Laws and Chieko Asakawa cklaws@us.ibm.com and mailto:chie@trl.ibm.co.jp
IBM Special Needs Systems
11400 Burnet Road
Austin, Texas 78758


Web browser solutions for people who are blind suffer from a growing list of problems including the inability to easily obtain page layout information, difficulty navigating the grammatical and structural elements of a web page, synthesizer inaccuracies, the inability to accurately read tabular information, and limited document search capabilities (Vanderheiden, Chisholm, & Ewers, 1996). In the last year, the World Wide Web Consortium, as part of its Web Accessibility Initiative, has authored accessibility guidelines for user agents, which include screen readers and screen magnifiers working with web browsers as well as independent web browsers (Gunderson & Jacobs, 1998). These prioritized guidelines offer recommendations for browser implementations which significantly improve access to WWW documents.

This paper discusses how IBM Home Page Reader, a new web browser solution for blind users, implements some of these guidelines in its approach to address World Wide Web accessibility problems for blind users.


In 1996, blind people in Japan had only two sources of published information: Braille books and cassette tapes. With computer users able to get information easily and quickly from all over the world using the Internet and blind users unable to access the web easily, the information gap between sighted and blind users was becoming wider. When Japanese blind users did try to access the web in the DOS environment, the screen reading and navigation of hypertext links and two-dimensional information was difficult and incorrect (Asakawa & Itoh, 1997).

Since the IBM Screen Reader/2 product had been translated into Japanese, the IBM Tokoyo Research lab first tried to create a prototype system using SRD/2 to read Netscape Navigator web pages. However, this solution read only the text information displayed on the screen; it was unable to read and navigate tables, forms, long web pages, and frames. To address these problems, the research lab decided to develop a talking web browser solution for Japan that analyzed HTML tags rather than simply reading the screen. In October, 1997, the IBM Japan Entry Systems Business Unit (ESBU) announced IBM Home Page Reader as a Japanese consumer product for blind user access to the web. In 1998, the IBM Special Needs Systems organization in Austin, Texas, worked with IBM Japan to develop Home Page Reader as a U.S. English, IBM Independence Series product that offers blind users better access to the World Wide Web.


IBM Home Page Reader offers a number of features that enable it to provide better access for blind users to the World Wide Web:

  • Netscape Navigator synchronization. Because Home Page Reader communicates with Netscape Navigator to get web information (HTML source), HPR reads tables, frames, forms, and images on graphical web pages logically, as they should be read. While HPR speaks web pages to a blind user, sighted users can see the Netscape rendering of the same web page the blind user is reading to provide sighted assistance, if needed.
  • Software text-to-speech support. HPR supports IBM's software text-to-speech, SAPI-compliant engine, IBM ViaVoice OutLoud. No extra hardware expense is required.
  • Numeric keypad web page navigation. HPR provides a logical, numeric keypad interface for navigation and manipulation of web page elements, such as image and text links, text, form elements, tables, maps, lists, headers, and frames. Keys help mode allows users to press any HPR key combination and hear its description.
  • Web pages are read with speed and auditory distinctions. HPR's fast-forward key allows users to skim web pages to locate desired information quickly. Using a female voice to read links and a male voice to read text, HPR provides the user with easy, auditory distinctions when reading web pages. Optionally, the user can select the word "link" or a MIDI sound to identify links, or select no announcement of links, if desired.
  • Web page authoring accessibility features are utilized. HPR reads ALT or other descriptive text, when it exists, for all images, maps, and other web page objects. Otherwise, it reads the URL link information. HPR reads other new HTML 4.0 information provided by web authors, such as table captions, headers, and summaries.
  • Web page orientation. Page summary information and "where am I" numeric keypad commands tell the user information about the number and location of page elements on the current web page and at the current location.
  • Online help and bookmarks accessed as web pages. HPR online help and bookmarks are easily retrieved as local web pages with hypertext and help the user get started quickly using HPR.
  • Electronic mail feature. HPR provides an integrated electronic mail feature consisting of forms and menus that can be read and handled by HPR. This feature requires the Microsoft Personal Web Server or Peer Web Services. Also, for sending mail, HPR can handle mailto tags.
  • Easy, self-voicing installation. Spoken instructions guide non-sighted users through a standard installation program. HPR setup includes installation of the IBM ViaVoice OutLoud software TTS engine and an optional installation of Netscape Navigator for new Internet users.

Logical Numeric Keypad Layout

HPR uses a logical layout of the numeric keypad for its users to read and navigate web pages. Basic numeric keypad keys are assigned to read the previous, current, and next link (1, 2, and 3), page element (4, 5, and 6), and word or character (7, 8, and 9), to read the page (0) and to stop reading (Enter). Other basic keys provide access to a history list (Num Lock), online help (slash), a settings menu (asterisk), and bookmarks (minus). In settings mode, basic keys (2, 4, 6, and 8) are used to logically navigate and select settings in a non-visual menu system.

Extended HPR functions use the plus (+) key then a basic key that is usually related to the extended function. Extended numeric keypad keys are assigned to read the first or last link (+ then 1 or 3), page element (+ then 4 or 6), and word or character of an element (+ then 7 or 9). Other extended functions include reloading a web page (+ then Num Lock), getting keys help (+ then slash), adding or deleting bookmarks (+ then -), setting word/character reading mode (+ then 8), getting "where am I" information (+ then 5), opening a link (+ then 2), fast-forward page reading (+ then 0), getting a new URL or searching (+ then dot), and canceling a connection (+ then Enter).

Jump keys in Home Page Reader use the dot (.) key to provide additional navigation capabilities for tables (dot then Num Lock, slash, or *) , headers (dot then 1, 2, or 3), frames (dot then 0), paging up and down (dot then 4 or 6), and structures (dot then 7, 8, or 9). a structure can be a list, select menu, table row, form, or map. a page summary key (dot then 5) is also a jump key.

Functions for managing bookmarks require the user to hold down the bookmarks key (minus) and then press a basic key. Functions for history list navigation involve holding down the history list key (Num Lock) and then pressing a basic key.

Screen Reader compatibility

Since HPR requires a screen reader for access to some of its advance customization features, it provides some screen reader compatibility, such as the use of standard Windows controls. However, HPR must be silenced when using a screen reader and vice versa. The Ctrl+F12 key silences and reactivates HPR keys and functions. Unchecking a setting called "Active in the background" also enables HPR to coexist with a user's screen reader. The online help provides additional information that suggests how specific screen readers can coexist with HPR.

More Information

For more information about IBM Home Page Reader and other IBM Independence Series products, visit the IBM Special Needs web site at http://www.ibm.com/sns. In addition to the web site, you can obtain information about IBM SNS products by calling 1-800-IBM-CALL and through our dealers.


Asakawa, C. and Itoh, T. (1998). User interface of a Home Page Reader. Proceedings of the ASSETS '98 ACM Conference on Assistive Technologies, 1998-4.

Gunderson, J. and Jacobs, I. (1998, July 3). WAI accessibility guidelines: User agent. Working draft. [Online]. http://www.w3.org/TR/WD-WAI-USERAGENT/

Vanderheiden, G., Chisholm, W., and Ewers, N. (1996, March 27). Making screen readers work more effectively on the web. [Online]. http://trace.wisc.edu/docs/screen_readers/screen.htm

BrailleSurf: An HTML Browser for visually handicapped people

Dominique BURGER
INSERM-Creare U483
UPMC B23, 9 Quai St Bernard, 75005 Paris, France
tel: +33 1 44 27 26 25
fax: +33 1 44 27 34 38
e-mail: djamel.hadjadj@snv.jussieu.fr


This paper reports the work undertaken in a project aimed at providing services via the Internet to visually handicapped students from primary schools (the BrailleNet project). It examines the functionality needed to browse through HTML when the vision can't be used as the main sensory support. It is assumed that users have no experience in computer applications nor in graphical interfaces. Thus non visual browsing methods should be simple and intuitive as to make its learning and use very easy even for children and kids. We describe briefly BrailleSURF, the resulting HTML browser that has been developed is currently in evaluation in 20 French educational settings involved in the BrailleNet Project. The general lines concerning the architecture and techniques used to implement it are drawn.


The language HTML has been created to describe the content and the structure of multimedia electronic documents. Since this language has been popularised by the success of the Internet, it has been becoming a matter of standard used by many software manufacturers and publishers. Thus an increasing amount of documents is now available in an HTML form. In complement, reading tools have been developed so that not only present documents via a computer interface but also facilitate navigation through large document databases over the electronic world thanks to powerful engines embedding search, retrieve and navigate functionality.

For people with visual impairment, this situation renews the old problem encountered in looking for information. The question is not any more to get documents produced from the scratch in a completely different form (Braille, audio, large print) but rather to have an alternative access to the same information sources. According to this new situation, the consortium BrailleNet has been created in France in September 1996 in order to promote the use of Internet in the education of the visually handicapped. This consortium counts user organisations, schools and universities, research labs and industrial companies [1]. Its main achievements during the first year of the project were : the creation of an educational network, the creation of a Web Site containing examples of contents useful for students and the development of a Web browser which is the topic of this paper.

a preliminary survey on the software tools that are currently used to access the Web by visually handicapped users showed that mastering these tools necessitates a long and difficult training which could be a severe obstacle in our project. Let us simply remind that visually handicapped users have to deal with 1) a GUI (the graphical layer of Windows), 2) a browser whose interface widely refers to visual metaphors (Netscape, Internet Explorer) and 3) an additional software translating the content of the screen in Braille or speech (such as Virgo, Jaws, ..). For this reason, the development of a specific browser was undertaken. The results are very encouraging.

The filtering of HTML documents

1. General principles

Internet servers provide information via the unified HyperText Transfer Protocol (HTTP), and use the HTML [6] language to describe the structure and content of the information delivered. Thus, this information is fairly easy to interpret and transform even before to be presented to the user. Existing access solutions for the visually handicapped have taken advantage of this feature [2, 4, 8-10].

Different levels of transformations can be distinguished, for instance simplification (images are removed), clarification and rephrasing (a label can be added before an hypertext link to make it clearly perceived on a Braille bar or when it is spoken by a speech synthesiser [10], restructuring (a summary of links can be provided at the beginning of the document to facilitate rapid access to them [4]).

2. Filtering functions

HTML elements are enclosed in delimiters or tags that clearly indicate the nature of the element. It is therefore easy to trigger a transformation function each time a tag is encountered and to stop it at the end of the element. The process can be applied several times for each transformation. Moreover, HTML is flexible enough to provide a variety of ways to give a semantic content a HTML form. This is the basis of any adaptation method based on processing HTML source code. a transformation database can therefore built that defines the relationships between the various HTML tags and the transformation functions or methods [3]. Table 1 gives some examples of transformations that can be operated on the original sources. These transformation can be operated independently from each other.


  • Braille abbreviation
  • Phonetic value of acronyms for their pronunciation


  • Prefix for Braille display. Ex. : [H1]
  • Insertion of prosodic markers or voice indicator for speech output

Anchors, Links

  • Bracket for Braille display
  • Prefix for speech output Ex. : "Link" BrailleNet
  • Numbering the links


  • Insertion of an Image indicator. IMG 1
  • Insertion of the caption as a text
  • Insertion of a anchor allowing to by pass the image
  • If the image has a link associated to it, but no comment insertion of the URL address as a link.


  • Insertion of Table indicator. Ex. : "Table with links"
  • Insertion of the caption as a text
  • Insertion of a anchor allowing to by pass the Table


  • Creation of a list of links corresponding to the frames
  • Prefix for speech output Ex. : "Frame" Menu


  • Insertion of an Form indicator. Ex. : "Form with 3 objects"
  • Insertion of the caption as a text
  • Insertion of a anchor allowing to by pass the Form

Table 1 : Examples of transformation functions

The Browsing Interface

In this section we present some examples illustrating concretely these filtering methods applied in building the userinterface of the browser and how different modalities are combined to create a simple and user friendly interface.

1. a multimodal interface

The presentation of documents can use 1) enhanced contrasts, fonts, colours as well as large characters on the screen, 2) synthesised speech, or 3) a Braille display. In fact, all those three modalities can be used complementarily. For instance, the search for an URL address, the downloading of a document produce characteristic sounds. If an URL is not found a message is spoken. When a link is displayed on the Braille display, a short sound is emitted as a complement of the indication given in Braille. Reading a documents can be made in Braille or speech. a single key gives the possibility to switch rapidly from one modality to the other.

2. Different reading strategies

Moreover, different reading strategies can be used, for instance reading the page extensively, reading only the links or only headings and links. It is possible to switch from one strategy to another.

3. The presentation of Links

Links in HTML have an essential functional value. Thus they shall be perceived immediately by the user. When the data are to be read on a Braille display, the links regularly disappear for a very short time. The "blinking" speed can be chosen by the user. This solution can be reinforced by filtering, since the filter can insert brackets juts before and just after the links (see Table 1). To activate a link, the user just clicks on one of the corresponding. If the referenced document is an HTML document the software invokes the HTML interface.

If the reference is an e-mail address, the software invokes an e-mail application. If the document is to be downloaded (images, sounds, software files, ...) an adapted "Save As" Dialogue box opens. When reading with a speech synthesiser, the user has the possibility to stop it. At this moment the focus is on the text chunk being emitted. Then the user presses the Enter Key. This action activates the link Mode, presenting the first link in the chunk. Thus the user can go through the other links using the Up and Down Arrows. Once a link has been selected the Enter Key is used to activate it.

4. Multi-frame pages

The frame structure are transformed into link structures. Each page referenced by a frame, can be consulted separately by activating the corresponding link. At any time, the user can go back to the main page (Frame Page) in order to be able to access to an other referenced page.

5. The choice of a language

Since Internet is basically multilingual, a language key makes it possible to switch from one language to another. Four languages are currently available : English, French, German and Spanish.


The browser BrailleSURF has three main modules : a Document downloader module sends requests to Web server using the HTTP protocol. It can also load HTML files from a hard disk, a diskette or a CD-ROM, or, lastly, receive HTML pages generated by software engines on the Web. a Filter module processes the source documents and prepares them before their presentation in Braille, speech or large print display. Adapted documents are then delivered to the Browsing User Interface through which the user can read the document and interact with it. Figure 1 shows the general architecture of BrailleSURF:

The BrailleSURF browser has been developed in the environment of Windows 95 and Windows NT using the engineering concepts proposed in the ActiveX technology [5] (COM and OLE Automation). The programming environment was Visual C++ 4.2 and its extensions (MFC. SDK, APL,...). It has been developed in full compatibility with most of the Braille devices available on the French market with either 20, 40 and 80 cells, and possibly equipped withbuttons making direct pointing and clicking possible on items. Also several speech synthesis system can be used among them a software Speech Engine produced by Elan Informatique.


The approach we proposed for the development of this HTML browser clearly separates the adaptation of the web documents from their presentation [7]. It seems to provide a suitable framework for the development of Internet access products whose main features are full compatibility with current and previous HTML versions, and easy updating according as HTML develops by adding new data to the transformation database


This R&D project is supported by a grant of the Fédération des Aveugles et handicapés visuels de France.


[1] BrailleNet, http://www.ccr.jussieu.fr/braillene t/

[2] Guide to Writing Accessible HTML, http://www.utoronto.ca/atrct/rd/html/htmlvis.html

[3]Hadjadj D., Agro R. & Burger D., Customising HTML by filtering, 3rd ERCIM Workshop User Interface for All, 1997, pp. 219-224. [4] Lynx, http://lynx.browser.org

[5] Microsoft, ActiveX Accessibility Conference, Birmingham-UK, 1996

[6]Schwartre J., HTML, Data Becker GMBH & Co KG 1996

[7] Stephanidis C., Access to Graphical User Interfaces by blind people, Concerted Action on Technology and Blindness, May 1991, p.1-65

[8] The Web and Disabled People,www.w3.org/pub/WWW/Disabilities/

[9] Unified Web Site Accessibility Guidelines, http://trace.wisc.edu/docs/html_guidelines/htmlgide.htm/

[10] WAB: W3-Access for Blind And Visually Impaired, http://www.inf.ethz.ch/public ations/ea.html Do you know BrailleNet ? www.braillenet.jussieu.fr/education Dominique BURGER INSERM Creare Université Pierre et Marie Curie B23 9, quai Saint Bernard 75252 paris cedex 05 tel. : + 33 1 44 27 34 35 fax : +33 1 44 07 15 85

Authoring Tool Support: "The Best Place to Improve the Web"

Laurie Harrison
Jan Richards
Jutta Treviranus
Adaptive Technology Resource Centre, University of Toronto


The World Wide Web is quickly becoming a new form of library, news media, trade show, storefront, town hall, classroom, and community centre. If authors who create Web pages follow accessibility guidelines, the Web, unlike many traditional environments, is accessible to users with disabilities. The greatest access challenge, relative to the Web, is therefore to make sure that all authors follow accessibility guidelines. When we talk about all authors, this encompasses professional design firms, government webmasters, mom and pop retailers, and the kid down the block. The guidelines are published and available on the Web. Tools exist that allow the author to check the accessibility of their site. Legislation is in place mandating accessible web sites. However, all of these mechanisms require that the author know about accessibility guidelines, have the will to follow them, know where to get the necessary instructions and know how to technically implement them. a more successful method of meeting this challenge may be in providing supports and information in the Web authoring tool. The majority of authors use Web authoring tools and the percentage who prefer authoring tools to manual HTML markup is increasing. The authoring tool is a mechanism that can reach authors who have neither the knowledge or even the will to make their Web pages accessible. This paper will address a number of projects and initiatives with the common goal of creating Web authoring tools that support the creation of accessible web pages. These include:

  • HoTMetaL 4.0
  • WAI Authoring Tool Guideline Working Group
  • ATRC Authoring Tool Evaluation Project
  • The A-Prompt Project


While in recent years the issue of the accessibility of HTML to users with visual disabilities and other constraints has become a topic of great concern, it was not always this way. HTML began as a simple and predominantly text based subset of the more complicated SGML. It opened up a world of information for users with visual disabilities who could access the textual content quickly using text browsers such as Lynx in combination with their alternative screen access system. However, graphical browsers such as Mosaic and Netscape revolutionized the Web by introducing a graphical point and click interface along with a variety of new official and unofficial HTML additions. Innovative designers have misused the structured assumptions of HTML for their own aesthetic purposes and introduced new dynamic elements such as Java applets and active-X controls. The result has been an erosion of the accessibility that users with disabilities, slower connections and text based operating systems previously enjoyed.

Mitigation of Accessibility Losses

The Challenges

There appear to be two key factors in the current prolific production of inaccessible Web pages. The first is ignorance, or more specifically, the possibility of authoring Web pages with little or no understanding of HTML. The extent of HTML illiteracy on the Web is underscored by the general move towards WYSIWYG authoring tools that advertise themselves as usable without knowledge of HTML. In addition, even those who are skilled in HTML are often ignorant of Web accessibility guidelines.

a second problem is laziness, or, in any case, the lack of motivation to do repetitive, complicated or time consuming activities that may be viewed as unimportant. Reworking HTML code or adding redundancies to accommodate computer users with disabilities is often pushed aside in the rush to get information out on the Web as quickly as possible. The extra step of ensuring accessibility is generally not an attractive undertaking for the web designer.

The key to increasing the accessibility of the Web is to take advantage of the power of computers to do the boring, repetitive and guideline intensive work instead of asking people to scrutinize and change their own authoring habits. With the proliferation of GUI word processor style HTML editors, a unique opportunity for including accessibility automation presents itself.

Lessons Learned from HoTMetaL 4.0

The first commercial, access-aware HTML authoring tool was HoTMetaL 4.0 from SoftQuad, created in consultation with the Adaptive Technology Resource Centre (ATRC), University of Toronto. The released product is still a work in progress as far as accessibility is concerned, but the first steps have been taken. For the purposes of this paper, the specific features of this product are not as important as the design priorities that emerged as the most essential characteristics that a successful access-aware HTML authoring tool must possess. These characteristics are the 3 "tions": information, automation and integration.


This is the most important of the "tions", since it is necessary to overcome author ignorance on the subject of accessibility. The methods by which accessibility information should be presented are constrained by three important factors:

  • the vast majority of users have never had exposure to accessibility issues and will not seek out ways to enhance accessibility on their own.
  • many authoring tool users are attracted by the time saving site building wizards and GUI word processor interfaces that allow sites to be constructed with limited HTML knowledge.
  • accessibility is a stylistic quality of a page or site, not just an extra that can be included as an afterthought.

Clearly, the best way to accommodate these constraints is to make the provision of accessibility information an active part of the authoring process. Instead of simply including accessibility information within a program's help files; guidelines and accessibility fixes should be presented as the user initiates inaccessible authoring practices. In this way, the presented information can be made succinct and context sensitive, educating the author as the work progresses; instead of overwhelming the author with problems when a check is made on a completed page. These brief initial warnings should include links to the help system for more information and (when possible) automated tools to perform or support corrective measures. Additional information or links to information should also be added to other major areas of authoring tools, such as: site management tools, specialized utilities and content wizards.


The second characteristic of an accessibility-aware HTML authoring tool is a high degree of automation; needed to overcome author laziness. Just as FrontPage 98 includes a wide array of utilities including ones that maintain button bars and modifies links, the access-aware HTML authoring tool should include tools that make repetitive and stylistic tasks into one-time, well-guided occurrences. Other automation ideas include:

  • Site building utilities that automatically include ALT text and avoid access hazards
  • ALT text association files (that save a record of ALT text used for a particular image, to be used as a default entry)
  • D-text file creation support (implemented in HoTMetaL 4.0)
  • Automatic Text-Only, NOSCRIPT and NOFRAMES generation
  • a function to spot problematic colour combinations

By automating the repetitive and tiresome aspects of authoring accessibly, an author's attention can be focused on description writing, where the human ability to understand the content of an image, sound or animation is imperative.


Finally, any accessibility tools that are added to an HTML authoring product must be integrated seamlessly into the look, feel and function of the product. If this requirement is not met, then the tools may assume the appearance of tacked on, second class features. This in turn will lead users to the belief that the authoring support tools have been added for reasons besides their necessity to page design. In addition, if the authoring support tools make use of user interaction styles that differ from the host product, some users may be hesitant to learn how to use them. The end result of inconsistent look, feel or function may be an unwillingness or inability of authors to make use of the accessibility features even when they are present.

Setting New Goals - Authoring Tools Guidelines Working Group

In order to introduce this threefold approach to accessibility to the software developers who are producing HTML authoring tools, a new Authoring Tools Guidelines Working Group has been established by the WAI. While attention is being given to the need for accessible interfaces to accommodate Web page authors with disabilities, the current focus of the group is the creation of guidelines, documents and prototype utilities for authoring tools which provide author support for creating accessible documents. Their tasks include:

  • Review of existing recommendations and guidelines for web authoring to determine which guidelines can be supported within the authoring tool and recommended mechanisms for doing so.
  • Creation of guidelines for developing authoring tools which support the creation of accessible documents. These will include priority levels and example implementations.
  • Authoring of example help files which can be included in authoring tool help files to instruct authors on the need and mechanisms for creating accessible Web documents
  • Prototyping and specification of tools for partially automating such processes as linking d-links, reusing alt-text, creating accessible style sheets, etc.

Ongoing work will involve provision of information and guidance to the WAI Education group related to educating, negotiating with and lobbying authoring tool developers to adopt recommendations.

Assessing the Current Market - ATRC Authoring Tool Evaluation Project

To demonstrate the strengths and deficiencies of current page authoring tools, the ATRC is undertaking a review of popular authoring tools currently available on the market. a measurement tool is being developed, using the WAI guidelines as a benchmark criteria for accessible page authoring. In addition, the principles of information, automation, and integration will also be considered. The scoring system be weighted according to the priority levels assigned to each of the accessiblity criteria in the WAI guidelines, with consideration being given to the three principles outlined above, as applicable.

During Phase 1 of this research project, between five and ten HTML authoring tools will be reviewed and scored using the measurement tool. It is hoped that this product review, conducted by an established centre of excellence in the field of accessibility, will highlight the need for incorporation of tools, utilities and help file resources into HTML authoring software. Phase 2 of the project will include adaptation of the measurement tool to allow evaluation of HTML conversion utilities, and also evaluation of courseware development tools used for creating Web-based distance education programs. It is anticipated that results of Phase 1 and preliminary results for Phase 2 will be available at the time of presentation of this paper.

The A-Prompt Project - a New Model for Interface Design

The ATRC, in collaboration with the Trace Centre, University of Wisconsin, is currently developing a software module that can be integrated into HTML authoring tools to support authors of Web pages in creating HTML documents which are accessible. Building on the lessons learned in the SoftQuad project, the goal is to develop a modular tool that supports accessible Web page authoring.

The software module will be in the form of a Windows DLL (Dynamic Linked Library), called the Acccessibility Validation DLL (AVDLL), which can easily be integrated into exisitng HTML authoring tools. The AVDLL will also be ported to an Accessibility Validation Java Bean (AVJB).

The module will have four components:

  • an HTML checker
  • an Attribute dialog modifier
  • Accessibility utilities, and
  • an Accessibility user interface model.

The Windows DLL and Java Bean will be created for developers of HTML editors for all popular platforms, and created in such a way that it can be easily integrated into HTML authoring tools applications with minimal effort or change to code.


In closing, it seems clear that published guidelines and pleas for cooperation have been ineffective in increasing the actual use of accessible HTML authoring practices on the Web. In order to change this state of affairs, the accessible HTML community must win the cooperation of the most popular Web authoring product makers to ensure that their products include informative, easy-to-use and effective authoring support.

a Primer on the Java Platform and Java Accessibility

Earl Johnson
Peter Korn
William Walker
Sun Microsystems, Inc.
901 San Antonio Rd.
Palo Alto, Ca 94303


Java computing is rapidly being embraced by industry and education alike. For example over 400 colleges and universities are teaching the Java language as a beginning computer programming course. On the corporate front a recent corporation focused survey found that in the coming year 84% of them will be developing new applications in Java 75% of them will use Java to extend the life of their legacy applications. This rapid embracement is further indicated by the latest numbers for Java programmers showing over 700,000, the fact that the Java phenomena is 3.5 years old at this writing, and over 1,000 different books have been written about the technology.

Still, what we are seeing is people with disabilities are only just now starting to be exposed to and affected by Java technologies in a significant way. It is this growing exposure that is driving further investigation into what the Java platform can do and, more importantly, into what type of accessibility support has been built into the platform. This paper was written to help provide some information in these areas. Specifically, this paper gives a high level overview of the Java platform, talks about the GUI components in the Java Foundation Classes and the accessibility support they provide, identifies the broader aspects of Java Accessibility, and quickly touches on future issues.

The Java platform

Java technology's product possibilities and realities cover a broad range of user environments. Java applets and applications (app/lets) run on platforms that include traditional desktop computers such as X Windows, Windows, and Macintosh, on future JavaOS generations of networked computers, on copying machines, on public systems such as information kiosks and automatic teller machines, and on home based products like set-top boxes and environmental control systems.

People are excited about the Java platform because it allows software engineers to "Write Once, Run Anywhere" (SM) -- that is to develop a single version of an application that can be used on a variety of computers and devices. This means that users will see better integration occurring between their desktop work systems, intermittently connected work systems, PDAs, and ATM. Large companies, independent software vendors (ISVs), and government agencies benefit also because they will be able to consolidate the groups of software engineers working on applications for different platforms into one group working on Java app/lets that run on any of these same platforms.

The Java platform is at the heart of this capability and is comprised of two main components - the Java Virtual Machine (JVM) and the Java Application Programming Interface (Java API). The JVM can be thought of as the translator and facilitator of communication between Java app/lets and the native platform the Java platform is running on while the Java API is the set of tools and components with which to build portable app/lets with. It sits on top of other platforms (e.g. CDE, Macintosh, Windows), and compiles to bytecodes, which are not specific to any physical machine, but are machine instructions for a virtual machine. The bytecode is read by the JVM and translated into a format the native platform understands, this capability is what enables the Java platform's cross native platform portability.

The Java APIs, the other half of the Java platform, are a set of packages of software components that provide a wide range of functionality from which to build robust applications with. The core API is the API included in every full implementation of the Java platform. The core API provides support for input and output, data structures, system properties, date and time, internationalization, networking, user interface components, applets, and more. The Java API set can also be extended through standard extensions from which some get promoted to core. The Swing components and Java Accessibility are two such examples.

The following figure depicts a Java program, such as an application or applet, that's running on the Java platform. As the figure shows, the Java API and Virtual Machine insulates the Java program from hardware dependencies.

Not all the above technologies will play an active role in enabling accessibility on the Java platform. Technologies that do play a role in supporting accessibility are Java Foundation Classes(JFC), Java Accessibility API and Utilities, Abstract Window Toolkit (AWT), JavaBeans, JavaSpeech Java%20Native%20Interface(JNI)%20<A%20href=" rmi? guide docs 1.1 JDK products java.sun.com http:Remote Method Invocation (RMI), Reflection mechanism, JavaOS More on the JFC and Java Accessibility API and Utilities follows.

Last but not least is the Java Language which acts as the on-ramp to all the power provided by the Java platform. Some highlights of the language are it is simple, yet flexible and powerful, that is object-oriented (with single inheritance), statically typed, multithreaded, dynamically linked, and has automatic garbage collection. Its syntax is based on C and C++, so those programmers can pick it up quite easily. Finally its strong data typing, automatic garbage collection, array bounds checking, lack of automatic type coercion, and the lack of the pointer data type encourages catching bugs early, during development.

The Java Foundation Classes user interface components (Swing)

Swing extends the original Abstract Windowing Toolkit (AWT) by adding a rich set of graphical user interface components that are completely portable and delivered as part of the Java platform. Examples of components include push button, menubar, text pane, and table. Application Developers are attracted to Swing because its comprehensive set of graphical user interface (GUI) components and foundation services greatly simplifies the development and deployment of 100% Pure Java (TM) applications for the Internet, intranet and desktop environments. By being 100% pure developers get by a big limitation of the AWT which relies on user-interface code that's native to whatever operating system they're running on. If one native platform's GUI toolkit didn't support a component, e.g. a tabbed pane, then the AWT couldn't support it. Doing so would break the AWT's cross platform capabilities. With its Pluggable Look and Feel Swing also allows developers to create applications that reflec! ts the operating system on which it runs, or use the GUI components to create their own platform-independent interface. Examples include an audio based user interface and the new Java look and feel that ships with Swing.

Swing also excels on the accessibility support front. For the first time accessibility has informed the design of and been built into a commercial UI toolkit. Mouseless or keyboard navigation support is already implemented on interactive components. The Pluggable Look and ccessibility API. Utility tools are also necessary in order to provide the necessary support for assistive technologies to locate and query user interface objects inside a Java application running in a Java Virtual Machine. These tools also provides support for installing "event listeners" into these objects, event tracking, and support for loading assistive technologies into the Java Virtual Machine. Finally, example tools are provided with the package that highlight how to enable assistive technologies to interact with the Accessibility API support built into Swing components. All these tools are provided in the package. Java Utilities

The Java Accessibility Bridge

Java applications run on a wide variety of host operating systems, many of which already have assistive technologies available for them (e.g. Macintosh, OS/2, Microsoft Windows). In order for these existing assistive technologies to provide access to Java applications, they need a bridge between themselves in their native environment(s), and the Java Accessibility support that is available from within the Java Virtual Machine (JVM). This bridge, by virtue of the fact that it has one end in the JVM and the other on the native platform, provides this pathway. Sun is currently developing a bridge for the Win32 platform in cooperation with assistive technology vendors and the various platform vendors.

The Pluggable Look and Feel of the Java Foundation Classes

The JFC is a set of user-interface building blocks that separate the state and model of information from the presentation of that information. Programs built with the JFC are not tied to a specific representation of their information (e.g., a specific list box, menu bar, or push button), but can instead allow its presentation to be programmatically determined, and can be chosen by the user. This is exciting because users will no longer need an interpretive assistive technology, a screen reader for example, but instead may purchase and specify in his or her configuration a set of audio- or tactile-based presentation tools instead of or along with a generic or customized visual presentation. So when a JFC-based program runs on this user's system and their system is configured correctly, information will be presented via one or more of these alternate modality channels. In this fashion, we have hope that the Pluggable Look and Feel will, for the first time, enable direct accessibility in mainstream applications providing.

Java Accessibility, the Bigger Picture

This paper has discussed the successes to date in building accessibility support directly into components used to build user interfaces, getting information about this out to the broader developer community, and enabling an architecture that can support choice in how users interact with and are presented information. For the most part however these are related to efforts that are primarily architecture based. Experience shows us though that true access takes much more than architectural support. This section enumerates many of the additional steps necessary to enable a broadly accessible digital world and provides some status updates on Sun's and other's work. We welcome your comments on entries we missed, please send them to us at access@sun.com.

  • An Accessibility API and underlying architecture that supports communication and object interaction between assistive technologies and applications or enables a person to directly access information without the need of a special assistive technology.
  • Status: Implemented on Swing and discussed above
  • Documentation on the underlying accessibility support broadly documented in general programming books.
  • Status: Most JFC programming books provide this coverage
  • Accessible design and testing tips included in Interface Design and Programming guideline texts books.
  • Status: IBM has made an excellent start with their set of publicly available guidelines
  • Assistive Technology Vendors who provide technical review and input on then develop products that are compatible with the Accessibility API.
  • Commercial and internal ISVs in all categories who utilize the guidelines mentioned above to help establish then meet accessible design criteria, develop these products utilizing the development tools covered in the next bullet where possible and practical, then establish an improvement roadmap where applicable.
  • Developer tools that support the Accessibility API in the UI and development environment, expose the properties associated with the Accessibility API to developers, and provide accessibility lint type features that perform basic accessibility evaluations of the app/let in design.
  • On-line information and help in applications and on the web that is written in accessible formats.
  • Customer service and field representatives who are familiar with the accessibility support in their products, know what compatible assistive technologies are available, understand how the state of current legislation and accessible products that are available can be factored into aiding sales, and can help customers fulfill their accessibility needs.
  • Most importantly customers who demand products that support, promote, and enable accessibility - companies do respond to customer demand, especially when big bucks are involved. This would include: agencies, education, and corporations setting contract requirements for accessible technology in new contracts, internal employees in these organizations who represent the concerns of employees with disabilities tracking and influencing new purchases and working with and pressuring internal development groups to develop accessible internal applications, individuals joining advocacy groups whose charter includes tracking the state of accessibility in products and applying pressure on manufacturers as required, and employees and students actively tracking and influencing decisions that result in the choice or development of applications crucial to the successful completion of their work.

Looking Ahead

As suggested early in the above Java platform discussion it is designed to power much more than desktop systems. Still, most of this discussion has dealt primarily with the development efforts that pertain to access to desktop types of systems (PC, laptop, etc.). The Java platform also powers consumer electronic devices like set top boxes, smart phones, and more - these are powered by the Personal and Embedded portions of the Java platform.

Sun has recently begun looking into interaction requirements for categories of consumer devices. The goal is to determine what an underlying architecture for these devices must provide to enable accessibility in products. While there is still much to do, some requirements have bubbled up already. The reality we found was these devices each have common as well as unique accessible interaction requirements associated with them. Many devices also have very tight memory constraints which means if a technology isn't deemed needed, it isn't included. And unlike desktop systems, some of these devices will be targeted to specific consumer groups or interaction environments which may not be practical for use by some major disability types. These are difficult design challenges to account for - that being the design an architecture in components that can expand to provide desktop like accessibility support as perhaps a set top box requires -and- contract to nearly nothing in a small dev! ice whose interaction modality simply can't or won't be expanded to

Retour au sommaire

Fac ut videam (Faites que je vois)
Le mot latin Fac écrit en braille. 
Le mot latin Ut écrit en braille. 
Le mot latin Videam écrit en braille.

Éphéméride du jour

En ce 22 septembre de l'an de grâce 2007. Décès à Montréal de Sœur Thérèse Parent, SGM, à l'âge de 85 ans. Sœur Parent fut la dernière Directrice générale de l'Institut Nazareth, boulevard Crémazie à Montréal, avant la fusion avec l'Institut Louis-Braille, de Longueuil, en juillet 1975 où elle occupa les fonctions de Directrice générale adjointe du nouvel établissement, Institut Nazareth et Louis-Braille sous la direction du Père Wilfrid Laurier CSV.

Saviez-vous que :

Valentin Haüy (1745-1822) fût l'un des grands bienfaiteurs des aveugles français au tournant du xixe siècle. Maurice de la Sizeranne a immortalisé son nom en l'associant à plus d'une de ses réalisations, reconnaissant ainsi, la riche contribution de Haüy, pour l'émancipation et l'instruction des personnes aveugles de son époque.


« La science sans religion est boiteuse, la religion sans science est aveugle. »

Albert Einstein


Typhlophile tire sa racine de « typhlo » d'origine grecque et qui veut dire « cécité »; et « phile » veut dire ami, sympathisant, etc. Donc, Typhlophile veut dire l'ami des aveugles.

Un clin d'œil vers :

Haut de la page.

Politique d'accessibilité du site
[Certifier Bobby Approved (v 3.2). | Description]
[Validation HTML/XHTML du W3Québec | Valide CSS! | Ce document rencontre les conformités Valid XHTML 1.0 Strict]
© 1996/2020; Le Typhlophile - Longueuil, Québec (Canada)

Pour vos commentaires et suggestions.