W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2002

Re: comments on techniques doc revisions

From: Charles McCathieNevile <charles@w3.org>
Date: Sun, 24 Mar 2002 16:04:27 -0500 (EST)
To: Jan Richards <jan.richards@utoronto.ca>
cc: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.30.0203241558430.12199-100000@tux.w3.org>
On Fri, 22 Mar 2002, Jan Richards wrote:

  --- imp1 ---------------------------------------------

  > When generating a natural language translation of text, produce the
  > simplest and clearest possible use of the new language. [T????] @@CMN
  > Proposal@@
  > SEEMS TO ME TO NEED SOME BETTER WORKING - 'THE SIMPLEST AND CLEAREST
  > POSSIBLE' !!!  I THINK THE AIM IS TO SUPPORT, EG  PEOPLE WHO NEED
  > LITERAL AS OPPOSED TO METAPHORIC OR POETIC TEXT BUT THIS NEEDS TO BE
  > SPELT OUT MORE CLEARLY, I THINK.

  JR: Can you propose new text?

Given that I have an action item marked against me for this text, let me
propose the following:

  When translating text from one language to another (e.g. French to
  Japanese) produce text which uses simple grammar and common vocabulary.

LN
  > 1.3 - I THINK THIS SHOULD BE
  > Ensure that when the tool automatically generates CONTENT OR markup

  JR: This is already an issue. Does the group agree?

I agree with Liddy.

  --- imp2 ---------------------------------------------

  > I THINK
  >   If the tool produces inaccessible markup, whether it is valid or
  > not, see ATAG10 4.1 for checking techniques.
  > IS TRYING TO SAY
  >   If the tool produces VALID markup, see ATAG10 4.1 for ACCESSIBILITY
  > checking techniques.

  JR: How about: "Even if the tool produces valid markup, see ATAG10 4.1
  for ACCESSIBILITY
  checking techniques.

Works for me.

  --- imp3 ---------------------------------------------

  > WHEN DEALING WITH THIS
  > Short Text Labels (for alternate text, titles, etc.): These types of
  > alternative equivalents require only short text strings from the
  > author, so the prompts for them may be best located as text boxes
  > within property dialogs, etc. An important consideration is that the
  > function of the object (decorative, button, spacer, etc.) will be
  > important to the instructions given to the author on what to write.
  > The object function may be prompted for or discovered by automated
  > heuristics.
  > WOULD IT BE HELPFUL TO HAVE TWO BITS - ONE CHOSEN FROM A CONTROLLED
  > VOCAB THAT SAYS WHAT THE FUNCTION OF THE OBJECT IS, AND ANOTHER THAT
  > IS THE TEXT TO BE TYPED IN??? MAYBE THIS IS A MATTER FOR WCAG??? BUT
  > IF THE FUNCTION WERE DECLARED, WOULDN'T THE TEXT BIT BE MORE EASILY
  > TESTED? AND SOMETIMES MORE EASILY GENERATED AUTOMATICALLY? SO A
  > TECHNIQUE IS TO HAVE A PULL-DOWN LIST OF THE FUNCTIONAL VOCAB.

  JR: Good idea - for WCAG.

I think that this also applies directly to ATAG and authoring interfaces,
which need to work out how to seperate a short functional equivalent from a
fuller description, and make it clear to that autthor what is required.

Chaals
Received on Sunday, 24 March 2002 16:04:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:47 UTC