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

"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!

> Please note that the comments below contain links to W3C Member
> Confidential material such as the minutes of our meeting; some
> of you may not be able to follow these links, but that should
> not affect the ability to understand our comments; the links
> are only provided for reference.
> 
> The following is the relevant excerpt from our minutes,
> at http://www.w3.org/International/Group/1999/12/ftf8/minutes#UAGL:
> 
> ---- start of excerpt
> [Review of]
> User Agent Accessibility Guidelines 1.0
> 
> WD-WAI-USERAGENT-19991105 and
> WD-WAI-USERAGENT-TECHS-19991105 have been reviewed.
> 
> DECISION: We agreed that checkpoint 2.3 and 2.9 need more
>    work.
> 
> DECISION: We agreed that multiple active insersion point need
>    to be allowed for BIDI.
> ---- end of excerpt
> 
> Some explanations on the comments above:
> 
> Checkpoint 2.3: This checkpoint asks to render content according
> to natural language identifiers. [Priority 1]. The problem here
> is that the number of natural languages is large, and the effort
> to support a language may be very significant. If this checkpoint
> can only be satisfied if a UA renders *all* natural languages, this
> means that it is impossible to satisfy this checkpoint. If something
> else is intended by this checkpoint, then this should be clarified.

This issue has already been raised as issue 140. I will make sure
that your proposals are discussed at our face-to-face meeting.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#140

 
> It is difficult to say exactly what the right thing to do is here,
> but the following solutions should be explored:
> 
> - Combine 2.3 and 2.9 in one checkpoint, saying that either of them
>   has to be done.
> - Link support for particular languages e.g. in visual mode and in
>   audio mode.
> - Require support for languages needed in the area the product is
>   marketed.
> - Change the definition of 'Applicable checkpoint' or of Conformance
>   to include coverage of natural languages.

That's my preferred solution.
 
> Checkpoint 2.9: It was unclear to us whether this checkpoint can
> be satisfied by not allowing configuration, or whether the
> ability to configure is a necessary precondition.

Yes. I propose the following editorial clarification:

     For identified but unsupported natural languages,
     allow the user to request notification 
     of language changes.

     Note. The user should be able to request 
            no notification of language changes.

> 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.
 
> 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 and whether it:

  a) Uses the appropriate terminology
  b) Could use a better example than "en" and "en-us".
 
> Definition Insertion Point says: A viewport has at most one
> insertion point. This is not true for bidirectional (Hebrew,
> Arabic) visually rendered text. In this case, there is logically
> always only one insertion point, but this may correspond to
> two locations on screen, and is typically represented by
> splitting the cursor into an upper half and a lower half.
> The text should be changed to mention  this, or at least
> be clarified to avoid misunderstandings in this respect.

I propose the following changes to the defn of insertion point:

  1) A viewport has at most one <INS>logical</INS> insertion point.
  2) Add this note to the end of the paragraph:

       Graphical user agents that render bidirectional text
       may render the insertion point at two locations on  
       the screen. Often, the cursor is shown as split into 
       an upper half and a lower half.
 
> 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).

> We also discussed Checkpoints 10.1 and 10.2. Handling keyboard
> state is more complicated in particular in East Asian languages
> than it is e.g. in English. However, we have not found an
> I18N-related argument that would contribute to the questions
> explicitly asked in the Status of this Document in the last call.

Ok.
 
> Upon repeated reading, I also found the following I18N-related
> points:
> 
> - Please don't forget to add a link to a translations page
>   (and errata page) once this goes to Recommendation.

The link is already in the comments on the document source.
 
> - The use of standard APIs is recommended throughout for good
>   reasons. However, it would be worth mentioning that some
>   languages/scripts are not supported by standard APIs or
>   their implementations on some platforms. In many such
>   cases, resources are also limited. The Guidelines should
>   not lead to disqualify implementations not based on standard
>   APIs in such cases, because this may affect support for
>   smaller and minority languages. The text on 'applicable
>   checkpoints' should be modified to take limits of standard
>   APIs into account.

Yes. Someone else also raised the question of "what do you do
when no standard API exists". A new definition of
"applicability" should cover this.
 
> - Checkpoints 8.5 and 2.2 refer to information about the expected
>   natural language of a target resource (via the hreflang attribute).
>   It should be noted that this attribute is most probably very
>   rarely used in actual documents. The main purpose, as far as
>   I can remember, was to be able to distinguish several otherwise
>   equivalent <link> elements.

Ok.
 
> - Definition 'Natural Language': 'by HTTP headers' should be
>   replaced by 'by the HTTP Content-Language header'.

Ok.

Thank you and the I18N WG very much, Martin, for the 
thorough and thoughtful review.

 - Ian


-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783

Received on Monday, 6 December 1999 08:35:31 UTC