New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider addition of property(ies) to expose braille string #765

joanmarie opened this Issue May 22, 2018 · 2 comments


None yet
3 participants

joanmarie commented May 22, 2018

A couple of use cases have come up in which it would be desirable to give assistive technologies braille strings which they could display as-is:

  • Abbreviated/localized role descriptions
  • Nemeth rendering for math content

With respect to the former, we created aria-roledescription so that authors could customize what is presented to the user by assistive technologies. A side effect/consequence of this feature is that it stomps on the screen reader's ability to provide abbreviated role names. For instance, if the ARIA role is button, a screen reader could abbreviate that as "btn" in order to be able to show more information at once on the refreshable braille display. But if an element has an aria-roledescription value of "Pizza slice" (to borrow an ETS example), that value overrides what the screen reader should display -- and occupies potentially more braille cells than may be desired. It would be handy if an author could specify "ps" or "slice" or whatever as the braille role name.

With respect to the latter, there are tools which can produce a spoken representation of math expressions. Assistive technologies which can take advantage of such a tool can pass the string along to be spoken. But that spoken representation is likely not what should be displayed in braille. Hypothetically, such a tool could also provide a Nemeth string which should be similarly passed along unmodified. But there's no standard means to expose this information to assistive technologies.


This comment has been minimized.


jnurthen commented May 22, 2018

This feels like a very similar problem to ruby. Maybe we could use whatever solution we come up with for that too.


This comment has been minimized.

arnog commented Oct 22, 2018

For a given expression, authoring tools might want to produce multiple representations of that expression, for example a spoken representation, a Nemeth Braille representation, a UEB Braille representation and a (plain) braille representation (particularly useful for users that know Braille but may still be learning Nemeth Braille). Having a mechanism to author this would be very useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment