Re: [csswg-drafts] [css-grid] Masonry layout in CSS Grid 3 has potential to cause accessibility problems with reading order. (#5675)

Playing catch-up…

@nattarnoff

> But I am clear that while the masonry may initially be targeted for photos and other visual pages, we have to expect it to be used by others for different things.

I have seen it used for cards, making the entire box an interactive thing.

@rachelandrew

> With masonry we give people a really compelling layout method which is likely to cause this problem without the author actively doing it. It also might be tricky to test as at one breakpoint the reordering might not be too bad, and at another awful.

This is a huge point — the few cases I have seen involve devs testing at up to 3 arbitrary breakpoints (iPhone, iPad, their own desktop).

@MatsPalmgren 

> I slightly disagree with the premise of this issue. You really shouldn't use (default) masonry layout in the first place if the item placement matters to the semantic meaning of the content.

But people will. We have lots of evidence telling us devs will use whatever achieves their visual layout objective regardless of intent (`<i>` for icon fonts, `display: contents` as a CSS reset, …).

@frivoal

> As far as keyboard navigation is concerned, https://drafts.csswg.org/css-nav-1/ is an attempt to cope with the fact that there is no perfect answer to ordering of content laid out in a 2D

That draft does not address the challenge today and should not be considered a fix. If it happens, that could be ace since it could address years of issues with floats, absolute position, `order`, auto-placement, tabled layouts… Stuff that pre-dates this by at least a decade.

@nattarnoff 

> I want to remind folks that there are people who are disabled yet use no AT, so we need to consider that when writing specifications.

Big +1.

I also agree that throwing more features at this will not solve it.

Here's what we can posit based on experience:

* developers will implement it without completely understanding the specification;
* developers will not test with AT nor users;
* developers will test with limited breakpoints;

Perhaps a place to address this is their tooling.

I know many developers rely on the grid (or `shape-outside`) features in browser developer tools to help them build layouts.

What do you think about browser developer tools warning devs when their layouts break some basic flow patterns? The simplest approach (IMO) is to draw arrows from box to box, and (for LTR languages) use that visualization to highlight problems when the arrow goes both upward and to the left.

I have images demonstrating these arrows where I first proposed the reading / source order tool:
https://adrianroselli.com/2017/11/feature-request-for-firefox-grid-inspector-source-order.html#Update01

Chromium now has a reading order viewer built in, but it does not use arrows to make breaks in the flow more obvious.

This feature would need to built by the browser as it builds support for masonry to be most effective.

-- 
GitHub Notification of comment by aardrian
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5675#issuecomment-720621777 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 2 November 2020 17:40:59 UTC