Good design means supporting different modes of interaction, because there are many reasons why someone might use a keyboard instead of a mouse, and if keyboard interaction is not fully supported the website is effectively unusable.
In the documentation examples, the Scrollable Dialog demo uses a container with overflow:auto to create a content scroller. These CSS based scrolling regions are currently not keyboard accessible - unless the region itself contains at least one focusable element (like a link, or button, or similar), keyboard users have no way to jump to/into the scroller and to then use cursor keys to scroll.
This issue is likely a problem limited to the example in the documentation, rather than being an intrinsic issue of the dialog component itself.
User impact
Someone with mobility problems will often use a keyboard instead of a mouse to navigate a web page. A screen reader user will also tend to use a keyboard if they cannot see the screen to use the mouse. Therefore if the website does not properly support keyboard interaction a large number of people are effectively prevented from using it.
In this case, keyboard users will be unable to scroll the container and see/read the content in full.
Required solution
Make sure that all interactive controls can be used with a keyboard.
While there is currently no "clean" approach to the problem of CSS-based scrollers, one solution would be to make the actual scrolling container explicitly keyboard-focusable by adding tabindex="0". Keyboard users will then be able to set focus to the container, after which they can use cursor keys to scroll.
Generally, when an element receives focus, it is recommended that the element should also have an explicit accessible name. In this case, as the scrollable element is a <main> container, this is not stringently necessary.
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.
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:
Check that all interactive elements can be navigated to using the tab key.
Check that all interactive elements can be activated using the enter or space keys.
Check that interactive elements can be interacted with using the arrow keys.
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.
WCAG Level
Level A
Priority
High
Pages/screens/components affected
Description
Good design means supporting different modes of interaction, because there are many reasons why someone might use a keyboard instead of a mouse, and if keyboard interaction is not fully supported the website is effectively unusable.
In the documentation examples, the Scrollable Dialog demo uses a container with
overflow:auto
to create a content scroller. These CSS based scrolling regions are currently not keyboard accessible - unless the region itself contains at least one focusable element (like a link, or button, or similar), keyboard users have no way to jump to/into the scroller and to then use cursor keys to scroll.This issue is likely a problem limited to the example in the documentation, rather than being an intrinsic issue of the dialog component itself.
User impact
Someone with mobility problems will often use a keyboard instead of a mouse to navigate a web page. A screen reader user will also tend to use a keyboard if they cannot see the screen to use the mouse. Therefore if the website does not properly support keyboard interaction a large number of people are effectively prevented from using it.
In this case, keyboard users will be unable to scroll the container and see/read the content in full.
Required solution
Make sure that all interactive controls can be used with a keyboard.
While there is currently no "clean" approach to the problem of CSS-based scrollers, one solution would be to make the actual scrolling container explicitly keyboard-focusable by adding
tabindex="0"
. Keyboard users will then be able to set focus to the container, after which they can use cursor keys to scroll.Generally, when an element receives focus, it is recommended that the element should also have an explicit accessible name. In this case, as the scrollable element is a
<main>
container, this is not stringently necessary.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.
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:
Definition of done
Complete all of these tasks before closing this issue or indicating it is ready for retest:
Related standards
More information
Test data
Test date: March 2021 Website: vaadin.com/components, vaadin.com/docs-beta