I18N last call comments on User Agent Accessibility Guidelines 1.0

Dear Working Group,

Below please find the last call comments from the Internationalization
(I18N) WG on the User Agent Accessibility Guidelines 1.0.

These comments are a bit late, due to the fact that we had our
meeting at the end of last week. This delay has been negotiated
between myself and Ian Jacobs.

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.

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.


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.

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.

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.


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.


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.


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.


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 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.

- 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.

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


Regards,   Martin.




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

Received on Monday, 6 December 1999 03:36:19 UTC