implement readability backplate for high contrast mode
Categories
(Core :: Layout, enhancement, P2)
Tracking
()
People
(Reporter: asa, Assigned: morgan)
References
(Depends on 1 open bug, Blocks 1 open bug, Regressed 1 open bug, )
Details
(Keywords: access)
Attachments
(9 files, 2 obsolete files)
1.13 KB,
text/html
|
Details | |
36.77 KB,
image/png
|
Details | |
544 bytes,
text/html
|
Details | |
32.15 KB,
image/png
|
Details | |
353 bytes,
text/html
|
Details | |
498.30 KB,
image/png
|
Details | |
659.69 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
2.91 KB,
text/plain
|
chutten
:
data-review+
|
Details |
Microsoft describes it here https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/HighContrast/explainer.md
The goal of high contrast is to ensure a certain level of contrast between foreground and background colors. A problem arises with images. If text lies atop an image, altering the color of the text in high contrast will not guarantee its readability. One option would be to override images to allow text readability. This solution, however, is not an ideal one, as it can alter the context of a webpage for users under high contrast.
Instead, a preferred solution is to draw a so-called "readability backplate" behind all text to ensure contrast for text lying above images. As illustrated in the screenshots below, adding a backplate behind text in high contrast can drastically increase its readability. This solution is currently used in Microsoft Edge to ensure the readability of text in high contrast.
This backplate does not replace the background of an element, but rather is drawn on an intermediary layer:
As the diagram demonstrates, an element's text content is rendered using the WindowText system color and a backplate with a Window system color fill is drawn behind the text. These are then layered on top of the element's background (with background-color being filtered out). In the case of links, the text would instead use the appropriate high contrast link color.
Updated•4 years ago
|
Comment 1•4 years ago
|
||
I looked into how this could be implemented today. I don't think it would be 100% straightforward, like adding a background to text frames. The problem is that if there is a paragraph with a line height of 1em or smaller, the running background will obscure part of the preceding line.
Assignee | ||
Comment 2•4 years ago
|
||
Moved explainer document: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Accessibility/HighContrast/explainer.md
Comment 3•4 years ago
|
||
Here's a testcase to exercise a few interesting scenarios, to load in Edge and understand its behavior a bit better.
Comment 4•4 years ago
|
||
Here's a screenshot of Edge's take on testcase 1, in High Contrast mode. A few observations:
- It is possible for a text-backplate to stomp on top of the text from another element, as shown by "ABSPOS TEXT" at top left (its backplate visibly stomps on the "relpos inline" text). This makes sense; it's just a good demonstration that they don't do "all text goes in front of all backplates, globally" or anything like that (which I was worried might be a possibility).
- Looking at the lime background-image: Edge does not seem to render background images for
display:inline
elements (first box), though it does render them fordisplay:inline-block
elements (second box). (The background-image property still computes to the image URL, but it simply doesn't render.) - The background image on the relatively-positioned
inline-block
(second box) does cover up the text that follows it, which makes sense since it's positioned which means it draws in front. (This demonstrates that they don't e.g. draw all backplates in front of all backgrounds, or that sort of thing.) - WEIRD: the final box, with a negative
z-index
, seems to go "behind" the canvas entirely! It doesn't show up at all.
Also worth noting: when I turn off High-Contrast mode, Edge agrees with Firefox entirely.
Comment 5•4 years ago
|
||
Comment 6•4 years ago
•
|
||
As shown in this screenshot of testcase 2, with overlapping text:
- A
display:inline
element seems to have its backplate drawn "cooperatively" with other text on the same line (since the text is overlapping but visible).
...vs: - A
display:inline-block
element's backplate seems to be drawn separately from (and potentially on top of) other text & inline-level content in the same line (since the text is overlapping and the inline-block's backplate visibly stomps on the text that it overlaps).
Assignee | ||
Comment 7•4 years ago
|
||
Depends on D42979
Assignee | ||
Comment 8•4 years ago
|
||
Depends on D43264
Assignee | ||
Comment 9•4 years ago
|
||
Assignee | ||
Comment 10•4 years ago
|
||
Weird "edge" case (haha...) on the test case I just uploaded. Have to post screenshot from my windows machine but here's the behaviour of that test in nightly with my current working patch:
Assignee | ||
Comment 11•4 years ago
|
||
same test case on edge; note div height is different
Assignee | ||
Comment 12•4 years ago
|
||
[the above are mostly for me to note this is something I need to fix; my windows machine has about a billion updates it wants to do, so the screenshot is my reference lol]
Assignee | ||
Comment 13•4 years ago
|
||
Bug 1539212: Add readability backplate support for block elements containing text.
Bug 1539212 [wip]
Bug 1539212: Margin fixes.
Bug 1539212: Add readability support for all elements containing text when HCM or A11y Theme is active.
Updated•4 years ago
|
Updated•4 years ago
|
Hi Morgan, do you have someone to review this? I'm interested in getting this fix into 70 (for bug 1575220).
Comment 15•4 years ago
|
||
Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information
Assignee | ||
Comment 16•4 years ago
|
||
(In reply to Liz Henry (:lizzard) from comment #14)
Hi Morgan, do you have someone to review this? I'm interested in getting this fix into 70 (for bug 1575220).
Hi! I have @dholbert and @eeejay set to review the layout and accessibility portions of this bug (respectively). There's a bit more work to be done re: creating a user-facing preference to enable or disable this feature, but hopefully the conversations (and work) around that portion will wrap up today and this weekend.
Comment 17•4 years ago
|
||
(In reply to Liz Henry (:lizzard) from comment #14)
Hi Morgan, do you have someone to review this? I'm interested in getting this fix into 70 (for bug 1575220).
Hi Liz, this is an ambitious feature that will need time in nightly, and will likely be preffed off for a cycle or two. I think they need to find another solution in bug 1575220 that does not use background images.
Comment 18•4 years ago
|
||
Hey Liz. As per comment 17, targeting this for 70 release is probably not feasible. Can we remove the tracking flag here? Thanks!
Yes, no problem. Thanks for the explanation!
Updated•4 years ago
|
Comment 20•4 years ago
|
||
Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f5b8fba989b4 Add readability backplate for all elements containing text when HCM or a11y theme is active. r=dholbert,mattwoodrow
Comment 22•4 years ago
|
||
Backed out changeset f5b8fba989b4 (bug 1539212) for reftest failures on backplate-bg-image-001.html.
Backout: https://hg.mozilla.org/integration/autoland/rev/86d1d52f1174927f18accc9f3014c37429077c7a
Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=f5b8fba989b48bcad5624201e57723a96e91dfd3&selectedJob=266921708
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=266921708&repo=autoland&lineNumber=62135
Assignee | ||
Updated•4 years ago
|
Comment 23•4 years ago
|
||
Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/928b755ef57b Add readability backplate for all elements containing text when HCM or a11y theme is active. r=dholbert,mattwoodrow
Comment 24•4 years ago
|
||
Backed out changeset 928b755ef57b (Bug 1539212) for backplate-bg-image-006.html failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/d6f9a934bea2b6345d46a5fa4896bd0a75a54a34
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267557697&repo=autoland&lineNumber=9851
[task 2019-09-20T00:29:09.796Z] 00:29:09 INFO - REFTEST TEST-START | http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006.html == http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006-ref.html
[task 2019-09-20T00:29:09.796Z] 00:29:09 INFO - REFTEST INFO | SET PREFERENCE pref(browser.display.document_color_use,2)
[task 2019-09-20T00:29:09.810Z] 00:29:09 INFO - REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006.html | 1560 / 7713 (20%)
[task 2019-09-20T00:29:09.812Z] 00:29:09 INFO - REFTEST INFO | RESTORE PREFERENCE pref(browser.display.document_color_use,0)
[task 2019-09-20T00:29:09.812Z] 00:29:09 INFO - REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006-ref.html | 1560 / 7713 (20%)
[task 2019-09-20T00:29:09.812Z] 00:29:09 INFO - REFTEST TEST-UNEXPECTED-PASS | http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006.html == http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006-ref.html | image comparison, max difference: 0, number of differing pixels: 0
[task 2019-09-20T00:29:09.818Z] 00:29:09 INFO - REFTEST IMAGE: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAebklEQVR4nO3d...
[task 2019-09-20T00:29:09.818Z] 00:29:09 INFO - REFTEST INFO | Saved log: START http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006.html
[task 2019-09-20T00:29:09.818Z] 00:29:09 INFO - REFTEST INFO | Saved log: [CONTENT] OnDocumentLoad triggering AfterOnLoadScripts
[task 2019-09-20T00:29:09.818Z] 00:29:09 INFO - REFTEST INFO | Saved log: Initializing canvas snapshot
[task 2019-09-20T00:29:09.818Z] 00:29:09 INFO - REFTEST INFO | Saved log: DoDrawWindow 0,0,800,1000
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: [CONTENT] RecordResult fired
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: RecordResult fired
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: START http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006-ref.html
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: [CONTENT] OnDocumentLoad triggering AfterOnLoadScripts
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: Initializing canvas snapshot
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: DoDrawWindow 0,0,800,1000
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: [CONTENT] RecordResult fired
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST INFO | Saved log: RecordResult fired
[task 2019-09-20T00:29:09.819Z] 00:29:09 INFO - REFTEST TEST-END | http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006.html == http://10.0.2.2:8854/tests/layout/reftests/high-contrast/backplate-bg-image-006-ref.html
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 25•4 years ago
|
||
More in-depth info about the reftest.list fuzzy annotations:
(1) Both Windows and Mac suffer from Ahem anti-aliasing, so I had to add fuzzy-if annotations for both platforms to the following tests:
- Mac: 001, 002, 003, 005, 007
- Windows: 006, 007 (the range here represents the difference between anti-aliasing on buttons on windows 7 vs windows 10 - https://treeherder.mozilla.org/#/jobs?repo=try&revision=5bb06d441648e04f1612956a5808401eca858159&selectedJob=269087678)
(2) Native and non-native select elements have issues with visual overflow, and so do MacOS native buttons. On MacOS native button and select elements, extra visual overflow is added in the vertical and horizontal directions. For native select elements on Windows/Linux, and non-native firefox select elements, extra overflow is added in the horizontal direction only. The size does not scale with the number of <option>'s in any of the above cases; it looks like it has to do with some extra, widget-specific visual padding. We also have some differing pixels because I was unable to mock the select backplate in the reftest case. The following tests' fuzzy-if annotations are because of the visual overflow difference and select mocking:
- Mac: 006, 008, 009 [native button, native select, non-native select]
- Windows: 008, 009 [native select, non-native select]
- Android: 008, 009 ["]
- Linux: 008, 009 ["]
Assignee | ||
Comment 26•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 27•4 years ago
|
||
Comment on attachment 9098291 [details] Telemetry Questions DATA COLLECTION REVIEW RESPONSE: Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate? Yes. This collection is Telemetry so is documented in its definitions file [Scalars.yaml](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Scalars.yaml) and the [Probe Dictionary](https://telemetry.mozilla.org/probe-dictionary/). Is there a control mechanism that allows the user to turn the data collection on and off? Yes. This collection is Telemetry so can be controlled through Firefox's Preferences. If the request is for permanent data collection, is there someone who will monitor the data over time? No. This collection will expire in Firefox 73. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under? Category 2, Interaction. (Well, maybe it's Cat 1 Technical because it's a pref, but it's a user-set pref so... 2) Is the data collection request for default-on or default-off? Default on for all channels. Does the instrumentation include the addition of any new identifiers? No. Is the data collection covered by the existing Firefox privacy notice? Yes. Does there need to be a check-in in the future to determine whether to renew the data? Yes. :morgan is responsible for renewing or removing the collection before it expires in Firefox 73. --- Result: datareview+
Comment 28•4 years ago
|
||
Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6baef669e147 Add readability backplate for all elements containing text when HCM or a11y theme is active. r=dholbert,mattwoodrow,Jamie
Comment 29•4 years ago
|
||
bugherder |
Comment 30•4 years ago
|
||
This has busted all the late beta simulation builds.
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=269901521&repo=try&lineNumber=3813
Could you, please, take a look?
Comment 31•4 years ago
|
||
In addition to fixing that error, the reftest.list
should probably explicitly set the preference so that the tests will pass even when EARLY_BETA_OR_EARLIER
isn't true.
Assignee | ||
Comment 32•4 years ago
|
||
(In reply to David Baron :dbaron: (away October 5-21) from comment #31)
In addition to fixing that error, the
reftest.list
should probably explicitly set the preference so that the tests will pass even whenEARLY_BETA_OR_EARLIER
isn't true.
Is explicitly setting the pref different from what the first few lines of the file do right now?
default-preferences test-pref(browser.display.document_color_use,2) test-pref(browser.display.permit_backplate,true)
Comment 33•4 years ago
|
||
Looks like we really need value: @IS_EARLY_BETA_OR_EARLIER@
in the .yaml file (we're currently missing the "IS_").
And RE the prefs in reftest.list: dbaron is out of office, so he probably won't see your request right away -- but I believe the existing default-preferences
line is sufficient & equivalent to setting the pref for each test. dbaron probably just didn't see it at first glance.
We'll find out for sure once we land the other change to unbreak late-beta simulation builds, anyway. :) If the default-preferences
annotation is sufficient (as I think it should be), then the tests will pass.
Updated•4 years ago
|
Assignee | ||
Comment 34•4 years ago
|
||
Landed follow-up patch on bug 1586577 :)
Assignee | ||
Comment 35•3 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]:
Firefox high-contrast mode will now render background images. Additionally, all visible text will be backplated to ensure it meets accessibility standards for high-contrast and readability.
[Suggested wording]:
High-contrast mode has been updated to allow background images. To maintain readability and ensure sufficient contrast, visible text in high-contrast mode will be backplated by the theme's background color.
[Links (documentation, blog post, etc)]:
This bug! https://bugzilla.mozilla.org/show_bug.cgi?id=1539212
As with global zoom, this is a possible blog post topic for later, once the accessibility blog is up and running
Assignee | ||
Comment 36•3 years ago
•
|
||
[I did this in the wrong order, sorry for the double comment]
Release Note Request (optional, but appreciated)
[Why is this notable]:
Firefox high-contrast mode will now render background images. Additionally, all visible text will be backplated to ensure it meets accessibility standards for high-contrast and readability.
[Suggested wording]:
High-contrast mode has been updated to allow background images. To maintain readability and ensure sufficient contrast, visible text in high-contrast mode will be backplated by the theme's background color.
[Links (documentation, blog post, etc)]:
This bug! https://bugzilla.mozilla.org/show_bug.cgi?id=1539212
As with global zoom, this is a possible blog post topic for later, once the accessibility blog is up and running
Assignee | ||
Comment 37•3 years ago
|
||
This is being preffed on in 73 (shipping default on instead of default off, which was shipped 71, 72), so requesting a relnote for 73 :)
Description
•