Windows
Windows
Creating accessible products means most of all being aware of the usability issues your designs and code can cause. When creating new products, Microsoft follows a strict workflow of accessibility reviews of designs, code reviews and mandatory audits before a new feature can leave experimental stage. Microsoft Edge is no exception. Even if users spend most of their time interacting with the web content itself (which the browser can’t really do anything about) they also interact with menus, options, settings pages and more that are part of Edge. These parts of the browser need to be accessible to you whether you use a mouse or a keyboard, or whether you rely on a screen reader to interact with your computer. The Edge Developer Tools are part of the browser, and as such, need to comply with the same accessibility guidelines. This includes new features but also legacy features that have been around for years in the Chromium codebase. In order to make time to fix issues, we have so-called bug sprints, where we focus two weeks on fixing broken issues rather than adding new functionality. We just finished a bug sprint focused on accessibility issues and today we want to share how we fixed a problem that has been around for a long time. DevTools has a fairly complicated user interface, and it uses a lot of different colors, to make differences in content more obvious. One example of which is the :
This menu lists commands that match what the user types in the input field. Every command has an associated category which is represented by a colored badge displayed next to it. This badge also contains the category name so we’re not relying solely on the color, which would be an accessibility barrier for people with low vision or color vision deficiencies.
That said, we’re not quite out of the woods yet. The bug and its fix we would like to describe here is related to the fact that some of the badges didn’t have sufficient contrast between their background and text colors.
The screenshot below shows that the “Resources” badge has a very low color contrast ratio (1.511:1). The say that, at a minimum, the contrast ratio needs to be 4.5:1 for users with low vision to be able to read the text. According to the , there is an estimated 246 million people worldwide who have low vision. Among them might be a lot of potential DevTools users who would have missed out on those badges if we hadn’t fixed that bug. In addition to that, making these more readable is what everyone can benefit from.
This worked great, but it also meant we needed to hover over each and every badge, one at a time, in order to check for contrast. So we tried a second technique.
.badge.low-contrast::before {
content: attr(data-contrast);
position: absolute;
background: red;
color: white;
/* ... */
}
Setting up
The Resources badge wasn’t the only badge with low contrast, and in total there are 17 different badges. We needed to find all the contrast issues and – if needed – . One thing not a lot of people know is that you can ! This means you can open DevTools, undock them and open a second instance of DevTools that targets the first one. From that second instance, we can inspect the badges and make color changes like you would change any other color on a web page. Lately, we’ve improved our development environment to make this quite fast, but it was still going slow and repetitive work. We had many colors to change, and every time we would make a change to the source code, we’d have to rebuild and reload DevTools, re-open the command menu, and test the contrast. We needed a way to look at all badges all at once in order to make the necessary adjustments instead of testing them one by one. To do this, we created an HTML document that contained all the possible badges, in both themes:Testing contrast
We used 3 different techniques to test color contrast in our HTML page.In DevTools
DevTools has a built-in contrast feature. If you start , you can hover over elements in the page, and DevTools will show a little popup that follows your cursor and indicates the color contrast of the hovered element you even get a green checkmark next to those with enough contrast and an exclamation icon next to problematic ones.Using the Accessibility Insights extension
Since we had 17 different badges to check, in 2 color themes, we needed something a little faster. The comes as a (for both Google Chrome and Microsoft Edge) that, among other things, can check for color contrast issues. We use this extension in our audits of new products as it provides automated and guided accessibility test flows. Using the extension, we were able to run a scan of the entire page, and it reported 15 contrast issues all at once. While this browser extension was very useful, we lacked one more thing to make the fix easy to do. We needed to be able to make adjustments to the colors and see the resulting contrast in real time.Our custom color contrast checker
We borrowed some of (the DevTools front-end code is in JavaScript and TypeScript, which made it straightforward) and added it to the local web page. Wrapping the calculation code in an interval to display warnings in the page directly meant that we were now able to change colors in DevTools and see what the new contrast ratios were without having to reload the page. You can or . One interesting technique we used to show the contrast in the page was by using on the badges. We calculated the ratio for each badge and then set it on each badge like this:badge.dataset.contrast = ratio;
Using a CSS pseudo-element and the we could then display the contrast value directly from CSS without needing any other DOM elements: .badge.low-contrast::before {
content: attr(data-contrast);
position: absolute;
background: red;
color: white;
/* ... */
}