W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2004

RE: diacritic marks

From: Ben Caldwell <caldwell@trace.wisc.edu>
Date: Thu, 18 Nov 2004 10:04:05 -0600
Message-Id: <200411181605.iAIG5nsR019416@jalopy.cae.wisc.edu>
To: "'Lisa Seeman'" <lisa@ubaccess.com>, <w3c-wai-gl@w3.org>

This criterion was revised significantly back in Feb. 2004 when we combined 4 guidelines into what is now guideline 3.1.

I believe this is now covered in 3.1, level 2, item 1 in that for some languages, pronunciations could not be located without diacritic marks:

[snip]

The meanings and pronunciations of all words in the content can be programmatically located. 

[end snip]

Issue #608 [1] includes some of this history of the changes to this section.

Hope this helps,

-Ben

[1] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=608 



>-----Original Message-----
>From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
>Behalf Of Lisa Seeman
>Sent: Thursday, November 18, 2004 9:06 AM
>To: w3c-wai-gl@w3.org
>Subject: Re: diacritic marks
>
>
>Are diacritic marks  still required in the new draft or was i just
>missing
>it.
>
>I am forwarding an old email for context and the results of the Israel
>internet society accessibility group (ISOC IL) conclusions
>
>keep well all
>
>
>Lisa
>----- Original > > -----Original Message-----
>> > From: lisa seeman [mailto:seeman@netvision.net.il]
>> > Sent: Tuesday, February 03, 2004 8:22 AM
>> > To: W3c-Wai-Gl@W3.Org (w3c-wai-gl@w3.org)
>> > Subject: diacritic marks
>> >
>> >
>> >
>> > Hi Folks,
>> >
>> > diacritic marks - conclusions from ISOC IL
>> >
>> > We are happy with the current wording and prioritization of the
>success
>> > criteria. :)
>> >
>> >  We would like however to suggest adding a level three criteria
>that
>seas
>> > the all diacritic marks necessary for pronunciation should be
>provided,
>> and
>> > should be removable at the users request.
>> >
>> > ISOC IL have also taken a n action item to document what words need
>what
>> > diacritic marks in Hebrew to fulfill the criteria.
>> >
>> > Background
>> > Some languages use diacritic marks to give the pronunciation of a
>word.
>In
>> > some languages (like Hebrew and Arabic) most spellings, without
>diacritic
>> > marks, can be resolved to more then one word. Use of context
>enables the
>> > average reader to work out what word was intended.
>> >
>> >  Natural language processing used in screen readers can often guess
>what
>> > word is intended without diacritic marks. However all screen
>readers
>will
>> > often make mistakes.
>> >
>> > User benefits
>> >
>> > It is estimated (by ISOC -il - need to get refrences) that 3% of
>the
>> > population have a visually impaired memory which makes reading many
>words
>> > without diacritic marks extremely difficult. This segment of the
>> population
>> > can use a screen reader to help them though the reading process.
>However
>> > when the screen reader guess a word incorrectly, they will often be
>unable
>> > to correct the mistake themselves, as guessing different
>pronunciation
>of
>> > words based on an identical spelling is difficult to impossible for
>many
>> > dyslexics.
>> >
>> > It should also be remembered that screen readers are difficult to
>use
>and
>> > are expensive.
>> >
>> > Vision impaired people using screen readers are also affected by
>missing
>> > diacritic marks.  All screen readers will  make mistakes, and will
>> pronounce
>> > the wrong word. This will occur more often then an incorrect word
>> > pronunciation makes grammatical sense. The user then has to guess
>the
>> > meaning of a sentence - by as guessing different pronunciation of
>words
>> > based on an identical spelling. This extra processing time on the
>users
>> part
>> > means that they can not speed up the screen reader, and often have
>to
>> reread
>> > passages.
>> >
>> >
>> > Finally I want to personally thank everyone who help contribute and
>> resolve
>> > this difficult issue.
>> >
>> > All the best
>> >
>> > Lisa Seeman
>> >
>> >
>> >
>> > Visit us at the UB  <http://www.ubaccess.com/> Access website
>> >
>> > UB Access - Moving internet accessibility
>> >
>> >
>> >
>> > I spoke to Melingo (finally ) yesterday. I will meet up with them
>some
>> time
>> > over the next few weeks.
>> >
>> > Info so far:
>> > User agents.:
>> > what they call a screen reader ,   is   a program were you have to
>copy
>> the
>> > text into it and it will read it
>> > So their screen reader need vision.  single installation NS4000
>> > the average monthly salaried before tax and health insurance
>deductions
>is
>> > about NS5000
>> > Average salary for a dyslexic is much lower.  Don't ask about other
>> > disabilities
>> >  I t does not help  completely vision impaired  people
>> >
>> > use of a similar tool on line as a web site exists (so they will
>not
>give
>> us
>> > the right to do this) and costs  NS 350 up a month for personal use
>- if
>> you
>> > use it often it costs more.
>> >
>> > Again you need to copy and paste -it is not a portal.
>> >
>> > Authoring tools for the web owner to vowel the site
>> > It is a finished product but they do not have a fixed price-
>depends to
>> who
>> >
>> > They have another product, that makes a mp3 of a reading of your
>page.
>The
>> > user clicks a button to get the reading. For Peaple who can not
>read you
>> > then can not tell were in the page to press, Peaple who can not see
>it
>is
>> > not useful. It helps low vision .
>> >
>> > According to their head of accessibility, this is based on ten
>years of
>> > research and is proprietary.
>> >
>> > My summary:
>> >
>> > In terms of helping at the user end  we have two options.
>> > I can  try to  help Melingo t u rn their "screen reader" into a
>true
>> screen
>> > reader -  but it will be years until such a product is available.
>and
>> will
>> > be expensive for the end user.
>> >
>> >  Probably the best if slowest solution will be to sponsor research
>in
>the
>> > public domain at the Technion. Gregg, can you look into the
>possibility
>of
>> > raising financing ?
>> > Again it will take years for a partial solution.
>> >
>> > Solving the problem from the authors side is immediate and cost
>effective.
>> > In other words - It can solve the problem today,   You can add the
>vowels
>> > for free without their tools in Unicode, you can buy word processor
>were
>> you
>> > can put in the vowels, and I hope switching a week or two to put up
>a
>free
>> > JavaScript tool to make it doable to  by  anyone. Mac come with a
>similar
>> > tool.
>> > However acknowledging that for a large site this is an enormous
>amount
>of
>> > work - they can buy  Nakdan from Melingo.
>> >
>> > The clincher for me is the fact that Nakdan does make mistakes. At
>the
>> user
>> > end there is nothing to be done but confusion, because you do not
>know
>> what
>> > the word was meant to be. At the author end you can easily correct
>your
>> work
>> > using a word processor or free tool.
>> >
>> >
>> > Back to the checkpoint:
>> >
>> > I think the wording as it stands:
>> > 'Provide information needed for unambiguous decoding of the
>characters
>and
>> > words in the content'
>> >
>> > is perfect- when the  user agent decipher the word correctly, then
>the
>> > checkpoint has been   fulfilled automatically. When the  user
>agents
>> portal
>> > are unable to  adds the vowels,   then   clearly not all the
>information
>> > needed for unambiguous decoding has been   provided, and the
>> responsibility
>> > falls on the web content provider . I am going to put up a site
>that
>goes
>> > through these issues from beginning to end. It may help....
>> >
>> >
>> >
>> >  All the best,
>> >
>> > Lisa Seeman
>> >
>> > UnBounded Access
>> >
>> > Widen the World Web
>> >
>> > http://www.UBaccess.com
>> >
>> >
>> >
>> >
>> >
>>
Received on Thursday, 18 November 2004 16:07:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:32 GMT