

Priority for Techniques Dealing with Foreign Language Markup

From: Gregg Vanderheiden <po@trace.wisc.edu>
Date: Tue, 17 Nov 1998 13:38:28 -0600
Message-ID: <D088364DDC78D211B9CA00104B978B8630E7@trace170.trace.wisc.edu>

We have a technique in the latest version (which will be coming out this
afternoon) that deal with two types of foreign language markup.  One of them
has to do with providing markup to text that is buried in the body of a
larger work in another language.  For example, a document that is written
all in English with a French phrase in the middle of it.

The other deals with marking the document as a whole as to its language.
That is, putting lang = en at the top of all documents on a website that are
in English.

There are two uses for these tags.  The first is the fact that Braille
translators need to know what language the document is in in order to
properly translate the document into Braille.  The second has to do with the
emerging ability to automatically translate documents if the language in
which they are written is known.

Only the first of these is actually an accessibility issue as relates to
disability.  The second one will also be very powerful, but is probably not
something we can deal with directly in disability access guidelines.  It is
a usability or accessibility problem faced by all.

Please give both of these guidelines a read and provide comments back to us
on them.

In addition, we are looking for input with regard to priority.  It is felt
that this type of markup is important, and the debate we had with ourselves
was between whether it would be a priority one or a priority two.  In the
current guidelines, they are listed as priority two for the following

Priority one is reserved for those things that if they are not done, the
user cannot access the information on the page even with extra effort.
Priority two is designed for situations where it is hard for the user to
access a page if it is not done.

Lets look at the Whole page in and unexpected language.
An individual trying to access a page would find that the content that was
presented to them in either speech or Braille was incomprehensible to them.
This is somewhat similar to the experience that anyone has when they go to a
webpage that is written in a foreign language  -  except it is harder to
"look" at a page in braille and figure out the other language.    Lets
assume that this person is not a liguist and knows only two or maybe three
languages.  If they hit a page that comes out in Braille in a form they
cannot make sense of it, they could try one or two languages that they were
familiar with and see if the page was comprehensible in those languages.  If
not then, like all of us, they would probably give up on the page.  Thus if
it were in a language they could understand, it would be accessible but take
extra effort to find out.

Next lets look at the Embedded foreign text problem.
In this situation, a  similar problem occurs for both sighted individuals
and individuals using Braille or speech.  The user suddenly encounters some
text that they do not understand.  If using speech (or Braille) the
information could be requested on a character by character basis, and the
person might be able to figure out what the phrase was.    (presuming that
if it did use special characters that the person was able to deal with,
their synthesizer or braille program would be able to recognize the UNICODE
and correctly identify them)   The worse case is that the user, just like
every individual without a disability who is also not a linguist, will not
know what the foreign quotation means unless it is translated someplace in
the text.

In either case, it did not appear as if the individual with a disability was
at anymore of a significant disadvantage in accessing the information than
the majority of the people who are not multi-lingual.

Since it does provide severe usability problem, however, it was rated as a
priority two.

We also considered a priority one except that there have been increasing
complaints from people about sites that fail to make accessibility ratings
but which were completely usable by everyone who went to try them.
Declaring a site of 16,000 pages as being inaccessible when it is completely
accessible except for the fact the pages do not have lang = en at the top of
them, seemed to fall in this category.  Also, we have kept in mind that
anytime we add another item to the list of priority ones we weaken all of
the other priority ones.

This was a tough call for us since we do see it as a serious usability
problem and that is the reason for this long e-mail describing some of the
thought process.

Your thoughts either concurring or differing are invited.

For the Editors

Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu, http://trace.wisc.edu/
FAX 608/262-8848
Received on Tuesday, 17 November 1998 14:34:13 GMT
