Closed Bug 1096071 Opened 10 years ago Closed 1 year ago

atk_text_get_text_at_offset, IAccessibleText::textAtOffset is broken for CSS-generated content

Categories

(Core :: Disability Access APIs, defect, P3)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox113 --- fixed
firefox114 --- fixed
firefox115 --- fixed

People

(Reporter: jdiggs, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(1 file)

Attached file test case
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)
Jamie: You seeing this is IA2?
Flags: needinfo?(jamie)
Keywords: access
(In reply to Joanmarie Diggs from comment #1)
> Jamie: You seeing this is IA2?
Yes.
Flags: needinfo?(jamie)
Summary: atk_text_get_text_at_offset is broken for CSS-generated content → atk_text_get_text_at_offset, IAccessibleText::textAtOffset is broken for CSS-generated content
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.
Blocks: texta11y
Depends on: 12460

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 :)

Yes, it does seem unlikely this will ever be fixed in layout, so we should find a way to work around it in a11y.

Priority: -- → P3

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.

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).

This is fixed by the new TextLeafPoint implementation for Cache the World.

Depends on: a11y-ctw-text
No longer depends on: 12460
Severity: normal → S3
Depends on: 1782873
No longer depends on: a11y-ctw-text

This is resolved by Cache the World, which is enabled by default in Firefox 113.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: