Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-display-4] Should the reading-order-items property apply to tables in addition to flex and grid layouts? #9922

Open
rachelandrew opened this issue Feb 8, 2024 · 4 comments
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. css-display-4

Comments

@rachelandrew
Copy link
Contributor

We resolved that the new reading order spec should only apply to flex and grid layouts. In the comments on the PR @bradkemper proposes to include tables.

Opening this issue to capture this discussion outside of comments on a PR, and to ask the WG for thoughts. From the comments on the PR:

"Have this new property apply to tables in the same way it applies to grid. They are very similar visually, and the end user doesn’t care what display type was used to achieve the grid of rows and columns they are looking at. It would be weird if you could make the reading order better for grid in rtl or vertical writing, or to be able to read down columns first, but not for table. One type of reading behavior for a visual grid generated one way but not the other means unpredictable behavior for the user."

I've not seen any requests for this type of behavior from authors as far as tables are concerned.

@tabatkins
Copy link
Member

I was under the impression that screen readers already have relatively powerful table-reading abilities, because the row/column association is already established in the markup and both axises are assumed to be semantically relevant. Do we need to add any controls for tables?

@bradkemper
Copy link
Contributor

Perhaps ask someone from a11y WG, but my understanding is that there are different modes of reading, and sequential reading might not always do the desired thing. There will be some order to how it is read, and that order might not be according to the author's intent (vertical first or horizontal first), or what is best for with rtl or vertical writing.

@aardrian
Copy link

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.

@fantasai fantasai added the a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. label Sep 24, 2024
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-display-4] Should the reading-order-items property apply to tables in addition to flex and grid layouts?.

