ant-design: Ant Design currently generates inaccessible forms. Blind people cannot use forms made by Ant Design.

  • I have searched the issues of this repository and believe that this is not a duplicate.

What problem does this feature solve?

A substantial percentage of the internet relies on screen readers (e.g. all blind people, many old people, etc.) - and having forms be easily read by them is critical. People who use screen readers currently cannot use forms generated by Ant Design.

Considering how widely adopted And Design is, many people are trying to access Ant Design forms with screen readers daily - and currently, they can’t read them. AntD has been advertised as an accessible platform, and accordingly - I hope that it is updated to make forms accessible.

Here is a post with a lot more info (including screenshots of current problems): https://github.com/ant-design/ant-design/issues/16268

What does the proposed API look like?

The proposed API would be the same as it is currently. However, the output would be very slightly different. All that’s needed is 2 extra attributes per <Form.Item/> - e.g. for in label, and id in input. That’s really all that’s needed for all the Ant Design forms to become accessible!!

As an alternative, perhaps the top level <Form /> can have an extra prop available called accessible that is a boolean, and when set to true, forms are made accessible. (personally, however, i think they should be accessible by default always).


  • Select
  • Checkboxes
  • Radio Buttons
  • Datepicker
  • Modal
  • Menu

description ref: comment

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Reactions: 67
  • Comments: 22 (8 by maintainers)

Most upvoted comments

@kaushalyap PR is welcome~

❤️ love the commitment to improving accessibility. Antd has already merged 3+ accessibility improvements I’ve suggested, over just a few weeks.

Thank you for continuing to be so awesome

It seems that when using const { getFieldDecorator } = form; and

 <Form.Item label="Title">
    {getFieldDecorator('title', {
      rules: [{ required: true, message: 'Please input the title of collection!' }],
    })(
      <Input />
    )}
 </Form.Item>

within the <Form/> - proper accessibility kicks in (unless you wrap an <Input /> with an <Autocomplete />). However, one shouldn’t be forced to use the state management in order to have good accessible forms.

Here is a react framework that primarily focuses on accessibility: https://reakit.io/ / https://github.com/reakit/reakit it may be a good reference as antd tries to improve it’s accessibility.

@zombieJ what do you mean by this?

help to add list in the issue above

An update, in using VoiceOver with Opera (which runs the same in Chrome & Safari):

The input with text is good, and easy to understand. Unfortunately, it (and buttons) are the only part of AntD forms that are truly accessible to understand.

I tested my form set up in a website that uses antd Menu, with the form embedded in an antd Modal, and discovered accessibility issues with both of those components as well. Here are some of the problems that I’ve encountered so far:

Form (and contained inputs)

  1. Select - the screen reader only reads the first item from the options. It gives zero sense that this is a select, and what type of selection it is.

  2. Checkboxes & Radio Buttons - these share the same problem. An individual radio button or checkbox is accessible. However, there is no connection to the label. The screenreader can’t understand what the relationship is between all the different checkboxes/radio buttons.

    For example, if there was a “Do you like cake?” with 2 radio options of “yes” and “no”, the screen reader would be able to tell you that you had a yes and no, and which one was selected - but you wouldn’t know what the yes & no were about.

  3. Datepicker - it is clear that this is something to pick a date, and the screenreader tells you that you can enter text. However, it is impossible to interact with the actual date picker (only entering text is easy). I can imagine that picking from a calendar with a screenreader is really really hard to design, so I don’t think this can be a large concern.

Modal

  1. For some reason, antd is adding a sentinalStart and sentinalEnd before/after all the other elements of the Modal. This is read by the screenreader, and is the first thing that is read to you - and makes the user experience very very confusing. It’s hidden visibly by html, but the text is still accessible. Here’s an example:

    <div tabindex="0" style="width: 0px; height: 0px; overflow: hidden;">sentinelStart</div>
    

    It’s the first thing within the ant-modal div.

  2. It is impossible to navigate a form within a modal using the screenreader. The screenreader can tell me what’s on the screen, but it can’t actually navigate within the layout. There’s something weird about how it’s structured. That being said - it is possible to navigate using the tab button, and that’s very important. (But the tab has 2 extra stops - the sentinalStart and sentinalEnd)

  3. A modal with a form should have an autofocus to the first field in the form, and when it closes, should autofocus back to the button/link that opened the modal. Is this straightforward to do with Ant design’s current HTML?

Menu

  1. In using a screenreader to test this, I discovered that Menu.Item is being read as a form element by the Screen Reader, when it really shouldn’t be. It makes it much harder to navigate a website, as the screen reader tells you there are form elements when there aren’t. It lists each of them as “Dashboard menu item”, “account menu item”, etc. so it is clear that it’s a menu item, but it still makes the user experience with a screen reader very difficult, and one that never happens on other websites.

I hope this is all useful, and I hope that the Ant Design team addresses this. 😃 You’ve made such a wonderful framework, and it would be great to put in little changes to allow several million more people to be able to use websites created with Ant Design! 😃

Just to add to this conversation about inaccessible forms, we also don’t have roles set on the Radio.Group component. Without this, screenreaders cannot properly recognise the radio group. The role on Radio.Group should be ‘radiogroup’.

I was about to report this as an issue and then I came across this

I’ve also noticed that the expandable rows in the Table component aren’t accessible. There is no way to expand them via the keyboard

Here’s an example: https://codesandbox.io/embed/trusting-kowalevski-7zmm4