The V2 version of the Microsoft Edge DevTools for Visual Studio Code extension is now live. We’ve worked hard to make the current feature set more stable and introduced new ones.

Console integration

Console Integration – makes it easier to use `console.log()` or interact with the document right from the developer tools. We found the old integration to be flaky and hard to find in the `Output` panel.

Improved CSS Mirror editing

CSS Mirror Editing – making sure that none of your tweaks in DevTools get lost. This is now out of experiment and doesn’t use up as much screen estate any longer. You can enable and disable it in the Styles tool.

Updated issue reporting

Live issue reporting of problems in your code. If you have any code that is a problem you will see a wavy underline on it. You can hover over it with your mouse or use the `Problems` panel to learn what is wrong and how to fix it. We’ve updated the issue engine to make sure you get the latest and will soon offer ways to customise the issues you’d like to see. For now, we’ve removed Internet Explorer error reporting as it may rest in peace.

Brand new browser preview with emulation

🆕 Screencast with emulation features – we added a brand new browser preview that doesn’t only give you the browser to interact with right in the editor but also offers various ways to emulate different environments. On the bottom of the browser preview you get a toolbar with various options:

First is the device list. You can select from a wide range of different emulated devices.

If you don’t select a device but choose `Responsive` instead, the browser will take up the whole available space. You can also define a viewport size using the form and rotate the viewport with the double arrow.

The magic wand menu allows you to simulate various CSS media queries, like print mode, dark/light mode or even simulate a forced colours (high contrast) environment. If you want to know more about forced colours, check this incredible article

The last menu (currently using the eye icon) allows you to simulate different visual impairments, like seeing the page in a blurred fashion or in different “colour blindness” emulations.

🆕 Sourcemap support for styles – means you can now debug the styles of Sass/React and other abstraction apps without leaving Visual Studio Code.

For lots more details you can also check the Changelog

Getting started with sourcemapped styles debugging

I’ve covered this here before when I asked for feedback, but now this should be much easier. If you open the Terminal you can do `npm i` and `npm start` to build your App and run the server. In this example, the app is now available at `http://localhost:3000`.

If you click the Edge icon you get the option to launch an instance of Edge or `Generate launch.json` file. Click the latter.

This generates a `launch.json` file in a `.vscode` folder of your app with all the correct settings. Find all the instances of `url` and change them to `http://localhost:3000`:

Save the file and press F5. Visual Studio Code will start the debugger and open a browser window with your app and the developer tools right inside the editor.

If you now edit the styles of any of the elements of your app, you don’t only change CSS files in your project, but also their scss source files or modular styles.

For this to work, you need to set up sourcemaps correctly in your project. As we assume this to be problematic for some people, we have an issue open in the extension repo where you can find help.

Webaim.org releases an annual report called the WebAIM Million. This is a deep analysis of the one million most visited web sites how accessible they are. And every year the result is pretty grim.

Across the one million home pages, 50,829,406 distinct accessibility errors were detected—an average of 50.8 errors per page.

This is 1.1% fewer errors than last year, but at the same time home pages of sites have become more complex. On average, home pages have 955 elements and 5.3% of those have accessibility errors. This means that users with disabilities would expect to encounter errors on 1 in every 19 home page elements with which they engage.

The most disappointing part about this state of affairs is the type of problems.

As explained in detail in the report, the biggest issues are ones that seem to be easy to avoid. Lack of contrast in text, missing alternative text for images, empty links and buttons, missing labels and no defined document language. None of these are hard to avoid or test against, and yet they went into live products.

How to test for these issues in your browser

I have a full course on Skillshare on the matter and wrote in detail how to test for these issues in the Edge Developer Tools documentation. There’s also a handy reference on which tool to use to test for each problem and even if you use other browsers, there is a lot available in those.

The biggest helper though are the Inspector tool and the Issues panel. The Inspector overlay flags up elements with a lack of contrast.

Elements with enough contrast show a check mark:

Problematic elements an exclamation mark:

When you select the element, you can use the colour picker to define a colour with enough contrast to the background. Select the colour of the element that is problematic in the Styles editor:

Then expand the Contrast section. It shows you the current colour, offers two colours to choose from to achieve AA and AAA compliance and you can see two lines in the colour swatch. Colours with enough contrast are indicated by the two white lines as boundaries. When you move the cursor around the colour swatch you can see the contrast of the colour and if it is enough or not.

There are also features in the browser tools to test for test for the other issues of the report as you can look up in the reference. But how about we go one level higher up the chain and prevent you from making accessibility mistakes in the first place?

Learning about accessibility issues while you develop

If you are a user of Visual Studio Code, you can get the Edge DevTools for VS Code extension, which analyses the code in your Workspace and flags up all the accessibility issues that need fixing.

Any problematic element gets a wavy underline – much like any typo does in most text editors. You can then hover over the element and get information what the problem is and how to fix it.

You can also see all the issues in the document in the mini map and if you open the problems panel you can see all the problems in your workspace.

These are all live, so if you edit your document and fix issues, the underlines go away and the issue is removed from the problems pane.

It’s a start…

Using these features will not prevent all accessibility mistakes. There is also the fact that many of these problems aren’t caused by developers and designers at all but by content management problems or even themes not in your control. But these things can help avoid the most obvious problems, and any accessibility barrier that doesn’t show up in a live product is already a win.

Using the Edge Developer Tools for VS Code extension, you can live edit files in the browser developer tools and all the changes are also happen in your source files. That way you never lose a change you did to your web projects in the developer tools. It makes tweaking a layout much more convenient than jumping in between editor and browser all the time.

One huge request we got from users was to support Sass, CSS-in-JS and many other abstractions. This is now possible, if you target Edge Canary as the functionality is only available in Edge > 101.

You can see the editing in action in the following screencast:

To make it easier for you to play with this, we’re providing a demo app that already has a `launch.json` that targets Canary for you. You can download the app as a zip and use it like this:

1. Make sure you have the Microsoft Edge DevTools for Visual Studio Code extension installed
2. Clone this repo or download the app as a zip and unpack it
3. Open the folder in Visual Studio Code
4. Run `npm i` in the Terminal
5. Run `npm start` in the Terminal
6. Switch VS Code to “Run and Debug” and run “Launch Edge and Attach DevTools” (the project is already configured to use Edge Canary, just make sure you have it installed)
7. Start editing Styles in DevTools and watch them sync!

We have an issue open in the Extension repository and we’d love to get your feedback there!

Today, after a decade or so of using MacOS, I realised that preview has a zoom lens built in. You can toggle it using the backtick ` key.

Once it is on, you can also increase and decrease the zoom level using two finger pinch on the trackpad.

It is not that hard to create a script that shows and hides parts of the document, but often we forget about how our visitors use the products we build. Especially when it comes to navigating huge documents, people tend to use the “find in page” functionality of browsers. And when they do and we hid content with JavaScript, browsers would either not find the content or users won’t know where in the document it is.

If you use the HTML elements of summary and details you don’t have to write any show/hide code yourself and users of Chromium browsers (Edge, Chrome, Brave…) can use “find in page” as the browser will automatically expand the details that contain their search terms.

Here’s a quick video showing that on The VS Code YouTube channel and on TikTok .

You can see this in action on any page that uses the elements. For example on this W3C document you can open the Developer Tools and see the browser add the “open” attribute to the detail in question when the term was found inside the details.

More about summary and details:

• Robin Rendle on use cases
• Chris Coyier on animating the interaction
• Greg Gibson on styling problems
• Adrian Roselli on what we shouldn’t use details and summary for