Search code examples
datepickeraccessibility

Possible accessibility issues when restricting manual date entry in a date picker

I am wondering if there are any accessibility issues that arise if limiting a date entry to the picker only.

I would like to limit the user to setting a date using the date picker only, and prevent the user from typing in a date manually using the keyboard (such as in this question).

If I disable keyboard input and restrict the user to the picker only:

enter image description here

Does this cause any accessibility issues?

Solution

  • This obviously creates an accessibility issue, or a least a major inconvenience for several kind of users:

    • Screen reader users: even if the date picker could be made accessible, many screen reader users aren't very comfortable with navigating in such component. Typing in the desired date directly is much simpler and faster, both for beginners and for advanced users.
    • Keyboard-only users: for the same reason as above, making them obliged to navigate in the date picker creates a lot of inconvenience
    • Voice control: if you can't tell what to enter in the field directly, then it becomes painful to use it as well. There are users who count on it, who can't use a keyboard, a mouse nor a touch screen.
    • Special devices: some devices behave quite a lot like keyboard, so by preventing keyboard input, you might prevent using them as well. Examples include braille displays, barcode/QR code readers, eyetrackers, etc. As above, it isn't only about convenience, they can be essential for the user to work autonomously.

    Giving the user several choices in how to input data is an important key in accessibility. The more possibilities you give, better are the chances for the user to find a way which works well for him/her. This also makes the interface more friendly for all users, whether or not they have an impairement. Anyone can choose the input mode he/she prefers.

    Speaking about WCAG, proper keyboard support is required everywhere at level A (except in some particular obscure cases). Providing several input possibilities (keyboard + other ones) is strongly encourraged. See sections 2.1 and 2.5 of WCAG 2.2. So explicitly preventing keyboard operation have great chances to make you non-compliant (unless you area really sinic)

    In fact, you should ask yourself why you want to prevent keyboard input. There is certainly no good reason to do that.

    If you are afraid of the user entering dates in the wrong format, or well formatted dates but invalid from the business point of view (such as reserving a day already full or in the past), you should instead:

    1. Clearly tells the user what is required/expected, both the format with indications like "dd/mm/yyyy" or by giving an example, as well as when your business is available (such as "Monday to Friday 08:00-18:00".
    2. Notify the user and help him/her fixing errors as soon as you detect them, by intelligently combining visual clues, form validation API, aria-invalid attribute, aria-live messages. You will find a lot of literature covering these topics.
    3. Always check the input server-side

    Finally, if you still want to prevent keyboard input despite my explanations above, note that it might not be as simple as you think. By preventing all keyboard events, you prevent from using the date picker with the keyboard as well, so you must be very cautious. Some assistive tools and some devices set the input value directly and completely bypass normal keyboard events. You should also think that the user can paste a value by choosing the "Paste" item in the context menu instead of Ctrl+V. And, above all, remember that it's always possible to completely bypass the whole front-end and submit anything to the server directly.