atk_text_get_text_at_offset, IAccessibleText::textAtOffset is broken for CSS-generated content
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
People
(Reporter: jdiggs, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: access)
Attachments
(1 file)
167 bytes,
text/html
|
Details |
Steps to reproduce: 1. Load the test case 2. Use Accerciser (or the tool of your choice) to get the word and line at offset 0 Expected results: The string and offsets returned would reflect the text at offset 0. Actual results: The line returned excludes the CSS-generated text. The word returned is an empty string whose start and end offsets correspond to the first offset of the non-generated content: >> acc.queryText().getTextAtOffset(0, TEXT_BOUNDARY_LINE_START) ('Stuff you must do.', 11, 29) >> acc.queryText().getTextAtOffset(0, TEXT_BOUNDARY_WORD_START) ('', 11, 11)
Reporter | ||
Comment 1•10 years ago
|
||
Jamie: You seeing this is IA2?
Comment 2•10 years ago
|
||
(In reply to Joanmarie Diggs from comment #1) > Jamie: You seeing this is IA2? Yes.
Reporter | ||
Updated•10 years ago
|
Comment 3•10 years ago
|
||
If we are not going to switch to own a11y-internal API to traverse the text by lexems or add hacks like we did for list bullets then I think we should wait for bug 12460. If layout stuff are fixed then a11y will be fixed as well I think.
Comment 4•6 years ago
|
||
Mmm, bug 12460 has waited for 20 years? I'm not sure we want to wait for it for another 20 years with hackarounds in screen readers which pose other problems in the meanwhile :)
Comment 5•6 years ago
|
||
Yes, it does seem unlikely this will ever be fixed in layout, so we should find a way to work around it in a11y.
Comment 6•4 years ago
|
||
Unfortunately, this is still broken for the line and word cases despite the latest offset fixes. This is even one where the start word and line offset is wrong, e. g., it is always greater than the passed in offset if that offset is within the CSS generated content boundaries.
Comment 7•4 years ago
|
||
my guess is that this would need a fix in FindOffset similar to the fix for list bullets. It might even use the same workaround code, just an additional condition to check for a CSS generated content text leaf Accessible. We may not currently have any way to distinguish those - I'm not sure - but that should be easy enough to add (perhaps a different AccType).
Updated•3 years ago
|
Updated•2 years ago
|
Comment 9•1 year ago
|
||
This is resolved by Cache the World, which is enabled by default in Firefox 113.
Description
•