Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

What people think that web developers do vs. what we really do

Friday, May 27th, 2022

What people think web developers do:

Chart showing what people think web developers do

  • Code, deploy and use, with coding being the main task

What web developers really do:

Chart showing the real tasks

  • Coding
  • Require random 3rd party framework code
  • Updating Node/NPM
  • Try the last command again with `sudo`
  • Checking on mobile
  • Shaking fist towards Cupertino
  • Looking things up on the web
  • Pasting Stack Overflow solutions
  • Resize the browser/use emulation
  • Discover that a browser extension was the problem all along
  • Explain again that things can’t look the same everywhere
  • Add ARIA till everything is fine
  • Trace performance issues back to analytics/ad code
  • Convert content to usable formats
  • Adding/Removing console.log()
  • Invalidate caches
  • Using
  • Summon Imhotep using blood magic to help with a rendering bug

TL;DR: Learning to code isn’t the main skill you need as a developer

A teleprompter script for video recordings

Wednesday, May 25th, 2022

Currently I am recording a lot of videos and I found the fastest way to do them is to write the script and read it out to my camera and then record screencasts and edit them to fit the narration. In order to make sure I read from the top of the screen and reading into the camera I had to scroll my scripts a lot, which was annoying so I wrote a small teleprompter script to work around that problem.

You get a text box to write or paste your script and pressing the “show as prompt” button will display one paragraph at a time at the top of the screen in a large font. You can click the document or press the right arrow key to move forward and Escape to go back to editing.

The prompter script in action

If you go to https://codepo8.github.io/prompter/ you can see it in action and the source is also on GitHub. It is nothing fancy and a lot was written by GitHub CoPilot for me anyways.

Global Accessbility Awareness Day – Does your web product support the needs of the many?

Thursday, May 19th, 2022
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:

Live issue reporting flaging up a problem in the 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.

The new emulation bar of the browser preview

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

Device list showing various mobile phones and tablets

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 CSS emulation showing the document in forced colour mode with the menu offering other emulations

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.

The page being displayed in a blurred fashion and the menu offering more visual 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.

Fixing the accessibility of Inspection overlays

Tuesday, May 17th, 2022

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.

Recording of the inspect tool in action

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.

Information overlay in magnification mode

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.

Pressing Ctrl while moving the inspect tool around doesn't show any information overlays

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 .

A “Quick Edit” bookmarklet to make changes to any web site

Thursday, May 12th, 2022

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.

Quick edit in action - drag it to your toolbar, click it and start editing the page. Hitting ESC end the editing mode

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

The source code is available on GitHub