Feat/add textarea label wcag 2.1

[TheeMattOliver]

Closes #103

Problem

Projects that list react-simple-code-editor as a dependent violate WCAG Success Criterion 4.1.2: Name, Role, Value.

For more context, please see issue #103 here.

Solution

I'd like to propose that we improve the accessibility of react-simple-code-editor with this PR, a small change that adds a textareaTitle prop to the rendered textarea. This strategy is proposed as part of the W3C official Techniques for WCAG 2.2. If others have better ideas please let me know!

Under this change, the textarea no longer violates WCAG Success Criterion 4.1.2, and authors may then judge whether their specific context requires a visual label during a manual accessibility review.

Open questions

It's unclear to me how consumers can provide this prop. A default prop should suffice. Please let me know what ideas you have.

[oliviertassinari]

I have noticed the same issue on https://mui.com/material-ui/react-alert/ since mui/material-ui#34870

https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh

Maybe it would be simpler if we allow developers to apply anything they wish on the <textarea>.

[satya164]

Maybe it would be simpler if we allow developers to apply anything they wish on the <textarea>

One concern would be that it might be easy to break the editor if there are some props that alter styling of the text area or conflict with the props we need to pass internally.

[oliviertassinari]

it might be easy to break the editor if there are some props that alter styling of the text area or conflict with the props we need to pass internally.

@satya164 Definitely, I think that it's about what dimension we want to value most. I would lean slightly toward the option that gives extra flexibility but happy either way.

(I'm biased by 1. not wanting to make a PR each time I need to extend something 2. I can read the codebase to figure out if it's a safe extension 3. I gave up on MUI trying to limit access to the elements.)

[satya164]

not wanting to make a PR each time I need to extend something

I think so far there haven't been many cases like this..

If we want to remove the current text area props and accept some object to pass to the text area instead, it'll be a breaking change so imo we should only do it if we really need to, e.g. we receive more of such PRs/requests.

[oliviertassinari]

I think so far there haven't been many cases like this.

@satya164 There are multiple ways to fix the a11y issue reported here https://www.w3.org/WAI/tutorials/forms/labels/. 4 of them:

• title attribute, the solution proposed by @TheeMattOliver
• id attribute + label for. Already possible
• aria-label attribute. Not possible
• aria-labelledby attribute. Not possible

Personally, I would like to use aria-label to not have to render another DOM node and for the label to be screenreader only. I wouldn't want to use title as I don't want the tooltip.

[JustinTime42]

I see this is a pretty old issue and I'm not sure what the desired direction is. I needed a fix for my own use, though, so I forked the repo and resolved the a11y errors using an aria-label. Just submitted #118 in case that's helpful.