Greg Whitworth

How to use -ms-high-contrast

2017-05-04T00:00:00Z

NOTE: This content is now outdated, I recommend referencing Microsoft Edge's blog post about the standardized solution

This post is in response to Patrick H. Lauke's post titled, Windows High Contrast Mode: the limited utility of -ms-high-contrast. Since this is a response post, I recommend reading his first and then come back to read this, I'll wait.

I mentioned in the twitter thread that I'd try to find some time to blog about this to help clarify how it works since it wasn't mentioned in his post, well I finally found some time.

Why the media query exists

The high contrast feature within Windows is designed to help people with contrast sensitivity issues. The colors are propagated from Windows High Contrast into the site's style to ensure that the site is offering a true high-contrast experience similar to other applications on Windows.

This is different from other browsers where they do graphic modifications to the site such as color inversion. For example, here is Google Chrome with High Contrast enabled compared to Edge with Windows High Contrast on the same site:

Chrome in high contrast

Edge in high contrast

This route is beneficial for another reason, since we are modifying the styles this allows us to offer control back to the web developer via the -ms-high-contrast media query so they can further improve the experience for their users.

It's about UX, not design

A common misconception that I've seen often with this media query is that people want to be able to make site changes by knowing which colors were selected by the user.

While the feature has to do with color modifications it's sole purpose is to aid in providing users with contrast sensitivity a better experience. As such, you shouldn't necessarily care about what the specific color is. To some extent, you shouldn't even care how your site looks; but how it functions in high contrast.

Note: I am not a designer, and I'm sure some designers will read this and inform me that UX is a part of design. That's fine, but for the scope of this article please allow me to stretch the definition of design to be separate from UX.

To make this easier we mapped the Windows High Contrast colors to CSS system color keywords so you can utilize the specified colors without needing to know them.

Text is mapped to windowText
Hyperlinks is mapped to N/A, we apply the color to <a>
Selected Text is mapped to highlightText & highlight
Button Text is mapped to buttonFace
Background is mapped to window

Here's a screenshot of the Window High Contrast options as it will make the above more clear:

The high contrast color settings for High Contrast Black

There are three values for the media query, active, white-on-black, and black-on-white.

Here is basic usage of the media query.

@media screen and (-ms-high-contrast: active) {
    /* All high contrast styling rules */
}
@media screen and (-ms-high-contrast: black-on-white) {
    /* Rules for users using black-on-white */
}
@media screen and (-ms-high-contrast: white-on-black) {
    /* Rules for users using white-on-black */
}

Enough background - let's get practical

All of the above is a good primer, so let's take a look at some practical examples and how to utilize the media query to achieve great results for your users. All of the examples below are based on real sites I've seen break when in high contrast mode, so if you're doing the below - please update your site.

Note: for simplicity purposes, in each of these demos I'm only showing the final state that causes a broken behavior and how to fix it, not a fully functional implementation of said solution

Custom checkbox images

This is a common scenario I've seen. You want to provide your users with consistent graphics for checkboxes or you just don't like the look of the browser provided ones. So you hide the checkbox and provide your own. Here is an example of this without high contrast enabled.

See the Pen custom checkbox without -ms-high-contrast by gregwhitworth (@gregwhitworth) on CodePen.

Now if I turn on white-on-black high contrast, let's see how this experience changes:

The checkmark completely disappears due to its alpha transparency and the background being switched to black provide high contrast in other areas. The image itself is still there, but there is no way to see this. So, what can we do to fix this. Well, there are two options:

Create a high contrast icon to begin with
Switch out the background image using the -ms-high-contrast media query

Create a high contrast icon to begin with

This should be considered best practice in my opinion, any icon that you're creating should have high contrast. There are numerous tools to help you ensure that the colors you're using meet the guidelines produced by WICAG for high contrast. I usually use the WebAIM Color Contrast Checker but there are many great ones to use. So let's assume that the checkmark has to be black to match the rest of our site, we can ensure high contrast by including the background with the image.

Yes, it isn't the best design, but that's not the point. The user can now see all of the content that a person without contrast sensitivity can. If you're able to design a style guide for your site that takes into account high contrast, you could make the checkmark stand out even more by making it green. Again, the goal here is functionality, not form.

Using system colors for dynamic color propagation

Rather than building up numerous images, one can utilize the mappings I referred to above. Let's take a look at a poorly executed SVG chart, first the intended look for people that don't have contrast sensitivity.

