You never create one product on the web – you create a product that people can change to their needs. At least you should.

I’ve been working on the web since 1997 and one thing I realised early on is a big basic idea of the web:

You do not control how your web product is consumed by your users – it is up to you to make sure people can change it to their needs.

As advocates of a usable web by everybody this was and still is the most misunderstood concept. I don’t know if it is because web design originated from print design. Or it may be because Flash promised to allow you to convert any design to the web. Or it just is because people don’t feel like looking past their own experiences. Or it is pragmatism, people know they don’t have time to make a product that adapts to users needs, so they build what they can. Or it is arrogance and a lack of repercussion. We keep telling people that they can be sued if their product “isn’t accessible”. But the reality is that there aren’t many successful court cases with real repercussions or fatal brand impact. Most ended up settled outside of court.

It doesn’t matter though, as the fact remains that people have to and will change the way your product looks to make it available to them. And it is a terrible thing to do to block someone out, although they already took a lot of steps to try to consume what you have to offer.

So here are a few things you can do to spot check if what you build works for as many people as possible.

• Resize the font to 300% (Ctrl + Plus) and see if you can still use your product
• Don’t use a mouse, try to navigate with keyboard alone
• Blur the screen (or squint) and see if the most important bits of interaction are still obvious.
• Play with the accessibility features of your OS and see what people user (Screen magnifier, high contrast mode, screen reader)
• Check your web site in reader mode of the browser and see if all the features it ripped out are actually that important, or if you could get rid of them for all your users
• Use the emulation in developer tools of your browser to spot-check how different users may experience your product

I wrote a detailed article on the DevTools for Edge documentation site on how to do that. There is also a cross-reference to tell you what tool you can use to test for which accessibility issue .

And there’s a whole course on Skillshare about Product Management: Tools for Improving Product Accessibility if you like videos better.

It is annoying that the accessibility emulation features are scattered amongst different tools in Developer Tools right now (Issues, Elements, Rendering…) and we’re working on a better way to do that. The DevTools for VS Code extension tried to do a better job with that by showing accessibility issues right in your source code:

The embedded browser also offers mode emulation and visual deficiencies emulation as a toolbar on the bottom rather than only part of the main tools drawer.

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

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.

We’d love to get more feedback on that and see if rolling that out in the main browser would also help you get a better understanding of what could be necessary for people to do to your product to make it accessible to them.

The Inspect tool is a great way to get information about different page elements before selecting then. Once it is enabled, it shows an information overlay as you move from element to element.

The main problem with the tool is that sometimes it is tough to get the information about the right element, as they are too close together and the information overlay shows the next element once the mouse moved a bit.

Whilst this can be annoying for any user, it becomes unusable for those who need to zoom the interface. In zoom mode, you magnify part of the screen and the magnification window moves with the mouse cursor. As the mouse cursor moves, the information overlay disappears, so you end up in a frustrating endless loop.

We got a report of this as an accessibility issue in Microsoft Edge and fixed it. From Edge 102 onwards, you can now press Ctrl+Alt when you have an information overlay active to stop it from disappearing. This makes this tool also usable to screen magnification users as shown in this screencast. It starts with the current interaction and then shows what happens when you press Ctrl+Alt and move the mouse around.

This also makes it easier for all users to get the information of Elements close to another. As an extra, you can also press Ctrl when you move the mouse around to only highlight the different elements and suppress the information overlay. This cuts down on a lot of noise.

This change shows that by fixing an issue for users of assistive technology, you can make it a better experience for everybody.

The problem has also been filed as a bug on the Chromium project .

Using the Quick edit bookmarklet you can make any web site editable. Drag it to your favourites toolbar, click it and you get into edit mode. You can edit, copy and paste, delete and anything else. Hitting `ESC` will end edit mode.

You can use this to quickly edit web sites before taking a screenshot, for example.

The source code is available on GitHub

Last week, Šime Vidas complained on Twitter that it is hard to paste a block of text on a mobile device. I proposed to use pastebin.com but that needs a lot of taps before you paste. Šime then proceeded to joke that we should create pastebinzero.com and all it needs is a full-screen textarea with autofocus.

So I spent literally a minute to build this. In my browser, with nothing but a GitHub login. From setup, to coding with autocomplete support to hosting. You can see it in all its glory at https://codepo8.github.io/pastebinzero and look at the code at https://github.com/codepo8/pastebinzero.

And you can do that, too. Here is how.

If you feel like seeing this as a video, check out the following ~2 minutes walkthrough.

Otherwise, here are the steps to start, build and host any HTML/CSS/JavaScript based project on GitHub.

• Go to your GitHub profile, click on `Repositories` and press the “New” button
• You need to name the repository, as this will later on also be part of the URL. GitHub automatically tells you if the repo name is still available or not. Make sure that your repo is public and hit “Create Repository”. If you don’t want to show the source code but only have people see the result, you can also keep it private. The generated GitHub pages are always public.
• This created the repository and you get all kind of information what to do next. For now, click `creating a new file` link.
• Name the file `index.html` and enter anything as the content. This isn’t important now as this editor here is OK to do some quick fixes, but doesn’t cut the mustard. Press the `Commit new file` button and you get a new file.
• Go to the `Settings` tab and select the `Pages` menu item. Make sure to pick the `main` branch from the dropdown menu and hit `save`. This makes what you are working on available as a URL on the web
• Go back to the `Code` part of the repository and press the `.` button. This loads Visual Studio Code in the browser with this project open. You can now write your project using the full power of VS Code, including autocompletion and IntelliSense.
• Once you are done, go to the `Source Control` option in VS code, enter a commit message and click the checkmark. This commits the changes to the repository.
• You can see when your product is available online on the “Actions” tab of your repository. Check the “Pages build and deployment” workflow. It shows a yellow spinner until the page is ready. When it turns into a green checkmark your page is ready.

For the video demo, the code is available at https://github.com/codepo8/greencircle and the in-browser version can be seen at https://codepo8.github.io/greencircle where `codepo8` is my GitHub user name and `greencircle` the name of the repository

Why not codepen, jsbin, codesandbox, jsfiddle… ?

There are dozens of places you can host and edit projects online and all of them have their benefits and problems. I really enjoy this way as it gives me the full functionality of Visual Studio Code and my project is in version control. I own all the code and can download it any time I want to. I can also allow other people to fork and change it.

Many of these features are also available in the other platforms and I really like that you can immediately see the results of your projects as you code them. But this feels like a great end-to-end solution requiring only one login I need for most of my work anyways. Incidently, if you want the immediate display of your project inside VS Code in the browser, you can also install the “Codeswing” :https://aka.ms/codeswing extension.

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.