Using overrides in Chromium DevTools you can cache static assets locally and you don’t need to wait for GitHub pages to build before seeing a change in your scripts or styles.

GitHub Pages are a great offer. You can host and version control not only your code on GitHub, but you can also turn it into an HTML page that people can see in their browsers even if they don’t have a GitHub account. All you need is to turn on Pages for your repo and any markdown files already get shown as HTML documents. You can add a `_layouts` folder with a `default.html` document and any markdown file gets shown using this one as a template.

The only problem you will face is that it always takes a while to generate the new pages. You can check the `Actions` tab on GitHub to monitor the progress, but it can get tiring to wait for the yellow spinner to turn into the green checkmark.

Especially when there is no build process necessary. Turning markdown documents into HTML with Jekyll support is worth waiting for, but it is annoying that a simple CSS change also means you have to wait for the build to successfully conclude.

This is why I use Overrides to work around that problem.

Say I want to mess with the CSS of Dear Console without wanting to wait for builds, here’s how I do that:

• I Go to the page
• I open the Sources tool
  
• I select the arrow down to show more tabs and choose “Overrides”
  
• I activate the “+ Select folder for overrides” button and pick a folder from my hard drive.
  
• The browser asks me for file access to the folder. I choose the “Allow” button
  
  Now this is the overrides folder for my browser. I only need to set this once – from now on, this is where files I want to override live.
  
• I can now go to “Page” and select the files I want to store in this folder. I right-click any file I want to override and select “save for overrides”.
  
  This will add an indicator to the file icon showing me that this file is now overridden.
  
• The file is now on my hard drive in the folder I specified.
  
• I can edit the file there, and when I reload the Github page, my browser will load the files I have on my hard drive instead of the ones from GitHub.

If I now open this file in my editor and change it, saving it will refresh my browser and I can see the style changes.

Overrides work with any web site out there, and are – to me – a really underused power tool to mess with the web and not waste our time waiting for builds to finish.

Sometimes you want to notify a user that something has happened in your application. To be as inclusive as possible, it is important to display these notifications close to where the action happened. Here is how to do that with plain javascript.

When something happens in an application that has no direct visual outcome, it makes sense to tell the user with a message that it happened. One example where I implemented that lately is the Dear Console,… project. When you activate any of the copy icons, you get a message showing right where you were that the text is now copied into your pasteboard.

This is a pretty common task, but often you see implementations that forget some basic aspects of accessibility. Pretty common are notification bars on top of the screen or a toast message bottom right. The problem with those is that you assume that people can see the whole screen. But there is a large group of people that only view a small section of the screen, either because they use a mobile device, or because they need to zoom in to interact with your product.

This is why it is important to give the feedback message right where the interaction happened. There are several ways to achieve that, and here is one that I found generic enough and sturdy in its implementation. You can see it in action in this codepen .

See the Pen
Positioning notifications by Christian Heilmann (@codepo8)
on CodePen.

Obvious mistake: Don’t trust the mouse position

The first thing most people would do to position an element where the interaction happened is to read the mouse position and display it accordingly. This fails because of two reasons: first of all, not everybody uses a mouse and secondly, reading the mouse position in a world of positioned elements, scrolling interfaces and documents in iframes is complex.

Better: reading the position of the target element

One of the more “this is a mouthful” DOM methods is element.getBoundingClientRect , but it is incredibly useful. It gives you the location of an element in the document and its dimensions as an object

You can use this to position another element right next to the current one by reading the `top` and `right` properties. If you use an element that is keyboard accessible, like a button or a link, this means you can support all kind of users. In the case of this demo, we use buttons.

Styling the notification

.popup {
  position: fixed;
  left: calc(var(--element-x) * 1px);
  top: -20em;
  transition: 400ms;
  /* more styles */
}
.copied .popup { 
  top: calc(calc(var(--element-y) * 1px) - .5em);
  left: calc(calc(var(--element-x) * 1px));
}

We position the notification message as `fixed` on the screen and give it a `left` and `top` property. To make things smoother, we also add a transition. As the values of left and top we use CSS custom properties. These we will get later on from JavaScript and the `getBoundingClientRect`. As they are without the ‘px’, we need to use `calc()` to tell CSS what to do. We position the message off-screen (`top` as `-20em`), and move it to the element position when there is `copied` class on a parent element. This allows us to keep all the styling in CSS. JavaScript is only needed to get the values and to add and remove the parent class.

Showing, hiding and positioning the message with JavaScript

The script to make the rest happen isn’t too complex. You can see it in its entirety here with comments on what the code means.

