Web Site Accessibility Auditing Tool for Visually Deficient Persons OCAWA 1
2
Denis Chêne and Michel Hoël 1
France Telecom R&D /DIH/UCE 38-40 rue du Général Leclerc 92794 Issy les Moulineaux Cedex 9, France
[email protected] 2 Urbilog, 42 rue Fénelon 59000 Lille, France
[email protected]
Abstract. Accessibility to the Web for the blind and visually impaired is an issue that has become more significant since the introduction of direct manipulation interfaces. The problem can be approached with respect to two complementary points of view : it is possible to act at the beginning of the process, during the creation phase of web pages or it is equally possible to act at the end of the process, on the web pages that already exist. Our contribution to the subject of accessibility is based on the latter point of view. In this document, we will describe an accessibility evaluation tool with a corrective function, based on the following principles : the implementation of a syntactic analysis of html pages, the execution of a first series of accessibility rules based on the document generated by XML, the execution of a second series of more complex rules with the ability to be enriched by the rule server, the production of a report adapted for the user and the continual management of the implementation phase.
1
Graphics and Accessibility
In the past, the web was accessible to the blind and visually impaired due to the fact that the majority of pages consisted of text. Command line interfaces, of ms-DOS type, were and still are generally accessible as they are based on a purely textual interaction. On the other hand, these interfaces are not at all suitable for the general public as they require extensive training to use, an issue that concerns all command language systems. An event which has affected both the web, or interfaces in general, has been the introduction of graphics for interfaces (Graphic User Interface), which for the sighted, has been a significant step forward in usability. When the interfaces WIMP (Windows Icons Menus Pointer), are used in an intelligent way, there are very practical and intuitive for those with the ability to see. For a person endowed with sight, what is more natural than selecting an object in order to use it. On the contrary, for the blind or visually impaired, what is more inaccessible that an interface where it is necessary to pinpoint an object in order to use it.
K. Miesenberger, J. Klaus, W. Zagler (Eds.): ICCHP 2002, LNCS 2398, pp. 27–32, 2002. © Springer-Verlag Berlin Heidelberg 2002
28
D. Chêne and M. Hoël
Consequently, the only part of graphic interfaces generally accessible, is the part concerning expert users : these are the short cuts available through the keyboard. However, not only are these hot keys sometimes non -existent but when they do exist, the list of available hot keys is not always easily accessible. This is the case, for example, with the interface of mobile phones, where the hot keys are listed in the instruction manual. Interfaces and the web in general, are becoming more and more graphically orientated. A telling example of this movement is illustrated by the html editors. Before now, the code was written from a simple text editor, whereas at the present time, WYSIWYG tools are readily available. This has a clearly positive aspect as everyone is able to create and share information at a global level without having a very detailed knowledge of the language. However, at the same time, this tool does not comply with the structure of an html page, which can prove to be disastrous. For instance, it is possible to find on the web a “Title” format used to highlight a word within a paragraph of text. This practice does not help the visually deficient to have a clear vision of the structure of a document. As html language is already very tolerant, the editors must take when formatting it.
2
Accessibility, Before or After?
Stephanidis states that "Universal access to computer-based applications and services implies more than direct access or access through add-on (assistive) technologies, because it emphasizes the principle that accessibility should be a design concern, as opposed to an afterthought."[6]. We are headed in this same direction and stress that the best way to prevent such a practice from being carried out, is to control it during the creation of the web document or, more globally, of the interface. It is an area that we are exploring, with an more or less long term impact. Another way of acting, in shorter terms this time, is to place oneself at the conception stage. Admittedly, this type of reactive approach is no longer considered suitable since a evaluation of an interface, in hindsight, is not always welcomed by the developer. In addition, this type of approach is inadequate if we take into account technology which has developed at a rapid rate in recent years, such as mobile phones or other personal digital equipment. The changes are so fast that a corrective evaluation would be groundless, seeing that a new product would be launched before the completion of the evaluation. However, we are operating in the specific field of the web which is already wellestablished : the contents already created are considerable and developments are fairly restrained. It is clear that a corrective evaluation tool has a place in such a context. Tools of this type already exist (Bobby, W3C html validation service, CSS validator, A-Prompt [11, 12, 13, 14]), however they only partially fulfil their role as corrective evaluators. The number of rules that they take into account are limited, the recommendation of corrections issued are not specific to different members of the public targeted as potential users (manager and developer), and targeted interfaces (Braille, vocal or screen reading). Therefore, this type of tool is limited to the web domain and mobile interfaces, which have other constraints, pose similar problems. These are, of course, new interfaces and interfaces of the future, however WAP compatibility, for example, should not be neglected [3]. Thus, we are proposing a new
Web Site Accessibility Auditing Tool for Visually Deficient Persons
29
tool, able to integrate new rules with ease and capable of handling a large number. The specifications concerning this tool are defined hereafter.
3
OCAWA
The objective of the Ocawa application is to analyse HTML type files in order to create, based on a certain number of established rules (WCAG/WAI rules, INOVA rules, FTR&D rules [1, 4, 7, 8, 9, 10]), an audit report regarding elements which cause problems or that may cause problems for an individual with a visual handicap. The elements to distinguish are the following : a syntactic analysis of the html web page, a first application of the basic rules at the XML format level, a second application of more complex rules with the help of an inference engine, a module which allows the management of these rules, a module which allows the reporting of the analysis carried out and the management of the operations executed. 3.1
Collecting HTML Flow
It is difficult to content oneself with the recovery of a HTML stream by simply subjecting an Url to a web server. In effect, the most complex parts of a web site, for example its service section, impose full HTTP access, in order to generate the HTML stream expected. For example, if the net surfer wants to order a service on the site, he can be asked to identify himself and, following verification, he can be given a session number ( often by using cookies ) that must be recalled each time a request is made. Of course, it is the brother that is responsible for this function. Another example is the subscription by the user and the subsequent request to complete a detailed form. In this form, the keying in of data in a certain number of fields is required. After the submission of the form, the server reacts differently depending on whether the supplied information is correct or not. However, the level of accessibility to the responses given by the server is often neglected; A final example is the need to take into account the restrictions imposed by Proxy services which are often used in companies. All these examples demonstrate that if we wish to measure the accessibility of a site, it is imperative that we respect the exchange between customer mail and server from the outset. This is the role of the function “HTTP brother”. 3.2
HTML Syntactic Analysis Using TIDY
The WBC has made software available which permits the analysis (even the "repair") of an HTML file. This analysis, among other things, takes into account certain WCAG/WAI rules. The Tidy programme operates by providing its guidelines via a configuration file. This file defines the "configuration rules ". Using an HTML type file and analysis configuration files, the TIDY module is responsible for providing a summary of the faults or errors encountered. In the
30
D. Chêne and M. Hoël
occurrence of an error, the audit of the HTML flow is interrupted. Errors will occur when the pages analysed are not readable by the browsers. We will thus consider that the analysis will continue only with or without "Tidy warnings". The second phase for this module will be the generation of initial statements in terms of an inference engine based on a certain number of warnings. 3.3
HTML Syntactic Analysis
As Tidy does not recover all the original file contents in the case of any problems, by "repairing" the faults encountered, an overall analysis with our own rules must be allowed using the original HTML streams. However, in order to allow for the application of the XSLT transformation rules, the entry streams must be in "wellformed " XML format. Therefore, the HTML streams must then be transformed into, at least, XML of HTML streams. To accomplish this, we will use an HTML parser whose only role will be XML transformation by applying to it certain "grammar rules". These rules will be of two types: Detection of the indicators which never close and modifying the syntax to close them. Detection of the unclosed indicators and closing them at the correct moment. To guarantee a reliable transformation, we need a complete HTML syntactic grammar which will assist us in the construction of the HTML information stream tree, and to then go back through the tree and transform these streams into "wellformed" XML standards. 3.4
XSLT Engine
The Saxon or Sablotron permits the execution of an XSLT source within an XML file. The XSLT rules file permits fact generation for the inference engine for all the remarks found by the XSL rules. These XSL rules will be primarily the application of the WGCA 1.0 standard (WAI recommendations : the Directives for the accessibility to Web contents). 3.5
Management of Analysis Rules
This management is based on the rules of the inference engine. The module using the inferencing engine permits the execution of associated rules to the initial facts generated by the XSLT engine. The resulting file will be in XML format and catalogue all the facts encountered in terms of audit. 3.6
Module Reporting
The XML fact file will allow the generation of a site audit report in function of the mission entry parameters : initial HTML page, depth of analysis type page searches
Web Site Accessibility Auditing Tool for Visually Deficient Persons
31
(WGCA priority level). According to the confirmed facts, the report can provide advice and measure the accessibility situation of a site in the «Web Access» sense. Different formats can be issued : HTML, PDF, RTF.
Fig. 1. Functional chart of OCAWA
4
Conclusion
Just as the developer is the person most apt to grasp the subtleties of a functional chart, an ergonomist is the person most capable of supplying ergonomic expertise, and a blind or visually impaired ergonomist is the most suitable person to provide expert knowledge on accessibility. Therefore, this tool is also intended for use by blind or visually impaired experts, such as the Association Braillenet [5]. This tool will clearly allow them to perform accessibility tests more effectively by automating numerous procedures (for example, counting the number of hyperlinks per page). During the conception of this programme, everything was anticipated for it to be accessible to blind or visually impaired users. Regarding this issue, there remains certain adjustments to be made. The crucial matter is of it being a tool “for all”. Its modular appearance certainly allows it to transform and/or adapt certain aspects and to add functions; eventually it could even be a web tool capable of co-operating with other expert tools.
32
D. Chêne and M. Hoël
References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Archambault, D., Burger, D.: Le WEB plus accessible pour les aveugles et malvoyants http://www.snv.jussieu.fr/inova/publi.htm (1999) Bastien, JMC., Leulier, C. , Scapin, DL.:. L’ergonomie des sites web, INRIA, Rocquencourt (1998) Chêne, D. (2002). WAP, accessibilité et innovation. Usages, n°12 FTR&D/DIH/UCE, France février (2002) Coyne, K. P., Nielsen, J. (Nielsen Norman Group) : Beyond alt Text: Making the web easy to use for users with disabilities. http://www.NNgroup.com/reports/accessibility (2001) Duchateau, S., Archambault, D. , Burger, D. : Braillenet campaign for a more accessible web. http://www.snv.jussieu.fr/inova/publi.htm (2000) Stephanidis, C.: User Interfaces for All, Concepts, Methods, and Tools. New perspectives in human computer interaction. Ed. Stephanidis, LEA London (2001) IBM Guidelines: http://www-3.ibm.com/able/guidelines.html Livre Blanc BrailleNet: http://www.braillenet.jussieu.fr/accessibilite/livreblanc/ Recommandations EasyCap: Document interne FTR&D. Ref FTR&D/DIH/UCE/DC 140202 (2002) Recommandations WAI (Web Accessibility Initiative): http://www.w3.org/TR/WAI-WEBCONTENT/ A-PROMPT : http://www.aprompt.ca BOBBY WorldWide : http://www.cast.org/bobby CSS validator: http://www.jigsaw.w3.org/css-validator W3C HTML validation service: http://validator.w3.org/
