https://bugs.documentfoundation.org/show_bug.cgi?id=91739
--- Comment #9 from Jacobo Aragunde Pérez <[email protected]> --- (In reply to Joanmarie Diggs from comment #6) > > For each page in the document, create an accessible (ATK_ROLE_PAGE on my > platform; dunno about IA2). Regardless of the role, these page accessibles > are all immediate children of the document and are all created upon document > load. Also load the accessible children for a given page when that page is > accessed. Lazy load the rest of the children of each page. Unfortunately, this approach seems to be difficult to implement. There is no concept of "pages" in the document model; pages are an artifact of the view that wraps the contents. There are contents that can be split between two pages, so we would still have to do some hacks to model the contents in a proper tree. Finally, the flow of paragraphs to/from the next/previous page when editions happen would have to trigger a rebuild of parts of the accessibility tree, this should be doable but it's definitely inconvenient and would probably generate a lot of event noise. > Page 1 (which is visible) > * Paragraph 1 > * Paragraph 2 > Page 2 (not currently visible) > * Paragraph 3 > * Paragraph 4 > > At least on my platform, if you get the last child of the accessible > document, you get "Paragraph 2". If you then get the flows-to target of that > child you get "Paragraph 3". So far so good. But if you get the parent of > "Paragraph 3" you get the accessible document which contains "Paragraph 1" > and "Paragraph 2". In other words, the parent of "Paragraph 3" does not have > "Paragraph 3" as a child. That's a broken tree. When the paragraph 3 is got through the flows-to relation, is the parent component (the document) refreshed? Would that work to implement "say all"? > This issue also impacts things like Orca's ability to do structural > navigation (navigate amongst headings, for instance). Regarding this topic, would it help if we implemented flows to/from relations among header objects? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
