Two bug-fixes for forced-color mode

[SebinSong]

closes #2385
closes #2440

[Fix 1]

[Fix 2]

[cypress]

group-income    Run #3493

Run Properties:   Passed #3493  •  88915fd1ff ℹ️: Merge 013f37796f5caceabebd8983a0050bf43f70ed4a into 5f68446576179fd93a5428ebfba3...

Project	group-income
Branch Review	sebin/task/#2385-image-viewer-in-forced-color-mode
Run status	Passed #3493
Run duration	08m 50s
Commit	88915fd1ff ℹ️: Merge 013f37796f5caceabebd8983a0050bf43f70ed4a into 5f68446576179fd93a5428ebfba3...
Committer	Sebin Song
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	10
Skipped	0
Passing	111
View all changes introduced in this branch ↗︎

[corrideat]

This looks good, but I have an issue with this part:

I observed most elements that involve user interactions are rendered with white color when 'forced-color' mode is turned on. So made fixes using $white sass variable we have in the source-code.

That's not entirely accurate. See https://developer.mozilla.org/en-US/docs/Web/CSS/@media/forced-colors. In particular (emphasis mine):

Note: User agents choose system colors based on native element semantics, not on added ARIA roles. As an example, adding role="button" to a div will not cause an element's color to be forced to ButtonText

There are two cases where the user agent does not force the values for the above properties — when a forced-color-adjust value of none is applied to an element, or when a system color is specified by the author.

So, instead of using $white or any arbitrary colour, I'd use a system colour instead.

[SebinSong]

@corrideat Those articles are informative actually. Updated the $white to system-color.

[taoeffect]

Nicely done @SebinSong!