See the Pen SVG chart without high-contrast solution by gregwhitworth (@gregwhitworth) on CodePen.

We could improve this for our contrast sensitive users by adding the following:

@media screen and (-ms-high-contrast: active) {
    .axis,
    .bar {
        stroke: windowText;
    }

    .box {
        fill: window;
    }

    .bar {
        fill: highlight;
    }
}

Here is the result in both the White and Black high contrast modes:

There is more that could be done here to further improve this chart, but I think you get the point.

Takeaways

Like so many things on the web a lot can be done for all users that also results in aiding users that have contrast sensitivity issues. Here is an excellent talk by Aaron Gustafson about Inclusive Design which covers this.

High contrast tips:

Try to make icons high contrast from the beginning for everyone, if you can't utilize -ms-high-contrast: active to provide high contrast versions
If you have alpha transparency, use -ms-high-contrast to add in a background to ensure high contrast
Utilize the system color variables in order to utilize the colors selected by the user to provide a great high contrast experience in any scenario that takes CSS colors.

If you have feedback on this post, feel free to contact me on twitter

Accurately checking for CSS Grid support in Microsoft Edge

2017-05-10T00:00:00Z

Edge is updating it's implementation of CSS Grid. YAY! I was thrilled to fire up a test build and take it for a spin and check out a few of the most common CSS Grid demos as a good first pass at real life scenarios.

Then I hopped over to a great repo set up by Rachel Andrew that shows live sites using CSS Grid.

I discovered something unfortunate while looking at Bryan Robinson's awesome portfolio site. It didn't look like a grid layout. I then check his site in Firefox, and bam, - it looks great. Something was up.

Image of Bryan Robinson's site without grid

Looking at the code I see this:

@supports(display: grid) and (not(display: -ms-grid)) {
    /* grid code here */
}

While I get the purpose of this, IE's implementation of grid is not a direct 1:1 of the standardized CSS Grid. Unfortunately this makes it so that Edge will NOT go into this support block at all, because we will support both display: grid and display: -ms-grid when Edge ships.

The solution, just display: grid

So to make this work, we don't want to focus on -ms-grid at all, but harness the power of any of the other standard approach such as display: grid or any other grid-template-* properties added to the spec. For example:

@supports(display: grid) {
    /* will return true for any browser supporting the spec */
}

Bryan was awesome and updated his site about five minutes after we spoke on twitter and it now looks great.

Image of Bryan Robinson's site with accurate grid support check

What's Grid?

Just in case you read this whole post and don't know what CSS Grid is and what all the hype is about. Learn more about this awesome layout capability coming to a browser near you.

Update

In an earlier version of this post, I theorized why such a feature query was being used, as possibly related to a bug with @supports in an Insiders build of Edge 15 (eg: our Canary builds). This bug did not ship to stable, so I have updated the content to be the simpler more sane approach. Basically, don't include -ms-grid checks.

Freedom in exceptions

2018-08-05T00:00:00Z

The subtle clack of the keys joins the chorus of beeps and whirs of medical devices in my daughter's hospital room. She was diagnosed with brain cancer in January and quickly had two tumors removed. We're now over half way through her chemo treatments, and we're all getting used to this as our current reality.

One evening my wife and I were talking about some scenarios that we had encountered through this process that could be improved through technology. Working at Microsoft, this is a common past-time for my wife and I as we flush out various ideas to different depths. Some are more viable than others, but this one - it didn't matter about its viability; it offered me something else -- an opportunity.

So I began coding.

I never noticed it before; maybe due to apathy or preferring to look at the success of overcoming a problem rather than the problems themselves, but there is a beauty; I'd maybe even go so far as saying a freedom in the exceptions. I'm sure many of us became hooked to programming when building out our first "Hello World" scenario.

Each of us have our moments of frustration, struggle and humility wrought by these exceptions. But I find it remarkable how I can still achieve that same rush of accomplishment as I cross off another hurdle to a clear console. It doesn't matter how often I do it, each time that I get an opportunity to learn something new, face the challenges and overcome them - that rush returns. "I did it." Working in web tech this is a common scenario as the tech is ever evolving at an amazing rate. When building out a prototype for this solution I used this as an opportunity to learn Vue (it's all the rage right now) and I enjoyed various moments of "ahaa".