// hide the message after 1.5 seconds
const timeout = 1500;
// create an element with the class popup and add it to the
// document
const body = document.body;
let copypopup = document.createElement('output');
copypopup.classList.add('popup');
copypopup.innerText = '☑️ Copied!';
copypopup.tabIndex = -1;
body.appendChild(copypopup);
 
/* 
  When someone clicked one of the buttons 
  add a class of `copied` to the document body.
  Undo this after 1.5 seconds
*/
let copythis = elm => {
  body.classList.add('copied');
  setTimeout(() => {
    body.classList.remove('copied');
  }, timeout);
}
 
// If there is a click on the body element
body.addEventListener('click', e => {
  // test that there is currently no active message
  if(!body.classList.contains('copied')){
    // get the element the click happened on and 
    // ensure it was a button
    let t = e.target;
    if (t.tagName === 'BUTTON') {
      // get the position of the button and set 
      // two CSS custom properties accordingly
      let x = t.getBoundingClientRect().right;
      let y = t.getBoundingClientRect().bottom;
      let root = document.documentElement;
      root.style.setProperty('--element-x', x);
      root.style.setProperty('--element-y', y);
      // call the function to show the message
      copythis(e.target);
    }
  }
});

Possible enhancements

There are still a few things we can do better. For one thing, we still are in a visual context here. Users of assistive technology like screenreaders who can’t see what’s going on, don’t get any information that we successfully copied something to the clipboard. In the following recording the buttons are announced but the interaction with them doesn’t say anything about the notification.

This fixed codepen example works around this problem by using an `output` element in the source and changing its value.

This makes it work with screenreaders. Interacting with the buttons now announces the text of the notification and what was copied.

The last thing I am not sure about is to automatically hide the notification after an amount of time without giving a user to prevent that is the best way. Got an even sturdier solution? Please comment!

By using the Edge DevTools extension together with Live server in VS Code you don’t only get a server that shows your changes live in the browser, but a browser and developer tools right in the editor

The Live Server extension for Visual Studio code has been installed 25M times and is incredibly useful. It enables you to right-click an HTML document, and it runs a server for you and opens a browser window with the file in it. Any changes you make to the file causes the browser to reload and you can immediately see them – hence “live server”.

The problem is that you still have to jump in between the editor and the browser if you want to debug the project using the browser developer tools.

If you use the Edge DevTools for VS Code in addition to live server, you don’t have that problem. Instead you can:

• Get a live preview of changes to the file in a browser window right inside VS Code
• Use the browser developer tools and automatically sync the changes with your source files
• Get information about issues in your code and how to fix them
• Get a Console to try out JavaScript or see your `console.log()` messages right in VS Code

You can see this in action in the following video:

The process is not quite straight forward yet, but we’re working on it.

• Right-click the file you want to open and choose “Open with live server”
• Copy the location from the URL bar of the browser tab that Live server opened
• Go back to VS Code and right-click the same file, this time choosing “Open with Edge” and either “Open Browser” or “Open browser with DevTools”
• In the browser panel that opens, paste the URL from earlier
• … and that’s it.

What could be done to make that easier? You can chime in on this issue on GitHub to give us some ideas .

Here are some recent links on the topic of accessibility you might enjoy and learn something from:

• Manuel Matuzovic has a course together with SmashingMag on Deep Dive on Accessibility Testing starting on the 14th of November 2022.
• On that topic I also have a class on Skillshare Product Management: Tools for Improving Product Accessibility and wrote the in-depth article on how to use the Edge DevTools to look for accessibility issues in your products and there’s a handy cross-reference what tool to use to test for which accessibility issue .
• Scott O’Hara writes about Responsive accessibility using visibility hidden
• Sachin Gupta of Deque describes Why you need to monitor and report on accessibility—all the time
• Léonie Watson argues Why we need CSS Speech
• Geri Reid on Designing an Accessible Future both as a video recording of her talk and in text form.
• Alicia Jarvis talks about Product Accessibility: Building an Inclusive Product

If you use Microsoft Edge, you get a camera icon when you hover your mouse over any image:

This is a great tool for users as it allows them to do a visual search in a sidebar for that image.

During local development, the icon appears on images, too, but the results don’t show up. That means it interferes with your design and doesn’t work.

If you hover longer over the icon, you can access an overflow menu `…` which allows you to hide the icon for this site, to always hide it, to go to the settings and to give feedback.

You can also go to the browser settings edge://settings/appearance/visualSearch to add sites you don’t want to see visual search by hand.