Closed Bug 1905211 Opened 8 months ago Closed 7 months ago

Text-Fragments: expose the highlighted range to AT

Categories

(Core :: Disability Access APIs, task)

task

Tracking

()

RESOLVED FIXED
130 Branch
Tracking Status
firefox130 --- fixed

People

(Reporter: hsinyi, Assigned: Jamie)

References

(Blocks 1 open bug)

Details

Attachments

(10 files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

spin off the second point of bug 1904796 comment 1 to here
Expose the highlighted range to AT. Here "wrapping in <mark>", we can't modify the DOM since that would break scripts and violate specs. We could change the Accessibility tree, although it might need to insert multiple mark nodes since the range can cross element boundaries. Otherwise we'd need some way to annotate a range of text as being highlighted.

No longer depends on: 1904796
Summary: Text-Fragments: expose highlighted range to AT → Text-Fragments: expose the highlighted range to AT
Component: DOM: Selection → Disability Access APIs
Assignee: nobody → jteh

This test is disabled on CI because it's a bit fragile and we've never been able to work out how to fix that.
However, it's still useful locally.
Unfortunately, because it's disabled on CI, this problem wasn't caught when tests were moved around.

This doesn't matter for spelling errors.
However, we will soon generalise this code for use with other attributes like this.
In particular, custom highlights require us to use AbstractRange.
While we aren't supporting custom highlights in this bug, it is more effective to do this as part of this major refactor rather than doing another refactor later.

See the code comments for details.
We will soon use this for spelling errors, etc.

An array of ints is fine for spelling errors, but we need to support multiple attributes like this.
We could use an array of ints for each attribute and search each one, though that would require more work in the parent process.
Also, custom highlights can have multiple selections for a single highlight type.
This would be rather messy with int arrays, especially where multiple selections span beyond the Accessible.

Previously, this code was specifically tied to the spell check selection.
Actually adding more selection types will come in subsequent patches.

nsISelectionListener isn't sufficient because it only notifies that the selection has changed.
A11y needs to know specifically which ranges were added or removed.
Previously, we handled this specifically for spelling errors in mozInlineSpellChecker.
That code has been removed and replaced with a more general approach.

Since we now have these notifications, rather than using nsISelectionListener just to fire events, we now use these notifications for that as well.
This avoids the need to add additional nsISelectionListeners, which would get messy particularly for custom highlights where there can be an arbitrary number of selections at any given time.

We need this for the text fragment tests to load the page with an initial fragment.

This is now simply a matter of leveraging the work in the previous patches to support the new selection type and map it to the correct attribute.

Attachment #9413737 - Attachment description: Bug 1905211 part 7: Notify accessibility about ranges that are added or removed from relevant selections. → Bug 1905211 part 7: Notify accessibility about ranges that are added or removed from selections.
Blocks: 1909142
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/30bd5e3c1866 part 1: Remove unnecessary script load in browser_text_spelling.js so that it can actually run. r=morgan https://hg.mozilla.org/integration/autoland/rev/9f5803b39d98 part 2: Use AbstractRange instead of nsRange for a11y spelling error code. r=morgan https://hg.mozilla.org/integration/autoland/rev/15cfaad587a6 part 3: Introduce TextOffsetAttribute struct and support it as a serialisable attribute value. r=morgan https://hg.mozilla.org/integration/autoland/rev/0fa8b0016abf part 4: Use TextOffsetAttribute for spelling errors. r=morgan https://hg.mozilla.org/integration/autoland/rev/4ceae709871c part 5: Generalise the a11y spelling error code to support multiple selection types. r=morgan https://hg.mozilla.org/integration/autoland/rev/32ad063c00ea part 6: Adjust names and comments to reflect that this code can now be used for more than spelling errors. r=morgan https://hg.mozilla.org/integration/autoland/rev/085ae013a8b1 part 7: Notify accessibility about ranges that are added or removed from selections. r=smaug,morgan https://hg.mozilla.org/integration/autoland/rev/c720d5439268 part 8: Move code to check whether text attribute ranges match out of browser_text_spelling.js and generalise it for use with other attributes. r=morgan https://hg.mozilla.org/integration/autoland/rev/44df48fd4cc9 part 9: Add urlSuffix parameter to addAccessibleTask. r=morgan https://hg.mozilla.org/integration/autoland/rev/4248d8df19ca part 10: Expose target text as an a11y text attribute. r=morgan https://hg.mozilla.org/integration/autoland/rev/3b8dc45d7b53 apply code formatting via Lando
Blocks: 1911505
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: