[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Hi all!

Letting everyone know that we are picking up this initiative again :) 
Please find an updated explainer here:  
MSEdgeExplainers/Accessibility/AriaNotify/explainer.md 
at main · MicrosoftEdge/MSEdgeExplainers (github.com) 
.
 
I've already updated the ChromeStatus.

There is also an updated design doc in the works, but still waiting on 
reviews from third parties.

Thanks!
Sara

On Wednesday, June 1, 2022 at 9:23:04 PM UTC-7 David Tseng wrote:

> Thanks for the responses here and sorry for the late reply.
>
> IIUC, this looks mostly like syntactic sugar. The imperitiveness of the 
> api is somewhat of an illusion since this takes the same code path as 
> ordinary live regions and for most platforms and even most clients on 
> Windows, it re-uses the same mechanics of delivering the announcement as a 
> live region.
>
> So, we are basically reduced to the two lines:
> someElement.textContent = 'foo';
>
> vs
>
> document.ariaNotify('foo');
>
> (assuming someElement is a live region).
>
> The key diff is some number of queueing modes to reorder the announcements 
> for the current callstack and the aforementioned syntax cleanup. The other 
> diff is not having to add a DOM element which is somewhat negligible if it 
> is positioned offscreen.
>
> Is that a fair assessment of the difference? If so, could we consider 
> introducing additions to live regions to get the queueing behaviors 
> introduced?
>
> On Fri, Mar 18, 2022 at 1:05 PM Sara Tang  wrote:
>
>> + Cynthia Shelly
>> --
>> *From:* Sara Tang 
>> *Sent:* Wednesday, March 9, 2022 3:32 PM
>> *To:* David Tseng ; blink-dev 
>> *Subject:* Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of 
>> Action API 
>>  
>> Hi David,
>>
>> Responses inline . I've also linked the design doc if you'd like to 
>> take a further look: 
>> https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing
>>
>> Cheers,
>> Sara
>>
>> --
>> *From:* David Tseng 
>> *Sent:* Monday, March 7, 2022 4:44 PM
>> *To:* blink-dev 
>> *Cc:* Sara Tang 
>> *Subject:* [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API 
>>  
>> Hi there,
>>
>> A few additional questions/comments:
>> - this api will be a separate channel from ordinary live regions. If we 
>> mix the two techniques, wouldn't the output be interleave? For example, an 
>> iframe with a live region, and another iframe wherein we call 
>> document.ariaNotify?
>>
>> In the Windows implementation, we are indeed using a different channel 
>> than live regions. However, the final invocation out of Chromium for both 
>> this API and live regions is into UIA, which has its own queuing mechanism. 
>> While it is possible for notifications to interleave, they will never 
>> interrupt each other (unless specifically intended)
>>
>> The plan for other systems is to hook our API into the existing ARIA live 
>> region machinery. It will have a similar outcome as above, where ariaNotify 
>> notifications may interleave with live ARIA region ones, but they won't 
>> interrupt or interfere with each other.
>>
>> - the way Chrome (at least) works is based on the serialization of a tree 
>> structure. This api appears to be a imperitive call, making it seem like 
>> the call gets honored immediately. However, the a11y tree gets pushed only 
>> on layout clean.
>> - what happens if I repeatedly call document.ariaNotify? Would these 
>> announcements queue up? Would they flush tts? Would it trigger a refresh of 
>> the accessibility tree?
>>
>> This is a good point! We mark the a11y tree as dirty whenever 
>> document.ariaNotify is called and store unqueued notifications on 
>> AXTreeData.
>>
>> - live regions have the aria-live polite|assertive properties which 
>> roughly (though not really for all screen readers) map to queue vs flushing 
>> tts. Is there something equivalent for this api?
>>
>> Yes! One of the goals for this API was to have more indicative properties 
>> to describe how notification behave. Currently, we have any combination of 
>> the following two properties (naming tbd):
>>
>>- PlaceInQueue: (front | back | newest-only)
>>   - front: place the notification in the front of the queue
>>   - back: place the notification in the back of the queue
>>   - newest-only: place the notification in the back of the queue, 
>>   but also drop all existing notifications from the same element (good 
>> for 
>>   progress bars, latest status, etc.)
>>- Interrupt: (true | false)
>>   - true: if a notification is currently speaking and shares the 
>>   same source as the one being queued, interrupt it and move to the next 
>>   notification in the queue
>>   - false: let the current notification speak to completion
>>
>> - many screen readers actually suppress live regions (e.g. NVDA) 

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: forced-color-adjust: preserve-parent-color

['Sara Tang' via blink-dev]

Hi Joe,

We are aiming for version 106!

Sara

From: Joe Medley 
Sent: Wednesday, June 22, 2022 10:19 AM
To: Mike Taylor 
Cc: Chris Harrelson ; Daniel Bratell 
; saraztang ; blink-dev 
; Danny Holly ; Sara Tang 
; Alison Maher 
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: forced-color-adjust: 
preserve-parent-color

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | 
jmed...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


On Wed, Jun 22, 2022 at 9:54 AM Mike Taylor 
mailto:miketa...@chromium.org>> wrote:
LGTM3

On 6/22/22 12:10 PM, Chris Harrelson wrote:
LGTM2

On Wed, Jun 22, 2022 at 9:05 AM Daniel Bratell 
mailto:bratel...@gmail.com>> wrote:

LGTM1

/Daniel

On 2022-06-15 23:33, Sara Tang wrote:
Hi, reviving this thread as the CSSWG resolution at [css-color] 
[css-color-adjust] Make system colors fully resolve (but flag they were system 
colors) thus reversing the resolution of #3847 · Issue #6773 · w3c/csswg-drafts 
(github.com)
  has been reached (though the standards posiiton for this particular feature 
hasn't been updated yet).  preserve-parent-color value for forced-color-adjust 
CSS property · Issue #591 · mozilla/standards-positions 
(github.com).

To summarize,
  - If both system colors and forced colors were resolved at compute time, 
`preserve-parent-color` would not be needed. This is similar to Mozilla, which 
gets the behavior of `preserve-parent-color` "for free".
  - The resolution of #6773 is to resolve system colors at compute time. Forced 
color are still resolved at used value time.
  - Thus, `preserve-parent-color` is still needed.

I believe we should now be unblocked to ship `preserve-parent-color` :)

Sara


On Sunday, November 21, 2021 at 1:10:54 PM UTC-8 Danny Holly wrote:
cause no harm

On Thursday, October 28, 2021 at 4:45:04 PM UTC-5 Sara Tang wrote:
Contact emails
sar...@microsoft.com, alison...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Contact emails
sar...@microsoft.com, alison...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification

[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

+ Cynthia Shelly

From: Sara Tang 
Sent: Wednesday, March 9, 2022 3:32 PM
To: David Tseng ; blink-dev 
Subject: Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

Hi David,

Responses inline . I've also linked the design doc if you'd like to take a 
further look: 
https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing

Cheers,
Sara


From: David Tseng 
Sent: Monday, March 7, 2022 4:44 PM
To: blink-dev 
Cc: Sara Tang 
Subject: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

Hi there,

A few additional questions/comments:
- this api will be a separate channel from ordinary live regions. If we mix the 
two techniques, wouldn't the output be interleave? For example, an iframe with 
a live region, and another iframe wherein we call document.ariaNotify?

In the Windows implementation, we are indeed using a different channel than 
live regions. However, the final invocation out of Chromium for both this API 
and live regions is into UIA, which has its own queuing mechanism. While it is 
possible for notifications to interleave, they will never interrupt each other 
(unless specifically intended)

The plan for other systems is to hook our API into the existing ARIA live 
region machinery. It will have a similar outcome as above, where ariaNotify 
notifications may interleave with live ARIA region ones, but they won't 
interrupt or interfere with each other.

- the way Chrome (at least) works is based on the serialization of a tree 
structure. This api appears to be a imperitive call, making it seem like the 
call gets honored immediately. However, the a11y tree gets pushed only on 
layout clean.
- what happens if I repeatedly call document.ariaNotify? Would these 
announcements queue up? Would they flush tts? Would it trigger a refresh of the 
accessibility tree?

This is a good point! We mark the a11y tree as dirty whenever 
document.ariaNotify is called and store unqueued notifications on AXTreeData.

- live regions have the aria-live polite|assertive properties which roughly 
(though not really for all screen readers) map to queue vs flushing tts. Is 
there something equivalent for this api?

Yes! One of the goals for this API was to have more indicative properties to 
describe how notification behave. Currently, we have any combination of the 
following two properties (naming tbd):

  *   PlaceInQueue: (front | back | newest-only)
 *   front: place the notification in the front of the queue
 *   back: place the notification in the back of the queue
 *   newest-only: place the notification in the back of the queue, but also 
drop all existing notifications from the same element (good for progress bars, 
latest status, etc.)
  *   Interrupt: (true | false)
 *   true: if a notification is currently speaking and shares the same 
source as the one being queued, interrupt it and move to the next notification 
in the queue
 *   false: let the current notification speak to completion

- many screen readers actually suppress live regions (e.g. NVDA) or give users 
a way to turn them off. This api might reduce the ability for screen readers to 
do this depending on how it gets implemented.

Another good point! I think it makes sense that if live regions are suppressed, 
we would want this API to also be suppressed.

On non-Windows systems, since we will be hooking directly into the existing 
ARIA live regions implementation, we will share the same behavior as ARIA live 
regions (aka. suppress live regions => suppress JS API).

I'm not so sure in the Windows implementation, I'll do more research on how 
live regions are suppressed in screen readers.

- at least via the current proposed change, it looks like notify is trying hard 
to be a direct tts channel to the screen reader. It has very little to do with 
ARIA?

That is correct, but we decided to keep the ARIA-naming because many web 
authors associate accessibility with ARIA. Thus, this naming most succinctly 
expresses the intention of the API.

On Friday, January 28, 2022 at 4:26:36 PM UTC-8 Sara Tang wrote:
Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component

[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Hi David,

Responses inline . I've also linked the design doc if you'd like to take a 
further look: 
https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing

Cheers,
Sara


From: David Tseng 
Sent: Monday, March 7, 2022 4:44 PM
To: blink-dev 
Cc: Sara Tang 
Subject: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

Hi there,

A few additional questions/comments:
- this api will be a separate channel from ordinary live regions. If we mix the 
two techniques, wouldn't the output be interleave? For example, an iframe with 
a live region, and another iframe wherein we call document.ariaNotify?

In the Windows implementation, we are indeed using a different channel than 
live regions. However, the final invocation out of Chromium for both this API 
and live regions is into UIA, which has its own queuing mechanism. While it is 
possible for notifications to interleave, they will never interrupt each other 
(unless specifically intended)

The plan for other systems is to hook our API into the existing ARIA live 
region machinery. It will have a similar outcome as above, where ariaNotify 
notifications may interleave with live ARIA region ones, but they won't 
interrupt or interfere with each other.

- the way Chrome (at least) works is based on the serialization of a tree 
structure. This api appears to be a imperitive call, making it seem like the 
call gets honored immediately. However, the a11y tree gets pushed only on 
layout clean.
- what happens if I repeatedly call document.ariaNotify? Would these 
announcements queue up? Would they flush tts? Would it trigger a refresh of the 
accessibility tree?

This is a good point! We mark the a11y tree as dirty whenever 
document.ariaNotify is called and store unqueued notifications on AXTreeData.

- live regions have the aria-live polite|assertive properties which roughly 
(though not really for all screen readers) map to queue vs flushing tts. Is 
there something equivalent for this api?

Yes! One of the goals for this API was to have more indicative properties to 
describe how notification behave. Currently, we have any combination of the 
following two properties (naming tbd):

  *   PlaceInQueue: (front | back | newest-only)
 *   front: place the notification in the front of the queue
 *   back: place the notification in the back of the queue
 *   newest-only: place the notification in the back of the queue, but also 
drop all existing notifications from the same element (good for progress bars, 
latest status, etc.)
  *   Interrupt: (true | false)
 *   true: if a notification is currently speaking and shares the same 
source as the one being queued, interrupt it and move to the next notification 
in the queue
 *   false: let the current notification speak to completion

- many screen readers actually suppress live regions (e.g. NVDA) or give users 
a way to turn them off. This api might reduce the ability for screen readers to 
do this depending on how it gets implemented.

Another good point! I think it makes sense that if live regions are suppressed, 
we would want this API to also be suppressed.

On non-Windows systems, since we will be hooking directly into the existing 
ARIA live regions implementation, we will share the same behavior as ARIA live 
regions (aka. suppress live regions => suppress JS API).

I'm not so sure in the Windows implementation, I'll do more research on how 
live regions are suppressed in screen readers.

- at least via the current proposed change, it looks like notify is trying hard 
to be a direct tts channel to the screen reader. It has very little to do with 
ARIA?

That is correct, but we decided to keep the ARIA-naming because many web 
authors associate accessibility with ARIA. Thus, this naming most succinctly 
expresses the intention of the API.

On Friday, January 28, 2022 at 4:26:36 PM UTC-8 Sara Tang wrote:
Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Hi Roberto, thanks for your feedback  Responses inline:


From: Roberto Clapis 
Sent: Tuesday, February 8, 2022 9:05 AM
To: blink-dev 
Cc: Roberto Clapis ; Sara Tang ; 
blin...@chromium.org ; Daniel Libby 
; yoav...@chromium.org 
Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation 
of Action API

There is one additional question that was brought forward during the discussion:

  *   What information can be read by the users of this API? This is mentioned 
in the security concerns but it doesn't seem to be specified elsewhere. Is this 
just about learning of an existence of a AT or is this some additional info?
  *   Here are some security concerns and possible mitigations. These are also 
re-iterated in the "Privacy and Security Considerations" section of the 
proposal:
  *   - readback: Do not readback AT configuration settings. Doing so makes the 
user an easier target for fingerprinting.
  *   - authoritative-sounding notifications: announcements can be crafted to 
deceive the user. We should suppress notifications when focus moves outside of 
the web content.
  *   - Maybe only offer this feature to Secure Contexts (instead of 3rd party 
browsing contexts)

On Tuesday, February 8, 2022 at 11:06:43 AM UTC+1 Roberto Clapis wrote:
Hi All,

During a discussion about this proposal a few concerns were raised:

  *   What pipeline of data would be used to pass the new messages to a 
potential screen-reader? Would screen-readers need to implement a new API or 
would this use pre-existing ones?
  *   A small nuance: screen-readers do not implement APIs, they consume ones 
that are exported by the Web Platform.
  *   - In the case of Windows systems, we use the UIA notifications API to 
pass information along to screen-readers.
  *   - In the case for other systems, we can hijack the existing ARIA live 
regions implemenation. In the case where the confirmation of action API is 
called without a DOM element/ARIA node, we can attach the announcement to an 
internal "root" node instead.
  *   Does this new API allow pages to have a more direct or a less restricted 
way to pass data to a screen reader?
  *   Less restrictive; possible restrictions we'll need to employ are listed 
in the next response.
  *   Would this API allow potential attackers to use different character sets 
or might this allow them to pass potentially malformed data to screen readers 
that was not possible to pass before?
  *   Here are some possible mitigations we have for this scenario:
  *   - Truncating strings, employing a max queue length
  *   - Restricting to alphanumeric input.
  *   - Running the announcement-text through a 
HTML-parser/DOM-parser/setInnerHtml or similar JS API

  *   If a pre-existing channel is used to communicate with the screen reader 
(e.g. already existing APIs) how would a user distinguish this new mechanism 
from content on the page?
  *   I don't think it's necessary for the user to distinguish between 
different screen-announcing APIs. Is there a particular scenario you are 
thinking of where a distinction would be needed?

Thanks in advance,
Rob



On Wednesday, February 2, 2022 at 1:05:58 AM UTC+1 Sara Tang wrote:
Good suggestion Yaov! I've opened one here: Review request for Confirmation of 
Action API · Issue #713 · w3ctag/design-reviews 
(github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F713=04%7C01%7CSara.Tang%40microsoft.com%7Cf431134001a745dcb4c208d9eb2540f4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637799369399593658%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=lsVh4SiL6qRcNXChcBKu%2FSd570FF65I6J%2BvkAWpWhA4%3D=0>

From: Yoav Weiss 
Sent: Monday, January 31, 2022 6:33 AM
To: Sara Tang 
Cc: blin...@chromium.org ; Daniel Libby 

Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of 
Action API



On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev 
 wrote:
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blin...@chromium.org 
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7Cf431134001a745dcb4c208d9eb2540f4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637799369399593658%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=lnxqPAw92p%2FOzBzVbk5qpZPUVQ%2FLxLSu8bbq1ZQHLY8%3D=0>

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessari

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Good suggestion Yaov! I've opened one here: Review request for Confirmation of 
Action API * Issue #713 * w3ctag/design-reviews 
(github.com)<https://github.com/w3ctag/design-reviews/issues/713>

From: Yoav Weiss 
Sent: Monday, January 31, 2022 6:33 AM
To: Sara Tang 
Cc: blink-dev@chromium.org ; Daniel Libby 

Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of 
Action API



On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blink-dev@chromium.org<mailto:blink-dev@chromium.org> 
mailto:blink-dev@chromium.org>>
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sart...@microsoft.com<mailto:sart...@microsoft.com>

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EAccessibility=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=LUDpXQ3U9jlBNAiZr9Wgvdj8%2FbkaO%2FqYAxea%2FRxaEuQ%3D=0>

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>

TAG review


Just wanted to note that it seems worthwhile to file for an early TAG review.


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive 
(https://github.com/w3c/aria/issues/832<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Faria%2Fissues%2F832=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=T4UsOOd8wCYCMZRGB8PtvhjwGbQYZXytYTBP6Q0LAaw%3D=0>)

Other signals:


Debuggability

TBD


Is this feature fully tested by 
web-platform-tests<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781367695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=%2BlpfYYe4ynJlQt4H5gxCYp%2FtW4Z%2FRW9hpWVHFaOzd%2BI%3D=0>?
No

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1291098=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781367695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=GrDlD2ouj7qXwiUHetoQU5N2Ksd7LlcZLr2ygxG%2B8iY%3D=0>

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform S

[blink-dev] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blink-dev@chromium.org 
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sart...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

TAG review


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/w3c/aria/issues/832)

Other signals:


Debuggability

TBD


Is this feature fully tested by 
web-platform-tests?
No

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5745430754230272

This intent message was generated by Chrome Platform 
Status.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB06809C5589E8FD6848CF5E09F2239%40CH2PR00MB0680.namprd00.prod.outlook.com.

[blink-dev] Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Contact emails
sart...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

TAG review


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/w3c/aria/issues/832)

Other signals:


Debuggability

TBD


Is this feature fully tested by 
web-platform-tests?
No

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5745430754230272

This intent message was generated by Chrome Platform 
Status.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0680B14C1978202FF59CF7D3F2239%40CH2PR00MB0680.namprd00.prod.outlook.com.

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: preserve-parent-color

['Sara Tang' via blink-dev]

Thanks Chris, I've filed a request for position here: preserve-parent-color 
value for forced-color-adjust CSS property · Issue #591 · 
mozilla/standards-positions 
(github.com)<https://github.com/mozilla/standards-positions/issues/591> and 
I've updated the ChromeStatus to reflect the change.

From: Chris Harrelson 
Sent: Thursday, November 4, 2021 12:33 PM
To: Fernando Serboncini 
Cc: Sara Tang ; blink-dev@chromium.org 
; Alison Maher ; Daniel 
Libby 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: 
preserve-parent-color



On Fri, Oct 29, 2021 at 1:13 PM Fernando Serboncini 
mailto:fs...@chromium.org>> wrote:

Great. It makes sense.

thank you :)

On Fri, Oct 29, 2021 at 4:11 PM Sara Tang 
mailto:sara.t...@microsoft.com>> wrote:
Hi Fernando,

This I2S does #3.

Thanks!
Sara

From: Fernando Serboncini mailto:fs...@chromium.org>>
Sent: Friday, October 29, 2021 8:21 AM
To: Sara Tang mailto:sara.t...@microsoft.com>>
Cc: blink-dev@chromium.org<mailto:blink-dev@chromium.org> 
mailto:blink-dev@chromium.org>>; Alison Maher 
mailto:alison.ma...@microsoft.com>>; Daniel Libby 
mailto:dli...@microsoft.com>>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: 
preserve-parent-color

Could you clarify if this I2S:
1. just adds the 'preserve-parent-color' value to forced-color-adjust and 
doesn't apply it anywhere by default.
2. adds it and changes the default value of forced-color-adjust to be 
"preserve-parent-color" on all SVG elements
3. adds it and changes the default value of forced-color-adjust to be 
"preserve-parent-color" only on the SVG root element (that then gets propagated 
down)

it seems that #3 was 
decided<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6310%23issuecomment-862517612=04%7C01%7CSara.Tang%40microsoft.com%7C62d286347825457df11408d99fc9f115%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637716512028514093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=QT1poDe5TrNYtJgf5etEq87HIDY1uwk8SR1vGdbfkEY%3D=0>
 on the 
CSSWG<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6310%23issuecomment-862517612=04%7C01%7CSara.Tang%40microsoft.com%7C62d286347825457df11408d99fc9f115%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637716512028524050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=7JGgSyqt9IHbD0t5XbOCFBf8r9T7tPI3XzRLT4QUmU8%3D=0>,
 but your summary and crbug's CL looks more like #1, while your motivation 
seems like #2.


On Thu, Oct 28, 2021 at 5:45 PM 'Sara Tang' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Contact emails
sart...@microsoft.com<mailto:sart...@microsoft.com>, 
alison.ma...@microsoft.com<mailto:alison.ma...@microsoft.com>

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FAccessibility%2FPreserveParentColor%2Fexplainer.md=04%7C01%7CSara.Tang%40microsoft.com%7C62d286347825457df11408d99fc9f115%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637716512028524050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=wLDalF154UJpXmGbWqvaAn0c1O5uo8xlgLcEGEvQHaM%3D=0>

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-color-adjust-1%2F%23forced-color-adjust-prop=04%7C01%7CSara.Tang%40microsoft.com%7C62d286347825457df11408d99fc9f115%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637716512028534007%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=LwA5QtYzsEN9Bt7DApE8o1UmQ3yP2Z%2BWQkJavM8KGNM%3D=0>

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Contact emails
sart...@microsoft.com<mailto:sart...@microsoft.com>, 
alison.ma...@microsoft.com<mailto:alison.ma...@microsoft.com>

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FAccessibility%2FPreserveParentColor%2Fexplainer.md=04%7C01%7CSar

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: preserve-parent-color

['Sara Tang' via blink-dev]

Hi Fernando,

This I2S does #3.

Thanks!
Sara

From: Fernando Serboncini 
Sent: Friday, October 29, 2021 8:21 AM
To: Sara Tang 
Cc: blink-dev@chromium.org ; Alison Maher 
; Daniel Libby 
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: forced-color-adjust: 
preserve-parent-color

Could you clarify if this I2S:
1. just adds the 'preserve-parent-color' value to forced-color-adjust and 
doesn't apply it anywhere by default.
2. adds it and changes the default value of forced-color-adjust to be 
"preserve-parent-color" on all SVG elements
3. adds it and changes the default value of forced-color-adjust to be 
"preserve-parent-color" only on the SVG root element (that then gets propagated 
down)

it seems that #3 was 
decided<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6310%23issuecomment-862517612=04%7C01%7CSara.Tang%40microsoft.com%7Cafe9d7d59d5d4f31cb2108d99aefdd45%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637711177339738955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=DU66ohWIfaMOCWEffOH%2FZnWTEmITV7ZaSmeWT%2BmZIcY%3D=0>
 on the 
CSSWG<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6310%23issuecomment-862517612=04%7C01%7CSara.Tang%40microsoft.com%7Cafe9d7d59d5d4f31cb2108d99aefdd45%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637711177339748916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=KS9HCv0cUqSOVfnn%2FPoGxNwQNv5S1hztDwF%2FVSvUmyI%3D=0>,
 but your summary and crbug's CL looks more like #1, while your motivation 
seems like #2.


On Thu, Oct 28, 2021 at 5:45 PM 'Sara Tang' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Contact emails
sart...@microsoft.com<mailto:sart...@microsoft.com>, 
alison.ma...@microsoft.com<mailto:alison.ma...@microsoft.com>

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FAccessibility%2FPreserveParentColor%2Fexplainer.md=04%7C01%7CSara.Tang%40microsoft.com%7Cafe9d7d59d5d4f31cb2108d99aefdd45%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637711177339748916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=DWthG7wyL%2BhzWXHdx4oQs2PNg49AhRoV0vXyNz5gXAk%3D=0>

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-color-adjust-1%2F%23forced-color-adjust-prop=04%7C01%7CSara.Tang%40microsoft.com%7Cafe9d7d59d5d4f31cb2108d99aefdd45%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637711177339758868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=20lJLa8c%2BxRDoldBHmd8Zro%2F%2FYtqwK%2BI%2BYwne0ES6Y8%3D=0>

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Contact emails
sart...@microsoft.com<mailto:sart...@microsoft.com>, 
alison.ma...@microsoft.com<mailto:alison.ma...@microsoft.com>

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FAccessibility%2FPreserveParentColor%2Fexplainer.md=04%7C01%7CSara.Tang%40microsoft.com%7Cafe9d7d59d5d4f31cb2108d99aefdd45%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637711177339768823%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=aRu0keSh5Rgj%2BVTIFQ9%2BLXLuWr0bdGWAgxk3niZPKkw%3D=0>

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-color-adjust-1%2F%23forced-color-adjust-prop=04%7C01%7CSara.Tang%40microsoft.com%7Cafe9d7d59d5d4f31cb2108d99aefdd45%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637711177339778777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=2BCGuB1g2yK%2BwFjvlbRmHrZK4VjbnpOn6wlAOWsbFW8%3D=0>

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ p

[blink-dev] Intent to Ship: forced-color-adjust: preserve-parent-color

['Sara Tang' via blink-dev]

Contact emails
sart...@microsoft.com, 
alison.ma...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Contact emails
sart...@microsoft.com, 
alison.ma...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Motivation

‘forced-color-adjust' is a CSS property that allows developers to opt out of 
Forced Colors Mode.

Previously, there were two supported values: ‘auto’ and ‘none’, which can be 
used to control whether or not an element’s styles are adjusted by the UA in 
Forced Colors Mode. A third value, ‘preserve-parent-color', has recently been 
introduced in the spec, which provides similar behavior to ‘none’, except that 
it also allows an element to inherit its parent's used ‘color’ value. In other 
words, ‘preserve-parent-color' provides the ability for an element to inherit 
its parent’s Forced Colors Mode adjusted ‘color’ value.

The intention of ‘preserve-parent-color’ is to get a reasonable behavior for 
SVG icons that utilize ‘currentColor’ when styling ‘fill’ and ‘stroke’ in 
Forced Colors Mode, as described in [css-color-adjust-1] Spec currently breaks 
use of currentColor for SVG icons in WHCM · Issue #6310 · w3c/csswg-drafts · 
GitHub.

The use of ‘currentColor’ when styling an SVG icon is a common pattern used by 
authors to ensure an accessible experience in Forced Colors Mode. For example, 
in this sample logo, an author 
would expect the logo to automatically adjust to use the ‘CanvasText’ system 
color for ‘fill’ and ‘stroke’ in Forced Colors Mode, as a result of setting 
each to ‘currentColor’.

This behavior, however, became broken when we moved from forcing colors at 
computed value time to used value time: [css-color-adjust-1] Is forced color 
computed or used value? · Issue #4915 · w3c/csswg-drafts · 
GitHub. Instead of inheriting 
‘CanvasText’, as before, the above sample 
logo would inherit the computed 
‘color’ value of its parent, resulting in a logo that is no longer readable in 
Forced Colors Mode.

The new ‘preserve-parent-color' value was added to address this common SVG use 
case. By changing the default value of ‘forced-color-adjust’ for SVGs from 
‘none’ to ‘preserve-parent-color', SVG icons that make use of ‘currentColor’ 
will now inherit the used ‘color’ value of its parent, as expected.

It is important to note that this may break SVGs that expect the opposite 
inheritance behavior for the ‘color’ property. However, the behavior of 
`preserve-parent-color` handles the most common SVG use cases, and the behavior 
better matches legacy implementations of High Contrast Mode.

Blink component
Blink>CSS

Search tags
css, 
forced, 
colors, 
forced-colors, 
forced-color-adjust,
 
preserve-parent-color

TAG review
https://github.com/w3ctag/design-reviews/issues/681

TAG review status
Issues open

Risks


Interoperability and Compatibility

Interoperability Risks Gecko has shipped a version of Forced Colors Mode 
without support for ‘forced-color-adjust’. Although there is an open bug for 
adding support (https://bugzilla.mozilla.org/show_bug.cgi?id=1591210), 
development has not been started yet. Compatibility Risks We are updating the