- From: joanmarie via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Mar 2019 21:53:50 +0000
- To: public-css-archive@w3.org
> That's a good point, and is different from how we want assistive text to expose text-transform changes to case. It doesn't mean it isn't do-able, it just means that the accessible version of the transformed text needs to be clearly defined. You'd want to get input from people who work on tools that expose math to screen readers and Braille display and so on, to find out how they implement it. As a screen-reader developer, my preference is that the transformed/rendered text is what gets exposed via the platform accessibility APIs. For instance if the DOM text is "foo", but that gets CSS transformed into rendered text of "FOO", `atk_text_get_text(0, -1)` (and all other AtkText text-retrieval methods) should return "FOO"; not "foo". Screen readers, as a general rule, want to present the content sighted users see. Exactly how it got rendered is, more often than not, irrelevant.* Furthermore, it's a drag for an AT to have to take every single bit of accessible text, retrieve some additional property "just in case", and occasionally do additional work to transform it. The render tree already contains the final/displayed version, so please share that with me. :smile: *But if any ATs might have a need, exposing the transform property as an attribute on the accessible object shouldn't hurt anything and should be relatively easy to implement within the user agent. -- GitHub Notification of comment by joanmarie Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-475796027 using your GitHub account
Received on Friday, 22 March 2019 21:53:53 UTC