Text-Fragments: Set sensible default colors for high contrast mode
Categories
(Core :: DOM: Selection, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox131 | --- | fixed |
People
(Reporter: jjaschke, Assigned: jjaschke)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
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.
Comment 1•2 years ago
|
||
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 multiplemarknodes since the range can cross element boundaries. Otherwise we'd need some way to annotate a range of text as being highlighted.
Comment 3•2 years ago
|
||
(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 multiplemarknodes 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 .
Comment 4•2 years ago
|
||
(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
We should probably do this in a @media (forced-colors) block, and instead provide higher contrast versions of the non-CSS System Colors we're using for @media (prefers-contrast: more). I think Mark and MarkText are appropriate, we use SelectedItem and SelectedItemText for highlighted text, which could get confusing if a user highlights additional text on the page.
Comment 5•2 years ago
|
||
But we have system colors for text fragments already, and mark / marktext are just hard-coded yellow / black. What's the rationale for that?
Comment 6•2 years ago
|
||
That said, this code probably still needs something like this for the target-text color computation, like we have for ::selection
| Assignee | ||
Comment 7•2 years ago
|
||
But we have system colors for text fragments already, and mark / marktext are just hard-coded yellow / black. What's the rationale for that?
They provide a higher contrast (#FFFF00/#000000) than the normal version.
I'll create a patch that implements the check mentioned in comment 6, which will set mark/marktext as colors for forced-colors, and overrides the standard target-text colors as well as custom colors.
| Assignee | ||
Comment 8•2 years ago
|
||
Updated•2 years ago
|
Comment 10•2 years ago
|
||
| bugherder | ||
Description
•