Evolving Adaptability to Create Internationalized Accessible Multi-platform Web Services

Gary Perlman
Email: perlman@acm.org
OCLC Online Computer Library Center, Inc.

To motivate the consideration of multiple aspects of accessibility in parallel, I will discuss the internationalization and accessibility of a simple form. Adding one without first considering the other can make the later addition of the other more difficult.

An ordinary form contains input elements and text.

Basic code for a form like this looks like:

<form method=GET action="myscript.cgi">
	Find:
	<input name=query>
<p>
	<input name=fulltext type=checkbox>
	Full text only
<p>
	<input type=submit value="Search">
	<input type=reset value="Reset">
</form>

To translate this into other languages, the text must be isolated and replaced by entities:

[Limit]
FullText = Full text only

[Action]
Search = Search
Reset = Reset

[Prompt]
Find = Find:

<form method=GET action="myscript.cgi">
	&Lang.Prompt.Find;
	<input name=query>
<p>
	<input name=fulltext type=checkbox>
	&Lang.Limit.FullText;
<p>
	<input type=submit value="&Lang.Action.Search;">
	<input type=reset value="&Lang.Action.Reset;">
</form>

These entities are organized in sections in a language INI file (i.e., en.ini) and translated into files with matching structure and entity names (i.e., fr.ini and es.ini).

To add accessibility features to the form, we can add label tags to associate prompts and limits with the elements they describe:

<form method=GET action="myscript.cgi">
	<label for=query>
	&Lang.Prompt.Find;
	</label>
	<input name=query id=query>
<p>
	<input name=fulltext type=checkbox id=fulltext>
	<label for=fulltext>
	&Lang.Limit.FullText;
	</label>
<p>
	<input type=submit value="&Lang.Action.Search;">
	<input type=reset value="&Lang.Action.Reset;">
</form>

This is an efficient enhancement because it did not affect internationalization or localization.

ACCESSKEY: Accesskey shortcuts can be added, but these are usually the first character of what they abbreviate; should they be the same across all languages? If not, then they need to be translated and we need to ensure that all translated items requiring accesskeys begin with unique characters.

TITLE TEXT: If we decide to add title text to the form elements, it requires that new language entities be defined and translated.

[AccessKey]
StartSearch = s
ResetForm = r

[Platform=Mac]
AccessKey = Cmd

[Platform=Win]
AccessKey = Alt

[Input]
Query = Enter search terms
FullText = Limit search to items with full text online
StartSearch = Click here to start your search\
	(&AccessKey;-&Lang.AccessKey.StartSearch;)
ResetForm = Click here to reset form values\
	(&AccessKey;-&Lang.AccessKey.ResetForm;)

<form method=GET action="myscript.cgi">
	<label for=query>
	&Lang.Prompt.Find;
	</label>
	<input name=query id=query
		title="&Lang.Input.Query;"
	>
<p>
	<input name=fulltext type=checkbox id=fulltext
		title="&Lang.Input.FullText;"
	>
	<label for=fulltext>
	&Lang.Limit.FullText;
	</label>
<p>
	<input type=submit value="&Lang.Action.Search;"
		title="&Lang.Input.StartSearch;"
		accesskey="&Lang.AccessKey.StartSearch;"
	>
	<input type=reset value="&Lang.Action.Reset;"
		title="&Lang.Input.ResetForm;"
		accesskey="&Lang.AccessKey.ResetForm;"
	>
</form>

On different hardware/software platforms, different keys are used for accesskey shortcuts, represented above with conditional sections.

CONCLUSIONS: A simple form is now complicated by adapting to different platforms. Adding accessibility features added new language entities (and another round of translation). If these dependencies are not considered in advance -- if the developers do not plan for internationalization AND accessibility -- then internationalization can compete with accessibility. If they, along with other accessibility issues, are considered in advance, then it is less likely that they need to compete.

Very desirable to know percentages of current/potential markets using different hardware/software platforms, language.