Semantic-ui-react: Keyboard accessibility and other WCAG requirements not supported

Created on 12 Aug 2019  路  4Comments  路  Source: Semantic-Org/Semantic-UI-React

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
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.

needs engineering

Most helpful comment

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/

All 4 comments

馃憢 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.

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/

@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.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dilizarov picture dilizarov  路  3Comments

jayphelps picture jayphelps  路  3Comments

saikrishnadeep picture saikrishnadeep  路  3Comments

mattmacpherson picture mattmacpherson  路  3Comments

eXtreme picture eXtreme  路  3Comments