Ant Design currently generates inaccessible forms. Blind people cannot use forms made by Ant Design.

2019-04-24 03:16:27
  • 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): #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

2019-04-24 05:23:17

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

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.

2019-04-24 06:08:23
2019-04-24 06:44:37

Yes, like that. I think you guys should make it clear that this is possible in the documentation for Form.Item. it would make a big difference for people who care about this. :)

However, there's still some issues:

I played around with this some more. Here's the same thing with 5 different types of inputs: With the DatePicker, the id that the label points to is on the incorrect element (Tota11y still complains about not having a label available for that input). With the CheckboxGroup, antd complains about the id prop not existing.

I haven't done enough tests with this (I'll need to actually run the outputted HTML from this code using a Screen Reader to really understand how well it works for blind people), but my immediate sense is that the basic input is good - but other inputs for forms could still be problematic.

I'd be happy to do some tests tomorrow & report back! :) Thanks for the first bit of info on this @zombieJ

2019-04-24 06:58:50

Thanks for your help. I will add it in document. Maybe you can help to add list in the issue above : )

2019-04-24 19:30:18

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


  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?


  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! :)

2019-04-25 07:05:32

Thanks for your help! We will continually working on this. Let me update it as check list.

2019-04-26 19:21:25

You're welcome @zombieJ - i'm happy to help! I'll update here with more if I find more. :)

2019-05-09 18:03:25

❤️ 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

2019-05-09 21:04:02

Me too! :) I really love using Antd, and unfortunately my team would have to switch to a different framework if accessibility wasn't a priority. I'm hopeful that the suggestions in this thread get implemented in the next month or so, otherwise we're gonna have to seriously start thinking about alternative frameworks. :(

2019-05-10 03:54:11

@thisissami , since some components do not works well with accessibility. We should adjust some dom structure to enhance it. Considering not breaks current behavior, it may not fast for it but it's in progress.

当前位于第1页,总计16 条回复


Input with more than 2000 characters of form Regexp validation will get stuck

Mailboxes with more than 2000 characters of form regular validation will get stuck
讨论数 2
创建时间:2019-04-24 03:14:19

Forms in Ant Design are *not* accessible.

Hello. Ant Design has been advertised as an accessible library. (e.g.
讨论数 2
创建时间:2019-04-24 03:07:56


I have searched the issues of this repository and believe that this is not a duplicate. Reproduction link
讨论数 2
创建时间:2019-04-24 01:51:53

DatePicker bug

I have searched the issues of this repository and believe that this is not a duplicate. Reproduction link
讨论数 3
创建时间:2019-04-24 01:48:59

Specifying a Typography-Title type does not affect color

I have searched the issues of this repository and believe that this is not a duplicate. Reproduction link Steps to repro
讨论数 2
创建时间:2019-04-23 20:42:43

Tree checkbox animation not correct

I have searched the issues of this repository and believe that this is not a duplicate. Reproduction link
讨论数 2
创建时间:2019-04-23 14:27:07

Feature request: <Paragraph /> localization

I have searched the issues of this repository and believe that this is not a duplicate. What problem does this feature s
讨论数 2
创建时间:2019-04-23 09:53:06

Feature request: Paragraph localization

You define copyable paragraph like: <Paragraph copyable>TEXT</Paragraph> You will get copy icon that allows the child TE
讨论数 2
创建时间:2019-04-23 09:50:27