Accessibility Is Just Another Language
The common concerns
of localization and accessibility
ULTAN Ó BROIN
|
|
Dublin, Ireland. A city to inspire wordsmiths: James Joyce, Oscar Wilde, Bono and now Arnold Schwarzenegger. Speaking at the 2003 World Summer Games of the Special Olympics, he castigated those who did not support the occasion: "I have never heard anything said to me because they know that I will terminate them."
This scared me into thinking about technology accessibility again. In March 2000, I had written in "New Challenges for Localization" (MultiLingual Computing & Technology #30 Volume 11 Issue 2) that accessibility would be a forthcoming localization challenge: "Globalization will not stop at able-bodied people only, and why should it?" I thought there could be a conflict between localization requirements and accessibility features. Now I realize that this is not the case, but rather the opposite is true.
In this article, I will look at the global dimension of technology accessibility, arguing that localization can be considered a form of accessibility and, by focusing on Web-based deliveries, show how localization and accessibility best practices coincide.
Who Are 'The Disableds'?
The localization industry has been slow to address accessibility and in some cases churlish, approaching the subject in a manner reminiscent of David Brent's (BBC America's The Office) thoughts about what he calls "the disableds."
Accessibility is rarely brought up at localization conferences and is not a topic for articles in industry publications. Save for a well-deserved press release about Bowne Global Solutions provision of translation, interpreting and Web site localization services for the 2003 World Summer Games (www.bowneglobal.com/english/new_pr_180603.htm), I do not recall anything. A quick survey of Web sites of major localization industry bodies, publications, training bodies and consultancies shows that they do not meet most of the World Wide Web Consortium (W3C) requirements for accessibility.
|
|
A multilingual and accessible Web site created for the 2003 World Summer Games of the Special Olympics
|
|
Originally thought of as a US-centric mindset, accessibility has made significant advances globally. Most technology companies are now aware that accessibility is not just "the right thing to do" on social-inclusion grounds, but it is an essential selling point, central to developing markets and mandatory for public-sector contracts and large corporate deals worldwide.
Accessibility Is Not Just About the Disabled
Although typically we think of accessibility in terms of visual, hearing, dexterity, cognitive disabilities and so on, this concept of disability is very limiting in terms of the need for accessible technology. More than 50 million Americans have some sort of disability, and the numbers are increasing as the population ages. I now like to think of myself as "temporarily abled."
In 2003, Microsoft commissioned a report (www.microsoft.com/enable) that found that in the United States, 60% of adults between the ages of 18 and 64 are likely to benefit from the use of accessibility features in software products.
Such technology offers a wide range of benefits. Accessibility is about usability for everyone. For example, assistive technologies also facilitate the use of PDAs and other mobile devices. Just as good product design takes internationalization into account, so too should it be about accessible design. In fact, accessibility features per se can even make product localization an easier task.
Accessibility Is Global
A large number of people are affected. Over 50 million Americans, tens of millions of
people in the European Union (EU) and half a million worldwide have a
disability. Disability knows no boundaries, languages or borders.
Technology accessibility means that products and services can be used by everyone regardless of location, experience, physical or mental capacity or computer configuration. Accessibility is usually discussed in relation to people with disabilities because they are likely to be the most disadvantaged here but as we have seen, it does not stop there.
In Australia, the Australian Human Rights and Equal Opportunity Commission sued the organizers of the 2000 Sydney Olympics. The suit alleged that the Olympic organizers had committed a breach of the Australian Disability Discrimination Act by failing to make their Web site accessible to people with visual impairments. You might contrast this with the multilingual and accessible Web site created for the 2003 World Summer Games of the Special Olympics.
Legal Requirements
In the United States, the key legislation concerning technology accessibility is Section 508 of the Rehabilitation Act (Amended) 1998. This act defines the minimum levels of accessibility for software, Web content and applications, telecommunications, video, multimedia, personal computers and so on. Although it focuses on the US federal sector, large companies and other public sector bodies comply with its requirements.
The EU is also concerned with accessibility, stating, "Special attention should be given to disabled people and the fight against info-exclusion." In 1999, the European Commission launched an initiative to ensure that all Europeans could benefit from the information society. This was followed in 2000 by the eEurope 2002 Action Plan to ensure that people with disabilities benefit fully from the Internet and Web technologies ("e-Accessibility"). In 2001, the Commission adopted "eEurope 2002: Accessibility of Public Web Sites and Their Content," which aimed at improving the accessibility of public Web sites for people with disabilities and for older people so they could access information and take full advantage of the potential for e-government. Details are available at http://europa.eu.int/information_society/topics/citizens/accessibility/index_en.htm (Memo to EU: Understandable language is also an accessibility requirement.)
The EU recognizes the importance of the Internet as part of society and the need to offer a "technologically neutral access" to public information for all. It also acknowledges the key role of the W3C's Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines (WCAG) version 1.0 (WCAG 1.0) as the de facto global standard for the design of accessible Web sites.
National legislation in European countries enacting equality of status, anti-discrimination or direct Web accessibility laws provides additional weight for further enforcement of wider access to the Web. The Euroaccessibility Consortium (http://euroaccessibility.org) has emerged to address any "fragmentation" of standards and to develop testing and certification methodology for accessibility, again based on the WAI guidelines.
Localization as a Form of Accessibility
Now, let us look at the strong common interests between accessibility and localization. Localization should champion global accessibility. Why? Because by delivering equivalent information to different audiences, we could think about localization as a type of accessibility in its own right.
There are different standards for various technologies, so I will concentrate on the work of the W3C's WCAG in establishing core accessibility principles and HTML techniques. The Internet is one of the most visible aspects of technology and an area where usability can suffer and costs soar if standards are not used properly.
|
| Area |
Localization Concern |
Accessibility Concern |
| Language detection |
✓ |
✓ |
| Clear, understandable text |
✓ |
✓ |
| Externalized text from graphics and multimedia |
✓ |
✓ |
| Abbreviations and acronyms |
✓ |
✓ |
| Tabular data |
✓ |
✓ |
| Separate content from presentation |
✓ |
✓ |
HTML Accessibility and Localization Concerns
I have broken down the W3C recommendations into presentation, structural and authoring categories (the WCAG uses different categorization, which is available at www.w3c.org/TR/WCAG10). Think about how some of these accessibility themes might sound familiar to localizers: the separation of presentation and content, the writing of understandable text, the avoidance of slang and jargon and so on.
Presentation. The guidelines recommend that authors use style sheets to control layout and presentation, externalizing the rendering information from the document's content. This means avoiding the use of FONT elements in documents, the inappropriate use of HTML elements for formatting (such as the use of the BLOCKQUOTE elements and list elements for indenting, for example) and the hard coding of rendering information into the content. This is basic internationalization ("Internationalization Features in XML and XLIFF," MultiLingual Computing & Technology #46 Volume 13 Issue 2, available at www.multilingual.com/obroin46.htm).
The WCAG recommends taking great care with the use of the COLOR attribute. For accessibility reasons, information and functionality should not rely on the use of color for significance or operation. A visually impaired/color blind user cannot understand the intention. Color is an established area of contention for localization, too. We already know how the perception of color varies by locale. For more information, see Guide to Macintosh Software Localization (Addison-Wesley, 1992).
Structural. The guidelines recommend marking up document headings logically and always using a TITLE element so that disabled users can understand the flow and logic of a document. This, too, is a useful aid in localization, providing proper identification, context and logic to localizable content.
Another accessibility recommendation is the use of a consistent style of presentation and use of navigation mechanisms. Consider how this could aid localization QA efforts, not having to stop or log a bug to verify if a page really should look that way, for example.
Tables are a particular problem for accessibility. To address this, along with the means to distinguish between a table intended for data or for layout, data tables should have a CAPTION element and SUMMARY attribute with information outlining the nature of the content. This kind of information is an aid to localizers too, providing context with the rest of the document.
Table heading and data cells must be associated for accessibility reasons (a screen reader "tells" a visually impaired user how they are related). If you have ever pondered how to represent the relationship between a header and data cell in XLIFF or any other text-based localizable format that lacks preview, you will empathize with the problems that screen-reader applications have in interpreting table data.
Without a visual preview to associate the headers with the data cells, it is difficult to understand the relationships between the data in the cells and to deliver an accurate localization. The WCAG recommends (among other methods) the use of the TH element with an ID attribute and the TD element with a HEADERS attribute to make this relationship clear. Once done, assigning this relationship in localization formats is more obvious.
|
<TABLE border="0" summary="This table shows the language and currency used in different countries">
<CAPTION>Currency and Language By Country</CAPTION>
<TR>
<TH id="country">Country</TH>
<TH id="language">Language</TH>
<TH id="currency">Currency</TH>
<TR>
<TD headers="country">United Kingdom</TD>
<TD headers="language">English</TD>
<TD headers="currency">Pound Sterling</TD>
<TR>
<TD headers="country">Germany</TD>
<TD headers="language">German</TD>
<TD headers="currency">Euro</TD>
</TABLE>
|
| HTML example showing table heading and data cells association |
|
Avoid the use of the PRE element for formatting tabular data. It is impossible to easily localize a table "faked" in HTML using PRE. So, too, the use of PRE in this manner makes tabular data inaccessible.
With regard to graphical and audio content, accessibility recommendations require the provision of a text equivalent. To achieve this requirement, use ALT, LONGDESC, TITLE attributes and so on. This "alternative text" fulfills an equivalent function of the original content. In localization terms, not only can these descriptions provide additional context for localizers, but we could also consider this as one way of delivering localized equivalents to locales with low-specification computers or when the business case does not justify the cost of full applet or multimedia localization.
Here is an example of the use of HTML's ALT and LONGDESC attributes (the i18n
_basics.htm file contains detailed descriptions of the graphic file).
<IMG src="i18n_1.gif" alt="Internationalization Basics" longdesc="i18n_basics.htm">
Authoring. The category of authoring standards is where accessibility and localization probably have the strongest synergy. The accessibility requirement to provide easily understandable text with its promise of improved source texts is worthy of strong support by the localization industry.
The accessibility recommendation is to use the clearest and simplest language for authoring content. Keeping terms consistent, using understandable words and avoiding slang and jargon are as important to accessibility as to localization.
The adoption of a writing style for those with reading/cognitive disabilities also has localization advantages. It opens the door for the enforcement of writing standards and the adoption of controlled authoring, making text easier to localize and improving efficiencies for translation memory and machine translation.
The WCAG recommends the use of the active voice for accessible content, and this is a familiar best practice for the writing of localization-friendly text. Avoiding complex structures in text, multiple clauses and redundancy also helps accessibility and localization.
Writers should use terse, clear and accurate headings that make use of distinguishing information. Hyperlink text should be meaningful when read or heard out of context, reflecting the target document offering a localization saving, as well as an improved user experience all round. Each paragraph should be limited to one main idea, improving localizability and updating. Keep text short, as some accessibility technologies may not be able to accommodate text that scrolls off the screen, in the same way that text expansion of localized text can defeat the intention of the user interface.
Even the most basic authoring technique of using a spell checker is important. A visually impaired reader using a screen-reading device may not be able to figure out the screen reader's best guess for a word spelled incorrectly. The use of a grammar checker further ensures comprehension of the text. Easily comprehended text will also help people who are not native speakers, increasing global market coverage.
The use of acronyms and abbreviations has long been problematic for many. Use the ACRONYM and ABBR elements with a TITLE attribute to spell out these abbreviations and acronyms when they first occur. Localizers can also use this information. A screen reading utility can handle most common acronyms, but industry-specific ones or writer creativity in this area makes it impossible to pronounce them in any meaningful sense or to localize easily.
<H4>The following are <ACRONYM
title="Internationalization">I18n</ACRONYM> basics:</H4>
Example use of the ACRONYM element
Another practice for both localization and accessibility is to locate a list of acronyms and abbreviations and their meanings in one easily referenced place, such as a glossary.
All this will sound familiar to anyone who promotes improved localization by preventing verbose, convoluted source texts littered with multiple clauses and inconsistencies.
The accessibility guidelines recommend the use of the LANG attribute. This requirement is to identify the primary language and when the language changes. Accessibility screen readers tell the visually impaired user when the content is in a particular language. The popular Jaws for Windows screen reader (www.freedomscientific.com) claims support for more than ten languages and has been translated into many more). Indicating the language type by the use of the LANG attributes with elements such as SPAN and Q, for example, or the attribute HREFLANG with the A element not only helps accessibility but also indicates to localizers when a particular run of text should remain untranslated or translated.
Using some of the themes we have outlined, further exploration of the common interests of accessibility and localization is possible. For example, consider the guideline about avoiding the use of automatic, timed page-refresh. With text expansion during localization, the timed response may not be enough for the user to read the information. And so on.
Conclusion
I have looked at accessibility as a global, social-political and commercial necessity in the last few years and how we need to think of it in broader terms than just disability. The main points are:
Accessibility does not respect language differences or location. Walking around San Francisco looking at the ATM screens in Chinese and Spanish, I also notice the Braille keypad and the socket for audio hearing devices used by visually impaired customers.
Accessibility is not a benefit for "the disableds." It is about everyone, for everyone. Just as we all use wheelchair ramps, sidewalk cutouts and closed captions without thinking because they make our lives easier, accessibility features benefit localization, too.
Awareness of the importance of accessibility within localization groups is too low at present. Attitudes need to change. There are common areas of concern to both accessibility and localization, as shown in the accompanying table.
Localization groups should support accessibility features and initiatives, taking advantage of "doing the right thing" that will also have positive implications for localization in general. 
Ultan Ó Broin of Oracle is also webmaster for the Marina Dock nonprofit corporation in San Francisco. He can be reached at webmaster@marinadock.org
This article reprinted from #63 Volume 15 Issue 3 of MultiLingual Computing & Technology published by MultiLingual Computing, Inc., 319 North First Ave., Sandpoint, Idaho, USA, 208-263-8178, Fax: 208-263-6310.
|
April/May, 2004
|