search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
645 stars 125 forks source link

aria-brailledescription (to match aria-description) #1412

Open pkra opened 3 years ago

pkra commented 3 years ago

Now that we have aria-description, should there be a braille property to match?

pkra commented 3 years ago

I feel like the answer should be yes since braille users would benefit if the "simple, small description that is best experienced as a flat string, rather than by having the user navigate to them" could be further optimized for braille output.

sinabahram commented 3 years ago

I think that semantically you are 100% correct.

Practically, I'm not so sure because descriptions have either flashed onto the display or not depending on AT choices over the past few years.

If I were designing the AT, I would do what I feel is the obvious, and leave the user in control, letting them choose to display a description or not, and then a Braille-optimized one is an awesome idea, because it is opt-in on a display with incredibly limited real estate.

It would be good to hear from some others on this issue.

jnurthen commented 3 years ago

before introducing something like this I feel like we would need some real-world use cases.

pkra commented 3 years ago

As I mentioned on the call, I don't think this fits into 1.3 As @sinabahram pointed out, AT behavior is critical here. Maybe with aria-description we'll see some changes in the AT landscape and once they shake out we can assess things more adequately.

Another challenge I see is around the content restrictions for the existing braille properties; authors must either use no braille patterns or only braille patterns. In a description, I can see myself wanting to mix the two in a description; e.g., a button in a sheet music editor might have a description that would mix text with musical braille. I don't think solving that challenge is realistic in the 1.3 milestone (if at all - we have aria-describedBy after all).

In any case, we'd need to figure out Sina's point regarding AT behavior first.

mscuthbert commented 2 years ago

I can see myself wanting to mix the two in a description; e.g., a button in a sheet music editor might have a description that would mix text with musical braille.

This is exactly the use case scenario (mixing Music Braille Code within text that a screen reader is likely to be presenting) that I came to this page to see if there was a solution for. Will be following and hope it can be solved.

pkra commented 2 years ago

This is exactly the use case scenario (mixing Music Braille Code within text that a screen reader is likely to be presenting) that I came to this page to see if there was a solution for. Will be following and hope it can be solved.

Just FYI: you should be able to combine aria-brailleLabel with aria-describedBy as a workaround, i.e., use brailleLabel in the target referenced via describedBy.