Open Road

In the aftermath of the Community Languages Online report I’ve had time to start teasing out my thoughts on web internationalisation and accessibility as it applies to government information in community languages.

Web accessibility is well entrenched in federal and state governments’ web standards in Australia. Generally web developers understand the need for web accessibility. Government departments and agencies require web accessibility and will make the effort to get their websites to comply with accessibility standards.

This seems to work smoothly in monolingual environments, but there is a fracture point. Looking at Australian government websites, it becomes apparent that key aspects of web accessibility (and its relationship with web internationalisation) is only superficially understood.

In a future post I’ll discuss two particular federal government websites. For the moment I’ll concentrate on my understanding of web accessibility as it applies to content in community languages.

First a few clarifications. I’m not discussing web internationalisation in general, but rather the development of web content on Australian government websites in community languages. In the Australian context community languages refers to the mother languages of migrants and refugees who have come to Australia to live. The designation community languages could include major European and East Asian languages, but would also include lesser used languages of Africa, Asia and the Pacific Islands.

Each government website taken as a unit, could be considered as an essentially monolingual site. Only a small subset of information is translated into community languages. Target languages may differ from department to department.

Most content is made available using a mediated access model. By this I mean that the person accessing the information is not the end user of the information. The website itself, the navigation mechanism and location tools are all English based. The site is intended to be accessed by a staff member of a health, welfare, justice or employment sector service provider on behalf of a client.

Very few sites are optimised for mediated access.

Fewer government sites are designed for direct access. Such sites provide a navigation mechanism in the target community languages allowing community leaders or members of the CALD communities to directly access the information themselves in their own language.

It is important to recognise that some migrants and many refugees will not have sufficiently high literacy levels in English to be able to access the information they require on government websites.

For many government websites there is no clear target audience. Many websites fall into the mediated access model by accident or lack of planning rather than by clear and deliberate design. I feel that the issue of audience is central to accessibility and central to the mess we have in Australia with online translated government information.

WCAG 1.0 and community languages

For WCAG 1.0, web developers and designers should ensure graceful transformation of a website and should make content understandable and navigable. These themes are universal, i.e. web developers should embrace these themes even for languages that present challenges to the developers or test their knowledge.

I’ll tackle each of the relevant WCAG 1.0 guidelines individually.

Guideline 1. Provide equivalent alternatives to auditory and visual content.

Checkpoint 1.1 for this guideline is the need for provision of textual alternatives for non-textual elements. A common navigation technique on government websites is to use a small graphic image of the name of the language or a short phrase in that language to link to content in the target community language.

The best solution is not to use an image in this case. Using UTF-8 for your website allows you to use text for the link rather than an image. Many government websites have gone for images rather than textual labels for the navigation links. Obviously checkpoint 1.1 can be easily addressed if an alt attribute is added to the img element.

In practice government websites tend to have no alt attribute in these cases, an empty alt attribute or an alt attribute where the text is in English.

An example from one Australian federal government website:

<img alt="Somali Language Publications" src="images_languages/somali.gif" height="30" width="185" />

For this example I’ve shortened the value of the src attribute to make it fit easily on the page.

The image displays the Somali text “Waxaan ku hadalnaa luqaddaada“. I’ll ignore the irony that Somali can be represented in the same encodings as English and has no technical need to ever be represented as an image. And likewise I’ll ignore the fact that the alt attribute value does not bear any resemblance to the the English translation of the Somali phrase: “we speak your language”.

The key issue is the mismatch of audiences between the image and the value of the alt attribute. The image is clearly intended for an audience that can read Somali. Just as obviously, the alt attribute is for an English reading audience.

I’d suggest that the alt attribute value should be written in Somali rather than in English, e.g.

<img lang="so" xml:lang="so" alt="Waxaan ku hadalnaa luqaddaada" src="images_languages/somali.gif" height="30" width="185" />

And obviously if the alt attribute value is in Somali, why not just have a textual link in Somali rather than an image?

If I were being cynical, I’d suggest that the English alt text is there purely for the convenience of the web developers rather than the end users of the website.

Checkpoint 3.1, a priority level 2 checkpoint, requires the use markup rather than images to convey information. In this instance the checkpoint indicates that web developers should not use images to represent text.

Guideline 4. Clarify natural language usage

I’ll concentrate on checkpoints 4.1 and 4.3. These checkpoints involve language tagging. Checkpoint 4.1 requires any change in the natural language of the text or text equivalents in a document be identified. This is achieved by applying a lang and/or xml:lang attribute to appropriate elements. This checkpoint has a priority level 1.

Checkpoint 4.2 is a priority level 3 checkpoint that requires the primary natural language to be identified. The most convenient method for achieving this is by adding a lang or xml:lang attribute to the html root element.

Web pages with community language content on government sites tend not to be localised pages. The pages’ templates will be in English with the header, footer, and primary navigation always in English.

The approach some developers take in this case is to mark the primary language of the web page as the community language in which the unique text content of the page is written. For other elements of the page I’d add language attributes for English on appropriate elements.

Although, on Government websites, it is more common to find the primary language identified as English. There may or may not be any markup to indicate the change in language accompanying the community language content.

Again, it is an issue of audience. Who is the intended audience of the particular page, and which language is the primary language? Is it the language that the unique content of the page is written in or is it the language of the header, footer and navigation as various government websites seem to imply?

For information on using language tags read Internationalization Best Practices: Specifying Language in XHTML & HTML Content and Language tags in HTML and XML.

it is worth noting that the language attribute does not only indicate the language of content of the element but also refers to the attributes of the element as well.

Guideline 11. Use W3C technologies and guidelines.

The core web internationalisation techniques: declaring the encoding of a document, specifying the primary language and any change in language, specifying the direction of block and in-line elements as required are part of the HTML 4, XHTML 1.0 and XHTML 1.1 markup languages.

Following web internationalization best practice is an essential element to creating accessible web sites that support community languages.

Guideline 13. Provide clear navigation mechanisms.

Knowing who your intended audience is and what access method you will use (mediated or direct) is important. This will determine various aspects of your navigation mechanisms.

If you are directly targeting CALD communities it is crucial to have a clear navigation system that allows them to easily access information.

Some government websites have community language content buried deep in the site with no navigation aids to access the translated information. In many cases the information is not discoverable or searchable as well.

Guideline 14. Ensure that documents are clear and simple.

Checkpoint 14.1 (priority 1) indicates that appropriate level of language should be used. Efforts should be made to make the text as simple and clear as appropriate to the content.

This is as relevant to translated content as it is to the original English language content. Keeping the original English language text as simple and plain as possible can assist in the translation process.

Government terminology can be complex and can be difficult to translate into the languages of humanitarian stream entrants. all efforts necessary should be made to ensure that the translations are easily understood by the target audience.

Checkpoint 14.2 (priority level 3) raises some interesting issues for community language content targeted at CALD communities with low mother language literacy levels. The checkpoint suggests that you could “supplement text with graphic or auditory presentations where they will facilitate comprehension of the page”.

For CALD communities with low mother language literacy levels there is the possibility of supplementing translated text with audio or audiovisual content.

Currently multimedia CD-ROMs and DVDs are emerging as media for providing information to new and emerging communities in preference to printed information or the use of ethnic radio. It would be feasible to adapt existing audio content to use as a supplement to translated websites.

Resources

1. Web Content Accessibility Guidelines 1.0
2. Internationalization Best Practices: Specifying Language in XHTML & HTML Content
3. Language tags in HTML and XML
4. Richard Ishida’s presentation: Designing for International Users: Practical Tips