W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

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

From: Nat Tarnoff via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Oct 2020 13:09:09 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-718741300-1603976948-sysbot+gh@w3.org>
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. Like previously said, we have non-visual screen reader users, visual screen reader users, and ZoomText (and similar magnifiers) users. But we also have neuro-divergent users who may use no AT. We have low-vision users whose "AT" is just reducing the screen or viewport's resolution or increasing font size. And there are people who are keyboard only who actually may have no disability or a physical one which doesn't require AT. There seems to be a glossing over some of these types when trying to address the concern I raised.

>You really shouldn't use (default) masonry layout in the first place if the item placement matters to the semantic meaning of the content. 

Completely agree, but we have to know authors will use it inappropriately unless something is enacted to prevent or work around these issues. Leaving it to authors will bring interfaces that have a11y problems.

>I don't think adding more HTML/CSS features and relying on authors to use those features is a tenable solution. 

I can agree with this. I'm looking for solutions that don't really leave the potential problems in the hands of authors anyway. I want them to be able to use these grid features without accidentally making an inaccessible experience just because they misunderstood which property to use when. This happens enough with the HTML we have.

>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 space, and therefore navigation should itself be available in 2D.

I took some more time reviewing that today as it didn't really sink in yesterday. I do think this can answer the problem, however we are relying on the following:
- People accepting a new navigation paradigm. This will take time to be natural
- If the navigation shortcuts are more than just a single key press, we may be introducing a new problem for people with physical disabilities (this is really a comment for that spec)

I think CSS-Grid in general (and especially for masonry) needs to have a dependency on CSS-Nav where when grid is implemented, the parent grid is the spatial navigation container and default spatial navigation properties are implemented on the objects inside. This could prevent all my concerns, but I realize CSS-Grid is in the wild now and adding a dependency to it could have significant unexpected impacts to those sites using grid. WCAG could add a best practice around this, but now we are depending on authors to do the work to know the the two specs and make sure they follow the guidelines for accessibility. I'm aiming for as close to preventing inaccessible experiences by default as possible.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 October 2020 13:09:10 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC