E-mail List Archives
Thread: soft hyphens hard coded
Number of posts in this thread: 15 (In chronological order)
From: wolfgang.berndorfer
Date: Mon, Jan 11 2021 12:37PM
Subject: soft hyphens hard coded
No previous message | Next message →
Is hyphenation underestimated in the WAI?
Sorry, but I must get verbose to describe the background:
UAAG 2.0 1.4.6 is only AAA and passes as soon as it's possible to use
stylesheets. Correct? So, every HTML-page passes the SC.
WCAG don't deal hyphenation at all yet and in 2.2. I just found a discussion
in the LVWG from 2016, which faded out soon.
Problem:
*­* determines in HTML a potential visual break at the LINE END and an
interruption in speech synthesizers on EACH instance.
The aural interruptions can be annoying or even cause incomprehensibility.
These problems where lately discussed in the German JAWS mailing list.
The problem occurs when shy is hard coded extensively. Seems, there are
tools used for such hard coding hyphenation in German texts.
Needs for SCs:
If browsers were advised to implement language appropriate hyphenation in
UAAG, no further extensive hard coding hyphenation would be necessary and
could be deprecated. (good for TTS)
The shy-element could be strictly reduced to distinguish between differences
in meaning and pronunciation. As e.g., in German "Brautraum" can mean
Brau-traum (brewing dream) and Braut-raum (bride room).
Then the CSS hyphens values could be applied more effectively:
*none* for texts easy to be read.
*manual* for SR.
*auto* for small devices.
And there could be a SC 3.1.xx, which encourages to offer settings between
hyphenation auto | manual | none.
What do you think? I ask the WebAIM-group and not the WAI interest group,
because here is the broader community with more SR users, I suppose.
Wolfgang
From: Patrick H. Lauke
Date: Mon, Jan 11 2021 12:48PM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
On 11/01/2021 19:37, = EMAIL ADDRESS REMOVED = wrote:
> Is hyphenation underestimated in the WAI?
>
> Sorry, but I must get verbose to describe the background:
>
>
>
> UAAG 2.0 1.4.6 is only AAA and passes as soon as it's possible to use
> stylesheets. Correct? So, every HTML-page passes the SC.
>
> WCAG don't deal hyphenation at all yet and in 2.2. I just found a discussion
> in the LVWG from 2016, which faded out soon.
>
>
>
> Problem:
>
>
>
> *­* determines in HTML a potential visual break at the LINE END and an
> interruption in speech synthesizers on EACH instance.
To me, this sounds like a bug/shortcoming in speech synthesizers, rather
than anything that WCAG or authors should have to address. Soft hyphens
should not be causing a pause at all, I'd argue. Suggest this is brought
up with AT developers?
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: wolfgang.berndorfer
Date: Mon, Jan 11 2021 1:13PM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
Thanks Patrick for your estimation,
I thought of that too, but my tests with different German speech
synthesizers in different AT (jaws & nvda) and browsers showed similar
experiences.
And since I didn't find any spec, I thought, there should be one and where
if not in UAAG?
Wolfgang
From: Patrick H. Lauke
Date: Mon, Jan 11 2021 2:19PM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
On 11/01/2021 20:13, = EMAIL ADDRESS REMOVED = wrote:
> Thanks Patrick for your estimation,
>
> I thought of that too, but my tests with different German speech
> synthesizers in different AT (jaws & nvda) and browsers showed similar
> experiences.
So it's a fault with most synthesizers/ATs then? Or how browers output
it to the accessibility APIs/expose it in the accessibility tree? If the
latter, a bug to file against browsers.
Again, soft hyphens, CSS-based hyphenation, etc are visual properties
that should not impact how something is aurally announced.
> And since I didn't find any spec, I thought, there should be one and where
> if not in UAAG?
UAAG 2.0 1.4.6 is about the visual presentation, nothing to do with how
it's output as speech by AT.
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: wolfgang.berndorfer
Date: Tue, Jan 12 2021 1:09AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
I try it again with an example:
Given the word *hyphenation*. These are the hyphenation points:
Hy¡Ephen¡Eation
A browser with an auto-hyphenation mechanism like Firefox would wrap at
these hyphenation points if the word wouldn¡¦t fit in the line as a whole.
I found no problems in pronunciation by any speech synthesizer, whether the
word was wrapped or not.
Imagine, there was an island called *hyphe*. Their inhabitants could be
called the hyphenation with the following hyphenation point:
Hyphe¡Enation
The library for auto-hyphenation in the browser has no exception for the
Hyphe-Nation. So, the author must manually code the hyphenation point in
HTML:
Hyphe­nation
The word is correctly wrapped visually and:
The word is correctly pronounced by speech synthesizers. (There should be a
small pause between *hyphe* and *nation* to hear the difference). I didn¡¦t
hear any aural problems for that usage. So, the pause is not a bug of
synthesizers.
Now, because not every browser uses auto-hyphenation yet, some authors hard
code the hyphenation points manually (probably using some tools to do so):
hy­phen­ation
No big problem for visual layout, except that the CSS *hyphens: manual*
setting shows more often hyphenations.
But it is a significant problem, when listening to the text. Just paste the
code in HTML and hear the difference with all that pauses.
So, if there was an auto-hyphenation in every browser, excessive manual
hyphenation could be deprecated.
Therefore, there should be a requirement for UA:
Provide auto-hyphenation.
And there should be a SC for authors:
Provide manual hyphenation only for meaningful differentiation.
Wolfgang
From: Mallory
Date: Tue, Jan 12 2021 1:28AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
> A browser with an auto-hyphenation mechanism like Firefox would wrap at these hyphenation points if the word wouldn't fit in the line as a whole.
Since mechanical separation of words isn't something browsers are capable of (computers are still terrible at deciphering context of language), I cannot imagine a browser correctly hyphenating better than a human.
Additionally, where hyphenation happens and is acceptable seems to differ between languages. For example, Dutch newspapers seem to have no issue with hard word-breaks in random positions of words, which I think is gross and sloppy, but there it is. I don't think Dutch language pages ever use ­.
So instead of browsers trying and failing, I think the speech engines should simply code in a full ignore on ­ characters. They should never expose them unless the browser is actually inserting a "-" character visually (and then do whatever they normally do with a hyphenated word). So far as I know, there is no requirement to pause at a visible hyphen. That depends on the speech engine AND the user's own settings, not user agents. NVDA doesn't generally even announce dashes within content at the default verbosity level (this makes date ranges sound... interesting :)
cheers,
_mallory
On Tue, Jan 12, 2021, at 9:09 AM, = EMAIL ADDRESS REMOVED = wrote:
> I try it again with an example:
> Given the word *hyphenation*. These are the hyphenation points:
> Hyâ§phenâ§ation
> A browser with an auto-hyphenation mechanism like Firefox would wrap at
> these hyphenation points if the word wouldn't fit in the line as a whole.
> I found no problems in pronunciation by any speech synthesizer, whether the
> word was wrapped or not.
>
> Imagine, there was an island called *hyphe*. Their inhabitants could be
> called the hyphenation with the following hyphenation point:
> Hypheâ§nation
> The library for auto-hyphenation in the browser has no exception for the
> Hyphe-Nation. So, the author must manually code the hyphenation point in
> HTML:
> Hyphe­nation
> The word is correctly wrapped visually and:
> The word is correctly pronounced by speech synthesizers. (There should be a
> small pause between *hyphe* and *nation* to hear the difference). I didn't
> hear any aural problems for that usage. So, the pause is not a bug of
> synthesizers.
>
> Now, because not every browser uses auto-hyphenation yet, some authors hard
> code the hyphenation points manually (probably using some tools to do so):
> hy­phen­ation
> No big problem for visual layout, except that the CSS *hyphens: manual*
> setting shows more often hyphenations.
> But it is a significant problem, when listening to the text. Just paste the
> code in HTML and hear the difference with all that pauses.
>
> So, if there was an auto-hyphenation in every browser, excessive manual
> hyphenation could be deprecated.
>
> Therefore, there should be a requirement for UA:
> Provide auto-hyphenation.
> And there should be a SC for authors:
> Provide manual hyphenation only for meaningful differentiation.
>
> Wolfgang
>
>
From: Patrick H. Lauke
Date: Tue, Jan 12 2021 1:43AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
On 12/01/2021 08:09, = EMAIL ADDRESS REMOVED = wrote:
> Hypheâ§nation
> The library for auto-hyphenation in the browser has no exception for the
> Hyphe-Nation. So, the author must manually code the hyphenation point in
> HTML:
> Hyphe­nation
> The word is correctly wrapped visually and:
> The word is correctly pronounced by speech synthesizers. (There should be a
> small pause between *hyphe* and *nation* to hear the difference). I didn't
> hear any aural problems for that usage. So, the pause is not a bug of
> synthesizers.
Soft hyphenation characters are not intended to be pronounced/announced.
They're a signal that this is a potential hyphenation point to
*visually* break the word. Speech synthesizers should not pause, as they
shouldn't pause for CSS automatic hyphenation.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: wolfgang.berndorfer
Date: Tue, Jan 12 2021 8:16AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
Hi Patrick and all,
If shy is used exclusively for meaningful hyphenation off auto-hyphenation, it would also help to realize SC 3.1.6., I'd suppose.
I don't find a restriction for only *visual* usage of shy here:
https://unicode.org/reports/tr14/#SoftHyphen
Do you have any references for not to use shy for aural issues like in pronunciation?
It is a hack but is it also a possible mechanism for SC 3.1.6?
I looked it up and found that shy is not mentioned in the understanding-article for 3.1.6:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-pronunciation.html
But again, if shy were used exclusively for meaningful hyphenation off auto-hyphenation, it would also help to realize 3.1.6., I'd suppose. Two flies at once: meaningful visual hyphenation and pronunciation.
Wolfgang
From: Mallory
Date: Tue, Jan 12 2021 8:42AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
If you want people to know how to pronounce things, you don't hide the hyphen and don't use ­.
You use a real hyphen, so people with disabilities but no screen readers have equal access. Why should only those with speech synthesisers benefit? And should makers of things like TextHelp or other reading-assistance text-to-speech softwares implement a pause where hyphens are?
cheers,
Mallory
On Tue, Jan 12, 2021, at 4:16 PM, = EMAIL ADDRESS REMOVED = wrote:
> Hi Patrick and all,
>
> If shy is used exclusively for meaningful hyphenation off
> auto-hyphenation, it would also help to realize SC 3.1.6., I'd suppose.
> I don't find a restriction for only *visual* usage of shy here:
> https://unicode.org/reports/tr14/#SoftHyphen
> Do you have any references for not to use shy for aural issues like in
> pronunciation?
>
> It is a hack but is it also a possible mechanism for SC 3.1.6?
> I looked it up and found that shy is not mentioned in the
> understanding-article for 3.1.6:
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-pronunciation.html
>
> But again, if shy were used exclusively for meaningful hyphenation off
> auto-hyphenation, it would also help to realize 3.1.6., I'd suppose.
> Two flies at once: meaningful visual hyphenation and pronunciation.
>
> Wolfgang
>
>
From: Philip Kiff
Date: Tue, Jan 12 2021 9:00AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
On 2021-01-12 10:16, = EMAIL ADDRESS REMOVED = wrote:
> But again, if shy were used exclusively for meaningful hyphenation off auto-hyphenation, it would also help to realize 3.1.6., I'd suppose. Two flies at once: meaningful visual hyphenation and pronunciation.
Patrick Lauke wrote:
> Soft hyphenation characters are not intended to be pronounced/announced.
> They're a signal that this is a potential hyphenation point to
> *visually* break the word. Speech synthesizers should not pause, as they shouldn't pause for CSS automatic hyphenation.
>
> P
The only time I can recall purposely using shy is in a table header
cell: to manually position a line break in a word in order to allow the
column width to be thinner so it more closely matched the width of the
data in the column. It was definitely not meant to be meaningful when I
used it: purely cosmetic or visual.
Phil.
Philip Kiff
D4K Communications
From: Sandy Feldman
Date: Tue, Jan 12 2021 9:07AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
Hey Mallory,
The problem with a real hyphen is you don't know if the word is going to
need to break on any particular set up. Browser window sizes, font size
preferences, device in use, are completely out of control.
Consider the people of Hyphen Nation.
cheers,
Sandy
On 2021-01-12 10:42 a.m., Mallory wrote:
> If you want people to know how to pronounce things, you don't hide the hyphen and don't use ­.
>
> You use a real hyphen, so people with disabilities but no screen readers have equal access. Why should only those with speech synthesisers benefit? And should makers of things like TextHelp or other reading-assistance text-to-speech softwares implement a pause where hyphens are?
>
> cheers,
> Mallory
>
> On Tue, Jan 12, 2021, at 4:16 PM, = EMAIL ADDRESS REMOVED = wrote:
>> Hi Patrick and all,
>>
>> If shy is used exclusively for meaningful hyphenation off
>> auto-hyphenation, it would also help to realize SC 3.1.6., I'd suppose.
>> I don't find a restriction for only *visual* usage of shy here:
>> https://unicode.org/reports/tr14/#SoftHyphen
>> Do you have any references for not to use shy for aural issues like in
>> pronunciation?
>>
>> It is a hack but is it also a possible mechanism for SC 3.1.6?
>> I looked it up and found that shy is not mentioned in the
>> understanding-article for 3.1.6:
>> https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-pronunciation.html
>>
>> But again, if shy were used exclusively for meaningful hyphenation off
>> auto-hyphenation, it would also help to realize 3.1.6., I'd suppose.
>> Two flies at once: meaningful visual hyphenation and pronunciation.
>>
>> Wolfgang
>>
>>
From: wolfgang.berndorfer
Date: Tue, Jan 12 2021 9:27AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
Hi Mallory
I completely agree to your objections on a triple-A level. (3.1.5 Reading Level and 3.1.6 Pronunciation are AAA)
Seems, ­ won't serve as a sufficient technique for 3.1.6., since it doesn't provide techniques for any reading level.
But would you agree that shy can be helpful for pronunciation too, if it is used with meaning for hyphenation? It would help SR and won't do any harm for easy to read under CSS hyphens: none.
Wolfgang
From: Patrick H. Lauke
Date: Tue, Jan 12 2021 9:33AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
On 12/01/2021 15:16, = EMAIL ADDRESS REMOVED = wrote:
> I don't find a restriction for only *visual* usage of shy here:
> https://unicode.org/reports/tr14/#SoftHyphen
> Do you have any references for not to use shy for aural issues like in pronunciation?
I have a *lack* of references that it should in any way affect
pronunciation. And references talk about it being an invisible
indication that this is a position that user agents should use when
doing needing to hyphenate to fit a word into a particular line/where
they can visually break, for visual layout. Which all leads me to say
that it's not intended to be used to influence pronunciation in any way.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Tue, Jan 12 2021 9:36AM
Subject: Re: soft hyphens hard coded
← Previous message | Next message →
On 12/01/2021 16:27, = EMAIL ADDRESS REMOVED = wrote:
> I completely agree to your objections on a triple-A level. (3.1.5 Reading Level and 3.1.6 Pronunciation are AAA)
>
> Seems, ­ won't serve as a sufficient technique for 3.1.6., since it doesn't provide techniques for any reading level.
Also, just to be clear...we're talking about UAAG here. Which is aimed
at what user agent should do/provide. Not what authors marking up
content should or shouldn't do.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: wolfgang.berndorfer
Date: Tue, Jan 12 2021 11:48AM
Subject: Re: soft hyphens hard coded
← Previous message | No next message
For me all perspectives are interesting: Browser implementation, WCAG requirements, usability for SR and easy to read.