I loved being able to explore a world where problems existed that I can solve. In a season of life where it feels like I have absolutely no control, and am met with fears that I don't have any desire to confront; I find freedom in the exceptions that rendered in my dev tools. Even though they are remarkably un-important in the grand scheme of things, it gave me a sense of control.

So if you're banging you're head against a problem today, remember your "Hello World" moment. You've been here before, you've got this, and to find the freedom and joy that the solution will produce.

Please share you're most recent victory, or ahaa moment on twitter

Blessed by your love

2018-08-20T00:00:00Z

Dear Karen,

I can see it my mind's eye like it was yesterday; we're both walking along railroad ties in our church parking lot like they're tight ropes and talking. I said something that makes you laugh and you look back over your shoulder and that warm summer glow dances through your hair and illuminates the smile that continues to take my breath away.

Like many young couples, we primarily talked and planned for the joyful milestones we might share together. We talked about visiting Hawaii, which we would do a few years after our marriage thanks to your loving Nana & Papa which would spark a tradition of scrounging money; and initially you trading your art for places to stay on any island we could. So many wonderful memories for our family are bathed in the sun and sand of those islands; and encourage our wanderlust spirit.

We talked about children, and how we felt two is the perfect number. You had more practical reasons, but I still stand by the fact that most vacation competitions are for a family of four, not more (still hopeful on this one panning out). In 2006 we would welcome our first, Rachel into the world and she would change our world in many ways. I recall sitting in the back of your parent's SUV singing to her as she screamed because she believe that Kenai is too far from Wasilla (I tend to agree with her). Then sitting in the kitchen of our new home while Rachel, at the time - two years of age, sat defiantly telling you that she will not say she's sorry to you for being bad. We laughed about her stubbornness after the standoff came to a close and she was in bed.

Then Matt came into our life, a sweet, sympathetic and joyful little boy. One that was all to eager to get into trouble with an older sister that was more than happy to come up with creative solutions and allow him to take the fall. These two were inseparable and quickly became each other's best friends.

As our family and careers grew, we were ready for more and we increasingly ready to leave Alaska. One March we visited Lake Oswego, Oregon where your Nana and Papa live for vacation. We took a walk around the neighborhood and relished in what it might like to live in a community like this and feel 70 degree weather in early spring rather than having to wait for summer. A few years later I would be on the phone with an employee from Microsoft and he asked, "Are you willing to relocate?" With absolutely no hesitation I stated emphatically, "Yes."

Greg and Karen posing in front of the pond at Monet's garden in Giverny, France

Our journey to the lower 48 began and excitement filled the tiny 800 square foot apartment for opportunities to come. We began to talk about what retirement should look like for us and things we long to do together while on this earth. We quickly listed out most of the hot spots in Europe. We've been truly blessed in that the team I joined at Microsoft just so happens to join W3C standards meetings in Europe at least once a year. You would tag along for some of them, and while I was in the meetings you would be out seeing some of the sites. We would meet up in the evening and enjoy the culture and friends. So many great memories that further unlocked our desire to travel and we've been able to see some our dreams for our fifties occur in our thirties.

In January of 2018 Rachel was diagnosed with brain cancer

Then came 2018, a year that embodies the harsh realities that no one ever thinks of when they say their vows; although we all know there is a possibility of unfortunate events occurring. Karen, you have stepped up in a big way, and honestly I wouldn't expect anything different. You're remarkably selfless, confident and strong. I don't wish the year we've had on anyone but I also know that I hope that anyone that has to walk this road has someone beside them like you. You've shown a patience and love, not only to Rachel but to the entire family that I will continue to strive and match. You're incredible and no words that I type can do you justice.

I fell in love with a woman that is beautiful, strong, creative and confident and when we said, "I do", I had no idea how much I would appreciate those qualities as I have this year.

While this year doesn't feel quite like the others, it has shown how blessed by your love I am - possibly more so than any other year. With you, the Lord we can get through this.

I love you,

Greg

What do you think about the ResizeObserver entry object?

2019-02-23T00:00:00Z

What is Resize Observer?

ResizeObserver is built on top of the same functionality of MutationObserver that allows you to attach a callback event to an element. When an element's layout content box changes in size the callback that you registered with the observer is called and it gets passed an entry object which has the layout information about the content box. This is a very useful API to use if you’re ever wanting to make any style or content changes based on the dimensions of the box even if the viewport doesn’t change (a.k.a container queries).

