https://bugs.documentfoundation.org/show_bug.cgi?id=156657
Michael Weghorn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 CC| |[email protected], | |[email protected] --- Comment #2 from Michael Weghorn <[email protected]> --- (In reply to Joanmarie Diggs from comment #0) > Additional Info: > I filed https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138 to ask > Atspi to not descend ginormous tables. > > As you will see in a later comment, I also suggested that Calc should > consider doing what web app authors with giant grids do, namely only include > a subset of the conceptual table in the DOM and use ARIA properties to > expose stuff ATs should report to end users. I'm not experienced with what web authors do, so have a few questions: Are there any further information/best-practices on how that should work, i.e. what you'd expect Calc to report, etc.? I've found https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/table_role but that doesn't really give too many details yet. It has this example: > The above is part of a table. While the full table has 81 entries, as > indicated > by the aria-rowcount property, only four are currently visible. The columns > are > sortable, but not currently sorted, as indicated by the aria-sort property on > the column headers. Does that mean that only what's visible on screen should be exposed? IIRC, Colomban (CC'ed) mentioned that generally, documents should not only expose what's on screen and e.g. tdf#96492 also suggests that off-screen paragraphs in Writer should be part of the a11y tree. Would we run into a similar problem with Writer when exposing all off-screen pages/paragraphs in the a11y tree as well, e.g. if somebody opens a 1000 page document with thousands of paragraphs? >From what I have seen, the current handling of tables in LO wrt a11y is that all cells are treated as children and the corresponding child index is used in many places (for calculating row/col index,...), so changing that would probably be a larger change. Without knowing much about how this is handled elsewhere, limiting what children to look into (iterate over?) on the client side (as the commit in https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138 does) seems like a good option to me, at least in the short run. (In particular for the status bar example given here, descending into any children of objects with document roles would seem unnecessary.) I'm thankful for further input on how to address this in practice. -- You are receiving this mail because: You are the assignee for the bug.
