Keyboard accessibility and other WCAG requirements not supported

[joakimbording]

Bug Report

I have done a quick and general review of Semantic UI when it comes to accessibility, and it is lacking in too many places. Please consider living up to the name by actually using semantical HTML and making sure each component is accessible by keyboard users and screenreader users. Below is a collected list of findings to get you started. Tested on Semantic UI React 0.87.3.

Component	Findings	Severity
Form.Field	Labels is not binded to the input element by default. This is optional. This would make form fields unusable by screenreader, and voice control users.	High
Accordion	Not accessible by keyboard since they use div elements with onClick.	High
Accordion	No semantical aria tags that communicate expanded or not.	High
Radio Buttons	Not keyboard accessible in Safari	High
Checkbox	Not keyboard accessible in Safari	High
Checkbox	Label not bound to input field by default. Optional.	High
Label	Does not include any aria tags to bind it to the component it is set to describe. Will let this information be inaccessible for screenreader users.	High
Tab	Not accessible by keyboard.	High
Menu	Not accessible by keyboard since they use a elements with onClick.	High
Comment	Reply is not accessible by keyboard since they use a elements with onClick.	High
Modal	Does not move keyboad focus into the modal. Makes the modal inaccessible by keyboard users and especially screenreader users.	High
Tab	No semantical aria tags that communicates the tab concept or which tabs that are expanded or not.	High
Popup	Not accessible by keyboard, only on hover.	High
Images	Alt text is not added by default. This is optional. This would lead to problems for screenreader users since the filename would be read aloud for images where the alt text is not specified.	Moderat
List	Does not use the semantic HTML tag ul or ol by default. This is optional. Will lead to problems for screenreader users that will not understand the context.	Moderat
Menu	Does not contain ul wrappers and nav wrappers that would communicate length and purpose for screenreader users.	Moderat
Message	Header in the element is a div and not a header. Structure not accessible for screenreader users.	Moderat
Card	Header in the element is a div and not a header. Structure not accessible for screenreader users.	Moderat
Comment	All base elements are divs. No semantical structure. Should ideally contain ul, articles and headers.	Moderat
Item	All base elements are divs. No semantical structure. Should ideally contain ul, articles and headers.	Moderat
Modal	No semantical aria tags that communicates the modal concept.	Moderat

I recommend this read for how to implement keyboard accessibility and aria tags for the more advanced components like modals and tabs:
https://heydonworks.com/practical_aria_examples/

Expected Result

Base components should be accessible by users that use the keyboard to navigate, and not use a mouse or touch. It should be accessible for users that use voice control. It should be accessible for users that use screen readers to read everything aloud. Good old HTML is accessible, it's just us developers that adds unnecessary walls when building because we do not think about the variety of how the web is used. Bad for users, bad for business.

Actual Result

Most of the base components had some issues when it comes to accessibility. Either it wasn't accessible, or the accessible options where optional and dependent on the end developer to remember adding while developing. Accessibility should be the default behaviour.

Version

0.87.3

Sorry for the large issue, but hope mye quick walktrough can be of some use. I do not have time to contribute by code unfortunately, but please reach out if you have questions.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you've completed all the fields in the issue template so we can best help.

We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[layershifter]

This issue is known. Some improvements will be shipped soon, some work will be for v1. No ETAs, the best way to improve - contribute 🙏

Accessibility was not considered in SUIR design, nowadays it looks like a mistake. We are open for improvements 👍

If you need something accessible and SUIR-like, take a look on Stardust UI: https://stardust-ui.github.io/react/

[brianespinosa]

@layershifter I know there was a recently merged PR adding some of these... but I do not think it got all of them. Worth noting here for anyone following along.

[layershifter]

Let's keep this issue to track the work that should be done.

[victoriaskeggs]

@joakimbording Could you please include in your bug report that checkboxes and radio buttons are not keyboard accessible in Safari?

[forivall]

Is there a status of these issues as-of the current version (v2.0.3)?

[brianespinosa]

Hi @forivall!

The way our status tracking works here on this open source project is that any work in terms of code, pull requests, conversations, etc will be linked here chronologically. We've historically been pretty good about it.

That being said, the status of this is that there has still been no time invested in these things. None of the core maintainers have had free time to invest here in a while, and nobody from the community has thrown any time at this either.

If you need something accessible and still want to use Semantic UI Styles, you could potentially look at using Reakit and add your own class names by hand. Not ideal from a development standpoint, but would give you accessibility and styling if you absolutely needed to match Semantic UI.

[brennanyoung]

The viability of semantic-ui-react will be heavily constrained for any public sector projects in North America, Europe and certain other jurisdictions that have legal mandates about WCAG compliance, for as long as built-in WCAG violations remain unfixed. Legal mandates about private sector WCAG compliance are also coming, and accessibility lawsuits are increasingly common.

As an accessibility specialist targeting mostly public sector customers, I can only continue to recommend against this library to the devs in my team until there is some movement on this. The legal liability is too great.

[lhenze]

Hi all, agreed, for new work. For the platforms already invested in using this library...
Might the maintainers consider creating a project for accessibility? https://github.com/orgs/Semantic-Org/projects

It could be helpful for fully describing each issue (along with citations for success criteria), prioritizing, tracking fixes, and discussing any short-term workarounds.

[brianespinosa]

@brennanyoung @lhenze the same issue still stands... maintainers who invested time creating this have not had the resources to move some of these other things forward. This is still open source software. There is nothing stopping you from throwing your hat into the ring to move something forward on this. Especially if one of you is an accessibility specialist.

[bauerbach]

Any workarounds? I have already spent over two years working on my project that uses this, and only NOW do I discover it's not accessible! I don't want to have to scrap my project or start all over again with a new UI library!

[forivall]

@bauerbach There's always the option to roll up your sleeves, learn a11y practices and implement it! Personally, I'd look at using ariakit, as it provides low level unstyled components that you can build on top of, ideally, sprinkling it into the existing semantic-ui-react components where needed.

[bauerbach]

@forivall OK! I considered rewriting the UI in another framework, but then I decided it was too much work. So I restored from a backup and decided I needed to "get a bit creative".