Start

Slide instructions

SPACEBAR to move forward through slides.

SHIFT & SPACEBAR to move backwards through slides.

LEFT ARROW & RIGHT ARROW to move through sections.

ESC to see overview and ESC again to exit.

F to enter presentation mode and ESC to exit.

What makes an accessible date picker? Is it even possible?

Inclusive Design 24

Prepare for disappointment!

I'm not going to provide a definitive date picker solution at the end of this presentation.

So what’s the point?

The aim is to provide you with tools and strategies to make your own decisions.

What we will cover:
  • When should you use a date picker?
  • A decision tree for building new components.
  • How to conduct ‘accessibility unit testing’ to determine if your date picker is accessible.

Why date pickers?

Date pickers are one of the most complex components to build accessibly.

Some URLs:

Is a date picker the best solution?

Let’s assume your team wants to use a date picker as part of your website or design system.

Where would you start? Maybe with two fundamental questions:

Is a date picker the best solution:
  • For the problem you are trying to solve?
  • For your key audiences?

Date pickers can be suitable for some situations, such as choosing dates for a holiday.

Date pickers can be less than ideal in other situations, such as a ‘Date of birth’ component.

So, we must be careful about jumping into solution mode too quickly.

We should also be aware that some types of users find date pickers challenging, while others find them easy.

I have observed people struggling with date pickers for many years, especially when the components were often highly inaccessible.

Which is why I always thought of date pickers as the work of Satan!

However, a recent experience shifted my perspective.

Andrew
  • A person who is blind
  • Uses a range of different screen readers
  • Wants the ability to type the date quickly
  • Hates date pickers
Dan
  • A person who has mobility issues
  • Users face gestures and virtual keyboard
  • Wants the ability to click rather than type
  • Loves date pickers

What next?

If you decide that a date picker is the best option, the next challenge is determining the best way to build it.

I use a component decision tree, which can be used to step through some possible options for building new components.

Three options:

How could we test each of these options to determine if they are accessible?

Start with people

You can start by looking at different groups of people and their needs.

This means you can focus on one user type and explore how they may need to interact with the component.

These groups of people could include:

  1. People with some kind of cognitive impairment or neurodivergence.
  2. People with some sort of colour vision deficiency.
  3. People with reduced vision.
  4. People with limited mobility.
  5. People with limited or no sight.

1. People with some kind of cognitive impairment or neurodivergence

We need to make sure:
  • The purpose of the component is clear.
  • All content is written in plain language.
  • Any additional instructions and error messages are clear.

2. People with some sort of colour vision deficiency

We need to make sure:
  • All aspects of the component have sufficient colour contrast.

3. People with reduced vision

We need to make sure:
  • The text and layout are understandable when scaled.
  • The component is operable when viewed via magnification tools.
  • The component is operable when viewed in low contrast.

4. People with limited mobility

We need to make sure:
  • The component is accessible for keyboard-only users.
  • The component is accessible for voice control users.
  • Focus states are visible.
  • Focus order is intuitive.

5. People with limited or no sight

We need to make sure:
  • The component and any interactive elements have accessible names.
  • All possible states and values are made available to users.
  • Any dynamic content is announced at the appropriate time.

Which order?

We should start with ‘People with some sort of cognitive impairment or neurodivergence’.

If these people have issues with the component, there are either fundamental UX or content-related issues.

We should then look at design-related concepts for:

  • People with some sort of colour vision deficiency
  • People with reduced vision

And finally, we should look at more technical concepts for:

  • People with limited mobility
  • People with limited or no sight

We can use these people to create a cohesive set of accessibility unit tests.

What is accessibility unit testing?

‘accessibility unit testing’ is a process where the smallest parts of a component are individually and independently evaluated.

Accessibility unit tests are often based on two concepts:

1. How all aspects of the component are presented to users - either on screen or via assistive technologies.

2. How users should be able to interact with the component to complete all relevant tasks.

Each possible task needs to be defined as a test.

And every test must be written as a statement where the only outcome is either a pass or a fail.

Unit testing some date pickers

We will now look at an accessibility unit testing chart, showing a sub-set of some possible tests.

Keep in mind:
  • You would need a chart for each date picker you test.
  • I'm only going to focus on desktop here.

Let’s explore the demo chart.

A review of the three examples

The following high-level review is not meant to shame any of these solutions. This is just for educational purposes.

Native solution

Implementation
  • Very easy to implement, no need for JavaScript.
UX Issues
  • OSX Safari presents the current date as a hint, which could be confusing.
  • OSX Safari presents no date picker icon.
Keyboard issues
  • OSX Chrome does not always allow focus to the icon.
Screen reader issues
  • Focus is not sent back to the input, so the selected date is not announced.
  • OSX Safari does not announce date options - each date field is announced as ‘Group’.

ARIA APG Date picker

Implementation
  • A little ugly and may need re-styling.
Screen reader issues
  • Focus is not sent back to the input, so the selected date is not announced.

U.S. Web Design System Date Picker

Screen reader issues
  • A lot of additional information is announced while moving through each date.

Overall

As you can see, all three options have strengths and weaknesses. There is no perfect solution.

Ultimately, you should conduct your own tests to determine the solution that suits your needs.

While accessibility unit testing is a very useful process, we should still try to test with real people with lived experience.

These people may provide you valuable insights, and help you design and build more inclusive products.

Questions or discussion?