- From: Adrian Roselli via GitHub <sysbot+gh@w3.org>
- Date: Sun, 25 Feb 2024 22:37:05 +0000
- To: public-css-archive@w3.org
Not in the WG, but I encourage you not to apply this to tables. Table navigation commands in screen readers are robust. When tables are used as intended (tabular data whose relationship is expressed by the structure), the user relies on existing navigation methods to explore the structure to understand the data. Not only could that make tables suddenly at the whim of arbitrary visual design, but it risks breaking all the understood relationships that come from row and column headers. As for writing modes, this is easy to confirm as not a concern (unless there is a specific case not cited here that is a known problem). Tables already reflow based on the writing mode. As it is, I am worried the impact this will have on ARIA grids, which notoriously do _not_ use HTML tables but do use CSS grid for layout. The relationships conveyed to users are the same, but authors are responsible for supporting arrow key navigation within the ARIA grid via scripting (except for ARIA grid mis-uses, where authors fail to do it at all). Anyway, I am happy to answer questions about screen reader table navigation, tables and internationalization, or ARIA grids. I have experience in all as well as the required assistive technology to perform tests. -- GitHub Notification of comment by aardrian Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9922#issuecomment-1963085593 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 25 February 2024 22:37:06 UTC