The full IRC log of that discussion <astearns> PaulG: I’m in favor
<fantasai> scribenick: fantasai
<fantasai> TabAtkins: Current thread has folks suggesting not to apply to tables, because screenreaders have robust handling of tables
<fantasai> [AdrianRoseli also said this]
<Lionel_Wolberger> zakim, who is here?
<Zakim> Present: TabAtkins, dbaron, zcorpan, dandclark, tantek, sanketj_, cwilso, vmpstr, keithamus, khush, lea, jensimmons, noamr, rachelandrew, ydaniv, miriam, past, emilio, moonira,
<Zakim> ... ethanjv, bkardell_, kbabbitt, kzms, oriol, ntim, dholbert, PaulG, Lionel_Wolberger, Angela, CharlesL, matatk, janina, kizu, Nigel_Megitt, flackr
<Zakim> On IRC I see moonira, Roy, Lionel_Wolberger, masonf, karlcow, nigel, tink, Di, CharlesL, janina1, zcorpan, Angela, khush, kbabbitt, matatk, florian_irc, PaulG, miketaylr, siye,
<Zakim> ... ntim, oriol, atrigent__, kschmi, bkardell_, lea, kizu, past, RRSAgent, Zakim, sanketj, sylvaing_, shans_, Rossen-, leaverou_, projecto-, Francis_Storr, flackr, kzms2,
<Zakim> ... ondrejkonec, Krinkle, cmp, jbroman, dbaron, jcraig, foolip, tusf, keithamus, github-bot, jamesn, hyojin_, cabanier, geheimnis`, zrhoffman, CSSWG_LogBot, dustinm, fantasai,
<Zakim> ... vmpstr, bramus
<dbaron> s/Roseli/Roselli/
<matatk> q?
<fantasai> PaulG: It could be helpful for responsive tables, where the rendering changes
<fantasai> PaulG: if author has control over the flow
<fantasai> PaulG: That may be something to spend time on a demo
<matatk> q+
<zcorpan> q+
<fantasai> fantasai: One possible way forward would be to not apply if <table> rendered as table, but if rendering as grid/flex apply it
<PaulG> Adrian's responsive table https://adrianroselli.com/2017/11/a-responsive-accessible-table.html
<fantasai> gregwhitworth: Do you get accessibility of tables using table display on DIVs?
<fantasai> TabAtkins: no
<matatk> q?
<gregwhitworth> q+
<fantasai> matatk: I understand what Paul's saying about consistency and those cases, but also understand what Adrian's saying about having a well-defined model for this
<fantasai> matatk: we don't want to get into a situation where devs think they have to put reading-order on everything
<fantasai> ... and they're duplicating what the system could do better than they can
<fantasai> ... don't want to reinvent that
<fantasai> ... Elika, your solution sounds reasonable ; but what if it looks like a table but done differently?
<fantasai> ... from our perspective, we have several different edge cases to think about
<fantasai> ... also some reasonable connections for a11y testing and AT industry
<fantasai> ... so can ask people about it
<fantasai> ... also in-house we have ARIA WG
<fantasai> ... APA's role would be to coordinate that broader review
<fantasai> ... lots of good points on all the sides; but could be an impactful change
<fantasai> ... so give us some homework :)
<matatk> q?
<matatk> ack me
<matatk> ack zcorpan
<fantasai> zcorpan: What is the screenreader behavior if you have a <table> element but you change the CSS to display: something else
<fantasai> ... do they still use table mode to navigate that, or do you get whatever reading mode of the display type?
<fantasai> matatk: excellent question
<fantasai> tink: I believe unless 'display: none', has no impact on a11y tree
<fantasai> matatk: what about for grid?
<fantasai> matatk: we'll need to investigate
<fantasai> zcorpan: I think that would inform what to do here
<fantasai> ... because if behavior is still using table mode, then reading-flow shouldn't apply
<gregwhitworth> ack gregwhitworth
<matatk> q?
<TabAtkins> fantasai: I think the default value of reading-flow should continue to do what we do today, so if display changes it has no effect
<TabAtkins> fantasai: If you style it with display:flex *and* apply reading-flow, we could consider it having an effect
<gregwhitworth> q+
<matatk> q?
<TabAtkins> fantasai: I could see reasons to restyle <table> with Grid Becuase you wanna do something fancy, but want to preserve the a11y affordances from it being a table
<matatk> ack fantasai
<matatk> ack gregwhitworth
<fantasai> gregwhitworth: For tables done without an actual <table> element, how often are they giving the expected AT experience?
<kizu> q+
<fantasai> ... Do thinks make it worse?
<fantasai> matatk: Question is, if you make a custom table out of DIVs and aria, what experience do you give?
<fantasai> gregwhitworth: How commonly would people do that in practice, using DIV-based tables + ARIA?
<fantasai> PaulG: Common in my work because we deal with very large virtualized tables.
<fantasai> ... don't know how common across the Web, but in FinTech it's quite normal
<fantasai> gregwhitworth: Do people do it correctly from a11y standpoint, in your experience?
<fantasai> PaulG: Lots of walled gardens, can't see in them ; but in ours we try our best
<fantasai> matatk: it's certainly doable, and works pretty well when done properly
<fantasai> gregwhitworth: 5yrs from now, could we deprecate <table>?
<fantasai> ... responsive tables is a common ask
<fantasai> ... how can we help authors fall into the pit of success?
<matatk> q?
<fantasai> ... because more people will lean into this over time
<matatk> ack kizu
<Lionel_Wolberger> q?
<fantasai> kizu: Cases where there's a table with display: flex or grid
<fantasai> ... usually done at transition point, or to use features of a grid
<fantasai> ... sometimes authors had to apply role to element because browsers would lose it otherwise
<fantasai> ... a lot of issues
<fantasai> ... sometimes browsers lose this role, especially with 'display: contents'
<fantasai> ... It would make a table display: grid or flex, then change order of rows
<fantasai> ... with reading-flow we might want to reorder rows or colu,ns
<fantasai> s/colu,ns/columns/
<matatk> q?
<matatk> ack fantasai
<Zakim> fantasai, you wanted to ask why it's done
<fantasai> fantasai: I think if we need more capabilities for responsive tables, we should add those capabilities
<fantasai> ... not require shifting to DIVs with ARIA because that's hard to get right

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. css-display-4
Projects
Status: Joint meetings
Development

No branches or pull requests

8 participants