WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: soft hyphens hard coded

for

From: wolfgang.berndorfer@zweiterblick.at
Date: Jan 12, 2021 1:09AM


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

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
Patrick H. Lauke
Sent: Monday, January 11, 2021 10:19 PM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] soft hyphens hard coded

On 11/01/2021 20:13, <EMAIL 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