web-components
web-components copied to clipboard
vaadin
grid / grid-pro / CRUD: content visually cut off at small viewport sizes
WCAG Level
Level AA
Priority
High
Pages/screens/components affected
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, and without any loss of content or functionality.
At small viewport sizes, depending on the number of columns, the grid component causes horizontal scrolling. This is allowed by WCAG 2.1 (as it recognises that complex tables cannot simply be squeezed/forced into a small viewport size), as long as the actual data contained inside each table/grid cell itself fits into the smaller viewport dimensions without requiring bi-directional scrolling. In this case, though, the grid simply visually elides/cuts off content at smaller sizes.
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.
In this case, users will be not be able to read the data, or see the full column headers/filter labels, of the grid, making it potentially unusable for them.
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.
In this case, instead of forcing an ellipsis, consider forcing a line break for long content that is wider than the available space, and allow content to vertically stack inside the cell, rather than cutting it off.
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 particular case, despite the author having specified a popup width, consider effectively overriding their choice if the end result would mean a popup that is wider than the 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:
- Open the page in a browser.
- Set the size of the browser to a "standard" desktop size (approximately 1280px wide).
- Zoom content to at least 400%.
- Check that the content in grid cells (including column header cells) is not elided/cut off.
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
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
To some extent this is possible to work around by providing different sets of columns for different viewport sizes and/or using the wrap-cell-content theme variant for wrapping cell content instead of truncating with ellipsis. We should improve the discoverability of these workarounds by explaining them in the documentation. A fancier solution that has been used with Grid is to use the row-details feature to provide additional details on the item e.g. on click. We could provide a convenience mechanism for doing this automatically (opt-in).
A solution similar to FormLayout's responsiveSteps could also be useful.
Related: responsive column configuration https://github.com/vaadin/web-components/issues/2049
Voicing the customer feedback that it would be great to see this issue solved on the component level in near future. A potential solution could be to use a tooltip component that allows accessing the cut off value. Such tooltip component should also be triggered using keyboard. In their use case wrapping the cell content would not be ideal.
Re-reading this issue now I realise that it describes two separate concerns:
- Forces the user to scroll both vertically and horizontally to see all content. This is of course quite inevitable with tabular content, unless it somehow collapses into a different type of layout altogether on small viewports, which can be implemented separately, but would require a rather complex feature addition for the Grid to handle automagically.
- Truncation of cell content. Setting fixed widths on the columns prevents this of course, but the Grid should also be able to handle auto-width in a way that is unaffected by the grid/viewport size. Of course auto-width will always be limited by the fact that it can only take the first page of items into account, but given a minimum width based on that, the columns should not shrink below it.
I presume @juuso-vaadin is referring to issue 2 above?
@rolfsmeds Yes, truncation of cell content. Auto-width or wrapping cell content does help, but not an ideal solution in every case.
For example there might be a column showing a long address as value. If the address is only relevant for small number of rows, having a super wide address column is not ideal. Better would be to have a narrow column that shows if a value is present and disclose the full value somehow. Questionable if this should be covered by grid component or not, but the message from the field is that other table components have their ways of handling such case.
That is pretty much exactly what the row details feature is for, and the upcoming tooltip support will provide an alternative solution.
(As an example, you could have a custom renderer in the address column that contains an indicator/button that, when clicked, opens a detail row containing the full address.)
Haven't looked at solutions in other datagrids, but if there are better approaches out there I'm all ears :)