E-mail List Archives
Re: soft hyphens hard coded
From: Patrick H. Lauke
Date: Jan 11, 2021 2:19PM
- Next message: Sean Keegan: "Job Posting: Director, CCC Accessibility Center"
- Previous message: wolfgang.berndorfer@zweiterblick.at: "Re: soft hyphens hard coded"
- Next message in Thread: wolfgang.berndorfer@zweiterblick.at: "Re: soft hyphens hard coded"
- Previous message in Thread: wolfgang.berndorfer@zweiterblick.at: "Re: soft hyphens hard coded"
- View all messages in this Thread
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
- Next message: Sean Keegan: "Job Posting: Director, CCC Accessibility Center"
- Previous message: wolfgang.berndorfer@zweiterblick.at: "Re: soft hyphens hard coded"
- Next message in Thread: wolfgang.berndorfer@zweiterblick.at: "Re: soft hyphens hard coded"
- Previous message in Thread: wolfgang.berndorfer@zweiterblick.at: "Re: soft hyphens hard coded"
- View all messages in this Thread