Re: I18N last call comments on User Agent Accessibility Guidelines1.0

At 08:35 1999/12/06 -0500, Ian Jacobs wrote:
> "Martin J. Duerst" wrote:
> > 
> > Dear Working Group,
> > 
> > Below please find the last call comments from the Internationalization
> > (I18N) WG on the User Agent Accessibility Guidelines 1.0.
> 
> Many thanks to the Working Group for their review!

Many thanks for your quick and precise reply!



> > Note: Upon writing this comment, I also became aware of the
> > following: In particular for many forms of visual rendering
> > (in contrast to text-to-speach conversion), there is no
> > difference in rendering between various languages (exceptions
> > are hyphenation and high-quality microtypography issues).
> > In such contexts, offering the ability to switch on a notification
> > does not make sense.
> 
> I think that graphically, sufficient notification takes place with
> the use of a different font family.

This very much depends on the languages in question. There
is usually no need at all to change fonts e.g. from English
to French text; quite to the contrary, changing fonts can be
visually very confusing. This very much depends on the document
at hand, for example most dictionaries use different fonts for
different languages; other texts may use conventions anyway
used for quotes if they quote foreign language text. This has
to stay under the control of the author (or of course the user)
and should not be done automaticaly by an aplication.

Of course if the languages use different scripts, it is often
necessary to use different fonts to cover these scripts, and
in this case, a change should happen automatically, rather than
to not render some characters that are not covered by a font.

A boundary case is the distinction between e.g. Japanese and
Chinese variants of ideographs. Different default fonts should
be used by the application for pages in Japanese and in Chinese,
and probably also down to the level of a paragraph or so, but
depending on the type of document, one wouldn't want to mix
fonts inline as long as the characters are covered in one font.


> > Note: It is unclear whether 'identified but unsupported' means
> > that the UA knows e.g. that en-us (the form that appears in
> > HTML and XML) corresponds to U.S. English, or not, or can mean
> > both. This should be clarified.
> 
> Given that request, perhaps it makes more sense to clarify
> your above point about supported languages by adding a note to
> 2.3 such as:
>  
>   Note. A user agent may not support all languages. When
>         a user agent supports a language identified by a 
>         multipart identifier (e.g., "en-us"), the user agent 
>         must indicate in its conformance claim which language 
>         it claims to support (e.g., "en" alone, "en-us" alone, 
>         or both).
> 
> Please let me know if the above note make sense

Sorry, I didn't mean the question of tags and subtags (which
indeed is a good question), but the question of tag (e.g. 'en')
vs. language name (e.g. 'English'). Does 'identified' mean that
the UA knows that 'en' means 'English', or does it only mean
that the UA saw a tag with some value that happened to be 'en'.

Probably overall what should happen is some of the following:

- If the UA knows how to deal with English, deal with it.
- If the UA knows that 'en' is English, but nothing more,
  tell the user that some English text is comming (and
  then spell it out, or whatever else is the fallback mode)
- If the UA sees 'en' without knowing what it is, say
  something like 'unknown language', then spell the tag,
  then the content.

But I'm not sure how much that makes sense in view of
accessability.


As for tags/subtags, if fully spelt out, the following rules
should apply (adapted from SMIL10, which took this from HTTP11;
probably better put this into the techniques document than into
the Guidelines):

- The UA should treat as a known language, and apply the rendering
  rules it knows for this language, if and only if: 
  
    the tag for one of the languages it knows exactly equals
    the tag for the language in the document, or the tag for one
    of the languages it knows exactly equals a prefix of the tag
    for the language in the document such that the first tag character
    following the prefix is "-".

  Otherwise, the UA should treat the language as  unknown.

  Note: This use of a prefix matching rule does not imply that
        language tags are assigned to languages in such a way
        that it is always true that if a user understands a
        language with a certain tag, then this user will also
        understand all languages with tags for which this tag
        is a prefix. The prefix rule simply allows the use of
        prefix tags if this is the case.

See http://www.w3.org/TR/REC-smil/#switch for further details.

> and whether it:
> 
>   a) Uses the appropriate terminology

Some quotes from RFC 1766:

The language tag is composed of 1 or more parts:
A primary language tag and a (possibly empty) series of subtags.


> > Note: On repeated reading, I found a similar problem in
> > the definition of Selection: A viewport has at most one
> > user selection. In the case of bidirectional text, this
> > is again not true. Two different ways of selection are
> > in use: Visual selection leads to an apparent single
> > selection on screen, which however has to be represented
> > by several logically discontinuous fragments of the
> > backing store text. The other way of selection is
> > logical selection, with a single logical fragment,
> > but multiple, discontinuous fragments on screen.
> 
> I prefer the latter and propose the following parenthetical
> addition to the section on selection:
> 
>   A viewport has at most one user selection
>  (though the selection may be rendered graphically 
>   as discontinuous text fragments).

You should also mention that it may consist of logically
disconnected fragments. Besides bidi, that's possible
sometimes if you press the shift key.


Regards,   Martin.


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org

Received on Monday, 6 December 1999 23:43:52 UTC