react-aria-live
react-aria-live copied to clipboard
AlmeroSteyn
Support for message element?
Hi, thanks for this project. I've struggled with aria-live regions in React before so I'm glad this exists. However, I can't use this library because PropTypes.string is the only allowable type to the message prop.
I need to have an element in the aria-live region. The main reason for this is because I need to wrap the text in a span that indicates the language of the text. E.g.:
<span lang="en">
Hello, world!
</span>
This is because I use a translations service for all of the display strings in my application, and sometimes, some of the strings are not translated to the user's language. A screenreader needs to know the language of the string to read it out correctly.
I don't know about the internals of this library, but do you think it would be possible to make a change to support passing elements to the message prop (PropTypes.node is a great option for this)?
Hi @thallada, thank you for your interest.
I am not yet convinced that this is something that should be solved by the ARIA live region.
Please help me understand more about what you are trying to achieve here. Why would a language tag be necessary here? If the <html> tag has the right language set I would only expect it to be set on other elements when a different language is used to the main one.
And these strings are being passed into the live region using user code, so this kinda looks like the moment to translate the message. Why can you not do it where the message originates?
I am bit loathe to inject more than strings into the live regions as it may lead to unexpected things if entire HTML contructs are allowed.
Let me know what you think.
The case I'm thinking of is, for example:
- the user's language preference is
es - so, the root element gets the lang attribute:
<html lang="es"> - most of the display strings in the application are translated to
es, except one - the display strings were originally written in
en, so that one untranslated string defaults toen - in order for the screenreader to read that string out in English instead of Spanish, it needs to be wrapped in an element that has the attribute
lang="en"
The way I've solved that case in my application is to just simply wrap every display string in a <span> that indicates the language.
I can't wrap <LiveMessage> in a span that indicates the language because the message actually gets rendered in a different part of the DOM.
I agree that it would be a lot simpler if LiveMessage only accepted strings, but I haven't found a better solution to this problem. It seems like others either translate their whole app or just ignore the few cases where the screenreader will read strings out wrong. WCAG 2.0 SC 3.1.2 covers this.
I just realized there might be another option. If <LiveMessage> accepted a lang prop that would be rendered as an attribute on the MessageBlock div, that might also work.
That still wouldn't allow you to announce a message that contained more than one language, but that's a pretty unlikely edge case and one that my application doesn't need.
Have not forgotten about this. Been a pretty busy time. Will get back to this soon.
Once again circling back. Hope to get time for this soon. Feel free to submit a PR in the meantime.