Learn more about how to use ResizeObserver on MDN

ResizeObserver also has the performance benefit that it passes you the layout information of the box so that you aren’t flushing the rendering pipeline in order to get these same dimensions since callback is called following layout and this information is already available.

What should the entry object structure be?

Aleks Totic and I are making some changes to ResizeObserver based on feedback we’ve already received from web developers, some of these improvements are being able to select which box you wish to observe, such as the border-box, content-box or scroll-box.

What we would like feedback from you on is this. When the observer for observing the border-box is triggered and the browser passes in the entry object to your callback would you prefer Option A or Option B.

Option A

    entry = {
        target: Element,
        contentRect: {/* v1 for back compat */},
        inline: 400,
        block: 400
    }

Option B

    entry = {
        target: Element,
        contentRect: {/* v1 for back compat */},
        contentBox: null,
        borderBox: {
            inline: 400,
            block: 400
        },
        scrollBox: null
    }

Vote now!

There are two ways to vote, you can vote in the YouTube video embedded above by clicking the 'i' in the top right hand corner, or you can vote via Office forms here.

Initial thoughts on standardizing form controls

2019-07-15T00:00:00Z

While the move to Chromium is bitter sweet for me, one of the things that has me excited is being able to take some of the time that the team has spent devoting to compat and investing it in trying to address the many pain points that we’ve heard through the years.

One area that we’re beginning to investigate is the problem of form controls and components built into the browser. Initially, we started at a very high level by doing an opportunity analysis of the various buckets of work we could consider addressing in this space; all with varying levels of necessary investment. Ultimately, they all came back with an indicator that there was substantial opportunity for web developers, designers and end users if the problem is solved correctly. In addition, it revealed a few core pillars that I feel must exist for the work done in this space to solve the pain points web developers and designers currently face when working with the built in form controls.

Web developers need complete control over the appearance
Extensibility needs to be possible
State management across component(s), including composite components
Expectation from developers is that the controls "just work"
Accessibility, performance, focus and other foundational items work as expected

Ok, so now that we have a quick overview of the expected key pillars, let’s dig into a few of them in a little bit more detail with some of the data that lead us to making these key pillars.

Complete control over the appearance

In many of the currently shipping controls and components there are a set of CSS properties that developers can apply to aspects of control. This is one of the major pain points presented, some of the top offenders being <select>, <input type="file"> and <input type="date"/>. Additionally, there currently is no way in which to extend the control if the developer desires to. A good example of this is the <video> element where the developer either gets all of the controls or none of them by adding or removing the controls attribute. Because of this, many developers are left recreating all of the functionality already provided even though they may have only desired to make a small content adjustment, like adding an additional button next to the play/pause button.

While there is a desire for more native controls in the browser (more on this later), adding them does no good if the web developers and designers can’t adjust them to meet the needs of their site's design or user experience.

I sent out a survey on twitter to understand this problem space a bit more. With close to 1,400 unique respondants it helped reveal why this area is such a pain point for web developers & designers.

Let's take a quick look at some of the results (view the full results here).

Within the survey we asked if they have ever used a library or created their own version of controls, and if they did which controls did they create? Here are the top 10:

This list isn’t surprising if you’ve been in the web development community for a while. But simply requesting which ones were created doesn’t necessarily inform us why they reached for a library or created their own, so we then asked, “What were the top two reasons that you needed to create or use a custom control?”

In addition to Microsoft, Bocoup and Google have been actively investigating this space so when Simon Pieters of Bocoup reached out, having seen my survey, we decided to collaborate on a survey that was presented to attendees of JS/CSS Conf EU. It had the same questions overall but it included two new questions. “Which form control gives you the most frustration”:

And while this is only a slight pivot to what could be inferred from the earlier question it shines a strong light on the most problematic controls.

In addition to this, we asked "Why does that form control give you the most frustration?" (bolded quotes were more commonly stated by respondants but phrased differently):

“Requires hacky tricks”
“Can’t style <option> elements at all to the extent we need to”
“Too little control over styling across popular browsers”
"I’m generally ok with default rendering of form components and the amount that web fonts, etc can be used. But select menus are a major outlier and just sort of stink”
“Label “select a file” and file name are hard to customise.”
“Styling implementation for Select is inconsistent between browsers. Not all styling properties apply to the control.”
“…but the amount of work it takes to implement an accessible alternative with complete feature parity is massive”

