Last week I was at build Europe and talked to a lot of people about the developer market. The general consensus was that there is a huge lack of developers to hire. That there is not enough talent. When I poked further and asked about how people assess talent, it boiled down to people having the right degrees. We are desperate to have more computer scientists.

But do we really need computer scientists? I’m not saying a solid foundation in computing isn’t great and there are for sure a lot of tasks that need experts. But I also see that the down-to-the-metal work is a tiny percentage of the market. People who build web sites or apps are hardly ever starting from scratch.

Instead we build using packages of other people, frameworks to fail fast and re-iterate, reusable components and build systems. None of these are taught in schools in universities for the main reason that they are short-lived and constantly evolving. What stack a company uses changes over time and depending on the project. How we apply the stack is decided by the lead engineers and architects in the company.

Considering that we – for better or worse – build on the work of others aren’t the people we really look for another skillset than computer scientists? We need flexible implementors, people who can learn a new environment quickly and assess the quality of components they use. We hardly ever get the chance or find the need to write code from scratch. Digital librarians, so to say. A good librarian doesn’t know the content of all the books in the library but where to look to find the right information.

The quality of people like these is harder to assess, for sure. But a diploma also doesn’t mean people are effective developers either. Being someome without a degree myself I always loved that our market is accessible to many people. Maybe that should be a thing we should strive to celebrate and embrace more in our search for new people.

Retention of people in our market is terrible. By the time you are used to how a colleague ticks, they are likely to leave. Often the reason is that we hire programmers to build products using off-the-shelf components. No wonder they get bored.

Maybe we can turn that around by training people on the job better and lower the barrier to entry instead.

What people think web developers do:

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

What web developers really do:

• 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

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.

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.

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 .