You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for investigating this area.
When supporting multiple screenreaders inside a government, I had to resort to distributing dictionary files to users in the past to have all the department acronyms properly read. An ability to offer that at source could prove useful.
However, I did not see enough information in the current draft to understand how precedence and inheritance could happen. IMO, a user's personal preferences for pronunciation should override anything provided by either the author or the AT defaults. It gets more difficult to know how to architect this solution when deciding whether AT defaults or author should take precedent. For example, I as a user may like how my AT defaults to numbers (say it does pairs) and I don't want the author overriding that behaviour.
Reading numbers is a relatively straightforward undertaking. But I saw this draft referenced in a discussion on getting a screen reader to pronounce Hawaiian properly. I could not see any examples in the existing draft on how the spec would support such an endeavour, or how localizations might come into play. If such a thing is part of this undertaking, I think a lot of examples covering such guidance needs to be included. At an abstract level, it seems overly involved for most authoring situations.
I look forward to seeing where the group takes this work!
The text was updated successfully, but these errors were encountered:
If you feel the matters I've identified are now adequately addressed by work the group is doing, or are identified as areas needing attention, can you please provide info how you're addressing each before closing:
precedence and inheritance between user preferences, AT settings and author-supplied attributes and values (I'm only seeing one mention of user preferences in the doc)
how localizations (especially regional preferences for pronunciation) may be handled
Thank you for investigating this area.
When supporting multiple screenreaders inside a government, I had to resort to distributing dictionary files to users in the past to have all the department acronyms properly read. An ability to offer that at source could prove useful.
However, I did not see enough information in the current draft to understand how precedence and inheritance could happen. IMO, a user's personal preferences for pronunciation should override anything provided by either the author or the AT defaults. It gets more difficult to know how to architect this solution when deciding whether AT defaults or author should take precedent. For example, I as a user may like how my AT defaults to numbers (say it does pairs) and I don't want the author overriding that behaviour.
Reading numbers is a relatively straightforward undertaking. But I saw this draft referenced in a discussion on getting a screen reader to pronounce Hawaiian properly. I could not see any examples in the existing draft on how the spec would support such an endeavour, or how localizations might come into play. If such a thing is part of this undertaking, I think a lot of examples covering such guidance needs to be included. At an abstract level, it seems overly involved for most authoring situations.
I look forward to seeing where the group takes this work!
The text was updated successfully, but these errors were encountered: