[css-display-4] Should the reading-order-items property apply to tables in addition to flex and grid layouts? #9922
Comments
|
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? |
|
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. |
|
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. |
|
The CSS Working Group just discussed 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 |
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:
I've not seen any requests for this type of behavior from authors as far as tables are concerned.
The text was updated successfully, but these errors were encountered: