Open Bug 1904796 Opened 4 days ago Updated 2 days ago

Text-Fragments: Set sensible default colors for high contrast mode

Categories

(Core :: DOM: Selection, task)

Product:
Core
Component:
DOM: Selection
Type:
task

Tracking

()

People

(Reporter: jjaschke, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

Currently, default colors for ::target-text are implemented for the non-HCM case (bug 1867940). We need to deal with this for High-Contrast mode as well. Citing from JIRA:

HCM mode: There are 2 suggestions - We could either use SelectedItem and SelectedItemText or alternatively, use Mark and MarkText, and for the latter a11y recommends wrapping the text fragment in <mark> tags so assistive technology is aware and can announce it to the user.

This should be done together with addressing other a11y concerns, eg. screen reader support, which needs to be conceptualized first.

If I understand correctly, there are two separate issues:

  • HCM colors. We could implement this in the UA stylesheet with the suggested color keywords (SelectedItem and SelectedItemText or Mark and MarkText), possibly only in a @media (prefers-contrast: more) { } block
  • 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.

Morgan, any insight you can add here?

Flags: needinfo?(mreschenberg)

(In reply to Simon Pieters [:zcorpan] (OOO until July 29) from comment #1)

If I understand correctly, there are two separate issues:

  • HCM colors. We could implement this in the UA stylesheet with the suggested color keywords (SelectedItem and SelectedItemText or Mark and MarkText), possibly only in a @media (prefers-contrast: more) { } block
  • 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.

Let's spin off the exposure of the highlighted range issue to bug 1905211 .

You need to log in before you can comment on or make changes to this bug.