date-time-picker: requires horizontal scrolling at small viewport sizes

[TetraLogicalHelpdesk]

WCAG Level

Level AA

Priority

Medium

Pages/screens/components affected

• Date Time Picker

Description

Browsers have functionality that lets people zoom in on the page, enlarging all of the content in equal proportion. If zoom hasn't been taken into consideration when designing the page, it can result in 2 Dimensional scrolling (both horizontal and vertical) being needed to view the content.

The related WCAG 2.1 success criterion states that it should be possible to zoom into a website presented in "standard" desktop size (generally accepted to be 1280 x 1024 pixels) to 400% without 2D scrolling occurring.

At a viewport width of 320 CSS pixels, the date-time-picker leads to horizontal scrolling.

User impact

When zooming causes horizontal and vertical scrolling it makes it hard to read the content because scrolling up/down and left/right disrupts the reading flow. If someone has mobility difficulties in addition to having low vision they may lack the dexterity needed to scroll in different directions, making the content completely inaccessible.

Required solution

Make sure that content adapts/reflows to fit a 320 CSS px width viewport, so that scrolling in two directions is not necessary. Also make sure content is not cut off and unreachable at this viewport width.

This solution must be applied to all instances of the issue identified within the test sample, then applied to all other instances of the same issue identified throughout the rest of the components, their variants, and the documentation website.

Implementation guidance

In this case, we would recommend allowing the two separate sub-components (the date picker and the time picker) to stack vertically depending on the available viewport width.

Test procedure(s)

Use these steps to confirm that the solution has been correctly applied to issues identified within the test sample, and to test the rest of the components, their variants, and the documentation website for instances of the same issue:

1. Open the page in a browser.
2. Set the size of the browser to a "standard" desktop size (approximately 1280px wide).
3. Zoom content to at least 400%.
4. Check that the content reflows to a single column and that it can be viewed without both horizontal and vertical scrolling being necessary (with exceptions for certain specific elements like tables, graphs, maps)

Definition of done

Complete all of these tasks before closing this issue or indicating it is ready for retest:

• All issues identified within the test sample have been resolved.
• The rest of the components, their variants, and the documentation website have been tested for the same issue.
• All issues identified throughout the rest of the components/website have been resolved or filed as new issues.

Related standards

• WCAG 2.1 Success Criterion 1.4.10 Reflow (Level AA)

More information

• W3C: Technique F102: Failure of Success Criterion 1.4.10 due to content disappearing and not being available when content has reflowed
• Knowbility: Exploring WCAG 2.1: 1.4.10 Reflow

Test data

Test date: March 2021 Website: vaadin.com/components, vaadin.com/docs-beta

[rolfsmeds]

This seems to be more a problem with the DTP sample in the docs site than with the component itself. When correctly configured (e.g. max-width:100% to force it to scale down to fit the available horizontal area), it does scale down horizontally as far as needed, and is perfectly usable (without truncating values) down to about 275px, leaving 45px for margins around it.

That being said, it would be good to allow the two sub-fields to wrap. This could be optional (e.g. through a theme variant) to allow the component to be used in more confined spaces without truncation.

We might also consider adjusting the default widths of the sub-fields to something more approrpriate than the standard text field width, as neither needs that much space regardless of the date/time format used.