Browser consistency

In order to achieve the capability of control over the appearance; we also need to ensure that browser vendors align as much as possible on the sub-parts available to web developers. A good example of how this can be problematic is <input type="file"/>. Here is what it currently looks like in Edge (EdgeHTML), Firefox, Chrome and Safari:

Chrome:

Edge (EdgeHTML):

Firefox:

Safari (MacOS):

These types of browser inconsistencies wouldn’t be such a huge deal if the form parts were agreed upon and reachable by web developers. Unfortunately, the majority of form controls aren’t standardized, which requires web developers to go to great lengths to work around these shortcomings. Here is one example blog post detailing ways to work around the file form control. Similiar "hacks" can be seen on many major sites such as Facebook and Twitter.

Why is this a necessary pillar?

Browser inconsistencies can lead to negative end user experiences and browser engineers often have an unrealistic expectation of web developers to open every browser and test it thoroughly. This has long been known to be a large request, especially for smaller shops. In order to try to put a quantitative number to qualitative assessment we asked, “Which browsers do you actively test during the development phase?”

This is not necessarily surprising to me given my history on the Microsoft Edge team, but it was kind of surprising how few Safari testers there were. I can only speculate at this point, but I think this has to do with the thought that Chrome is derived from Webkit, as is Safari and thus interoperability is not an issue. Where as Microsoft’s browsers have an infamous reputation of causing web developer pain through interop issues even if Microsoft Edge made huge strides in this regard.

An additional point to Safari’s lower testing can be due to developer access to testing Safari since it’s only available on Mac. We asked, “Which operating system do you primarily develop on?”

This can have a negative impact on our shared users

As we’ve seen in the results above, web developers have an ever-increasing testing matrix of operating systems and browsers. This can result in a negative impact on the end user which is bad for browser vendors, web developers and the companies that employ them to build their site.

To this end, I was curious about a key aspect of the end user experience, accessibility. Since the accessibilty team has spent so much time over the past few years improving accessibility in Microsoft Edge and now in Chromium, how many web developers take advantage of this investment and great work?

To understand this, we asked, “Do you do accessibility testing?”

Then, of the respondants that selected they do accessibility testing, we asked what type of accessibility testing they do:

Then, if they are doing assistive technology (AT) testing we asked which ATs they test with:

So we only have ~40% of web developers (that were willing to answer) doing any type of accessibility testing, and of those users only 27% doing any type of AT testing. This undoubtedly leads to broken user experiences and we have only begun to scratch the surface in this regard.

Standardize in-page controls

My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.

Note: regarding external controls/components: There are very valid reasons that operating systems can not standardize the external “windowed” controls, such as the keyboard flyouts, file explorers as these need to remain consistent across any application and there may be scenarios when the company is developing a new form factor that they require a new paradigm for input (eg: iPhone or HoloLens).

Reduce throw away work while increasing usability

As seen above, very few web developers have the time to put in the effort to do complete performance, accessibility and compat testing. Whereas the browser vendors, in many cases, are spending their time doing this work. This is something I'm acutely aware of since that’s what we’re actively doing within the Chromium codebase to match our Fluent Design System for the new Microsoft Edge built on top of Chromium.

As such, we want our users to have this experience while enabling web developers to benefit from this time spent by allow them to extend and style these controls; not throw them away to produce their own. Although I realize, give the current state of form controls, web developers are often stuck between a rock and hard place. This will not only improve the end user experience but also improve the developer experience and expense cost for the web development firms. In order to try and solve this problem, we should...

Introduce new form controls and components

Since we are aware of web developers needing to create their own controls, we figured we’d take this time to ask which form controls or enhancements they’d like added to the platform. We didn’t provide an exhaustive list but put in some of the top requests we’ve heard over the years, each respondent could select their top 3:

Top requests under "Other" were:

Tooltips
Context menu
A fully functional dialog

Introduce new APIs to avoid hacky work arounds

As we’ve been looking into this, and as I’ve tried to show above, there will be scenarios in which the web platform is simply missing solutions or APIs necessary to unlock the creativity that web developers and designers hope to accomplish with their controls. Also, as we saw above and during the opportunity analysis, the web community wants to simplify the effort necessary to build the controls they need.

Take the <select> control as one example, without digging too deeply into it yet - we currently don't have:

