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:

    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.