Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for April, 2022.

Archive for April, 2022

One million broken web sites – and a way to prevent that

Tuesday, April 12th, 2022

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.

Chart showing the accessibility issues recorded in different home pages.Low contrast text: 83.9%, Missing alternative text for images: 55.4%, Empty links: 50.1%, Missing form input labels: 46.1%, Empty buttons: 27.2%, Missing document language: 22.3%

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:

Elements with enough contrast show an check mark in the contrast section of the inspector overlay.

Problematic elements an exclamation mark:

Elements with not enough contrast are flagged up with an exclamation mark in the overlay

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:

colour picker of browser DevTools with the contrast section highlighted

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.

Colour picker tool of DevTools with expanded contrast section

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.

HTML document with Accessibility issues open in VS Code , the error is highlighted and explanations are visible 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.

Problems panel open showing all the accessibility problems.

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.

Animation showing how the live analysis removes and adds reports of accessibility issues

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.

CSS Mirror Editing with Sourcemapped files (Sass, React…) – we need you to make it better

Friday, April 8th, 2022

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.

Sourcemaps demo running inside Visual Studio Code

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!

Quick MacOS tip: Preview as a built-in zoom lens

Wednesday, April 6th, 2022

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.

Screencast showing the functionality

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

The devil is in the details…

Tuesday, April 5th, 2022

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.

Animation of the browser automatically opening a section when a search term was found inside it.

More about summary and details: