The University of Texas at Austin            
toolbox icon

Foreign Language Instructional Website Accessibility: Evaluation Report

General:

Our interest in accessibility issues grew out of a workshop we had attended at The University of Texas at Austin. We came out of that workshop with the realization that our personal web sites, like many others, were not fully accessible to people who were visually impaired, and that screen readers and speech synthesizers had a great potential for use in language instruction. We spent the summer of 2003 studying accessibility issues in the context of language instruction, and experimenting with speech synthesis. As a result, we have now added a section on the use of TTS Tools in language instruction to our Foreign Language Teachers' Toolbox.
In studying the accessibility of language instruction sites, we decided to survey a sample of sites in different languages, evaluate them for accessibility, and provide a summary of our observations. Our basic premise was that web sites should be accessible both because developers and designers should be inclusive in their approach and aim for reaching everybody, and because sites designed with accessibility in mind are better and more friendly to all users. While we were quite certain even before we started surveying sites that the majority of language instruction sites would be lacking in the area of accessibility, our assumption in undertaking the project was that making such sites accessible is an attainable goal, especially if one aims for the implementation of the minimal accessibility guidelines, those that would "make sense" even to the lay developer. That, we thought, would make a recommendation on the revision of inaccessible sites somewhat less threatening, and the task itself less daunting. Bearing in mind that the sites we were planning to look at would be in most cases bilingual, and would certainly make use of languages other than English, we were wondering if we could hope for more than technical compliance with accessibility guidelines. Such compliance, we thought, would mean very little if assistive devices like screen readers would be rendered useless when encountering texts written in a language other than English or pages that make use of more than one language. Thus, we decided to check the availability and functionality of automatic language detection by screen readers as well.

Procedure:

We evaluated thirteen Hebrew sites, twelve French sites, nine Spanish sites, eight German sites, and five Russian sites. We followed the principles of Section 508, and looked for Priority 1 compliance, primarily using "Bobby", a commonly-used internet-based tool developed for evaluating the accessibility of web sites (other tools were used if Bobby was unable to perform the evaluation). "Bobby" is currently replaced by Watchfire Webxact.

Section 508 of the Rehabilitation Act "requires Federal departments and agencies that develop, procure, maintain, or use electronic and information technology to ensure that Federal employees and members of the public with disabilities have access to and use of information and data, comparable to that of the employees and members of the public without disabilities unless it is an undue burden to do so."
The "priority 1" checklist is the minimum that developers must comply with, according to the working group of the Web Accessibility Initiative taken by The World Wide Web Consortium (W3C).

To the priority 1 check we added a manual check of the sites for tags identifying the primary language of the pages and changes of language within a document ("changes in the natural language of the document" in the jargon), two elements that are crucial to the appropriate design of both non-English and multilingual sites, and to the adequate functionality of automatic language detection.

To quote W3C, "When content developers mark up natural language changes in a document, speech synthesizers and braille devices can automatically switch to the new language, making the document more accessible to multilingual users. Content developers should identify the predominant natural language of a document's content (through markup or HTTP headers). Content developers should also provide expansions of abbreviations and acronyms.
In addition to helping assistive technologies, natural language markup allows search engines to find key words and identify documents in a desired language. Natural language markup also improves readability of the Web for all people, including those with learning disabilities, cognitive disabilities, or people who are deaf. Natural language markup may also enable machine translation of documents into other natural languages."

Findings: Checking the sites for the basic compliance with accessibility guidelines, we found the following accessibility errors (in descending order of frequency):
  • Alternative text was not provided for images.
  • Alternative text was not provided for image map hot-spots (areas).
  • Frames were not given titles.
  • Alternative text was not provided for embedded applets.
  • Captions or auditory descriptions of multi-media elements like movies were not provided.

Bobby suggested a large number of user checks, most of which pertained to conveying information by color or formatting data tables correctly. For the most part, the sites did not pass the basic compliance test, and only occasional pages were approved. With the exception of one site, none of the tested sites identified the primary language of the documents in the html tag, let alone changes in the natural language within the documents. Thus, even the automatic language detection feature of the more sophisticated screen readers like Jaws 5.0 (forthcoming) and IBM's Home Page Reader 3.02 (no longer available), did not function when applied to these sites simply because there was no code that would allow the screen readers to interpret the site language as anything other than English.

Recommendations:
As the same errors occured across languages, the recommendations are general and fairly straight forward. In fact, they are identical to the recommendations that one would make for any website, perhaps with a stronger emphasis on the importance of the language tags. These recommendations are simple to implement when new sites are developed, but they can and should be applied to existing sites as well. While this may be a time consuming task, a revision of existing sites is certainly feasible, especially if a unit administrator assigns the task to a number of people who focus on that aspect of design and go systematically through all sites within a unit. Accessibility aware authoring tools, like Lift for Macromedia Dreamwaver, can simplify the process.
We recommend, then, that language instruction site designers adhere to the following principles:
  • Design your sites with simplicity in mind--do not clutter the pages.
  • Provide alternative tags for images.
  • Provide alternative text for image map hot-spots.
  • Try to avoid frames, but if you use them, give each frame a title.
  • Provide alternative text, and, if need be, an alternative functional page for applets embedded in your site.
  • Provide captions and auditory descriptions to movies and other media elements.
  • Do not convey information by using only visual elements like color, font size, font style and such. If you feel that this is necessary, provide an alternative page that does not rely on such features.
  • Identify the primary language of the document in the html tag. Insert a language tag whenever you switch to another language within the text. You can see the tagging system in the source code of a sample page that we have created to test automatic language detection by screen readers. This page worked very well with Jaws 5.0 and Home Page Reader.
  • Before you post your site, evaluate it for accessibility with an automated checking tool like "Bobby." In addition, make an effort to run the site through a screen reader and get an idea as to how a person using a screen reader would hear the text. Pay special attention to punctuation, as it affects the flow of the language when a screen reader is used in conjunction with a site. Slight changes in punctuation may go a long way in making the text more sensible when it is read aloud.

For sample pages designed with a screen reader in mind, see Dining in a French Restaurant and Forming the Plural of Regular French Nouns. Note the punctuation of the list, meant to create breaks for screen readers after each item.

Site design with accessibility in mind often requires careful planning, and calls for compromises. A text whose punctuation is somewhat altered to produce a smoother reading by a screen reader, for example, or using the full "for example" instead of the abbreviated "e.g.", are compromises that should not interfere with conveying content. Accessible design is a matter of developing new habits and thinking creatively. Once designers realize the importance of developing accessible sites, they need to decide what they are willing to compromise, to what length they are willing to go in order to achieve maximum accessibility, and at what point the accessible design indeed places an undue burden on them and on the site users.

Website Accessibility: Resources


Home || 01 site blueprints || 02 look and learn || 03 arts, crafts, and music || 04 practice and evaluation tools || 05 resources for teachers

utopia icon

  |  UT Directory | UT Offices A-Z | Campus & Parking Maps | UT Site Map | Calendars | UT Direct |
© Authors: Esther Raizen and Jane Lippmann, The University of Texas at Austin, 2002-2004