a way in which to have a popup that we can ensure to be on top of all content and break out of overflow: hidden
have the popup open in the direction that has more space within the viewport

The Google Chrome team has been actively looking into this space as well, by utilizing built in modules, and they have introduced a proposal for a toggle/switch (WICG Thread) and have begun work on a virtual scroller component as well. In addition, they have an issue open for researching the "top layer" issue noted above open.

First steps regarding this work

More research into select & file

My initial thinking on this, and steps we’ll hopefully be taking soon for this is to take the <select> and <input type="file"> controls and dig deeper into them. We will use the above information as our north star to guide the implementations to ensure we're solving the problems outlined by the developers. We will be doing this work within this WICG Repo and as we discover APIs we'll take them to the appropriate working groups with the elements ultimatley living in the HTML specification.

Component libraries

We've also begun talking with many of the component libraries and frameworks, spefically about this work to understand what they would like to see from this and to learn from them due to their vast experience in this space. Some of the ones we've begun speaking with are:

Fast DNA
Fabric
Polymer
Ionic
Ember

If you work on a component library or framework and are interested in talking, contact me on twitter (my DMs are open).

Stay tuned & get involved

Hopefully this is clear based on the data and the resulting post, that I want to ensure that what is built enables developers and designers to create enriching experiences without having to re-create the wheel. I'm very eager to hear from you and I know many from other browser vendors and members in the standards community are too.

If you're interested in getting involved and keeping up with the progress, follow me on twitter (I commonly send out surveys and short info there), star the Standardized Controls & Components Repo, and provide feedback to Google on their toggle/switch proposal.

That's all for now - thanks for reading and I look forward to a day where we can fully style a <select> control (can you imagine?!)!

Click here to view the full survey results

Working with the text backplate in Windows High Contrast

2019-08-05T00:00:00Z

I've written in the past about how to adjust your site to provide a useful experience to users that turn on Windows High Contrast (if you haven't read about it, jump over here to read it and then come back).

Some background

An issue was brought to my attention recently Adrian Roselli where he asked, "... am unable to get Edge to properly do text in button on focus/hover when inverting values as it seems to think it conflicts with background and is putting bar behind it. Typo? Help?."

Before I get into how to fix this issue, I'm going to quickly outline why this issue is exists in the first place. In the 2016 Spring Release of Microsoft Edge, a change was made in high-contrast mode where a blackplate was added behind text nodes to ensure contrast. Bogdan Brinza & Rossen Atanassov of the Microsoft Edge team stated the reasoning for this was, "Many modern web sites use background images as foreground content, which doesn’t provide a great experience for users who need increased contrast."

Here is an example of this issue seen in the Microsoft Edge browser with high-contrast enabled:

So the Xbox site is using the background image to convey context that Halo is one of the best xbox games. In order to achieve contrast however, Edge replaces background images and fills in the background of every container with the user's selected colors in the OS settings. This ensures high-contrast, but the user has a degraded experience over all in relation to non-high-contrast users.

To solve this, the team did something pretty creative by taking a common paradigm seen in another medium where the background content is dynamic, video media. What they did was allow the background images to be rendered and inserted a backplate behind all of the text nodes that achieves the desired end result.

Here is what that same site looks like with these adjustments:

The problem

Now back to Adrian's problem from earlier. Adrian has a <button> that he has a nice little :hover effect on where the background and text color change. Here's what it looks like:

Now, let's take a look at this same scenario with Windows high-contrast turned on:

As you see the backplate actually ruins the high-contrast that Adrian was hoping to achieve. This happens, ironically because Adrian is being responsible and adjusting the web content for high-contrast:

@media screen and (-ms-high-contrast: active) {
  button {
    -ms-high-contrast-adjust: none;
    color: buttonText;
    background-color: buttonFace;
    border: 3px solid windowText;
  }
  button:hover,
  button:focus {
    color: buttonFace;
    background-color: buttonText;
    border: 3px solid windowText;
  }
}

The solution

So in order to solve this, all you need to do is add -ms-high-contrast-adjust: none;(MDN docs) to the button selector. This tells the browser, "I've got this, I know what I'm doing and I'll handle all of the high contrast." So the browser then doesn't touch that content leaving you in control of how high-contrast is handled. So now that -ms-high-contrast-adjust has been added, let's take another look:

That's all there is to it. Happy coding!