Now that Visual Studio Code has an in-built JavaScript debugger, it has become incredibly convenient to debug your project without leaving the editor. You can debug JavaScript, tweak CSS and the DOM and interact with the browser Console right inside VS Code. And you don’t need to know which extensions to install as the editor guides you along the way.

Under the hood, this uses the JS Debugger and the Edge Tools for VS Code extensions. Here’s what the flow looks like:

If you haven’t got the Edge Tools extension installed, VS Code will prompt you to do so the first time, as shown in this screencast:

In addition to breakpoint, DOM and CSS debugging, Visual Studio Code’s Debug Console now also is the same Console you normally get in the browser. You can access the window object of the browser instance and use all the Console Utilty Methods like `$` and `$$`.

To run the debugger automatically on your project, you need to create a `launch.json` file and define the debugger as the launch type. The Edge Tools extension can also do that automatically for you. If your application is not on `localhost:8080` you need to tweak the `url` parameter.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "pwa-msedge",
            "request": "launch",
            "name": "Launch Edge against localhost",
            "url": "http://localhost:8080",
            "webRoot": "${workspaceFolder}"
        }
    ]
}

If you want to see this in action, you can download/fork the demo to-do app I used in the screencasts.

What do you think? Anything you’re still missing in that workflow? File an issue on GitHub and tell us about it!

Over the course of my career I’ve seen a lot of excellent accessibility presentations and learned a lot. That’s because I worked in the accessibility space and went to specialist conferences. Web development conferences also have accessibility talks and their number is rising. But often these don’t go past the 101 stage or repeat things that should be obvious. Alas, many of these things aren’t obvious to the average designer/developer. The reason could be a thing I’m calling the accessibility stalemate.

What do I mean by that? A lot of excellent accessibility advice never gets distributed beyond the initial audience. The reason is that people love to call out any accessibility problems with the materials. There is a knee-jerk reaction I’ve seen over and over again. Calling a slide deck explaining how to make content accessible that isn’t fully accessible as “ironic” or “a bad example”. A lot of presenters don’t share their talks because of that. I saw many conferences not release any of the materials or videos as they couldn’t caption them or host them on a platform that allows for it.

It is tough to make things accessible. I’d even go as far as saying that you can never make things accessible to everyone. All you can do is make sure that the materials you publish can be altered to the needs of your users. At the least, provide information that describes things that are visible only – like alternative text for images. We understand that and when it comes to products in the wild, we’re forgiving if things aren’t perfect.

We are not as lenient when it comes to information materials of accessibility events. If they aren’t perfectly accessible, they’re seen as a disgrace. And that’s holding us back.

Many presentations complain about the lack of basic accessibility in products. On the surface, it seems to be valid criticism to call out when they aren’t in an “accessible format”. Or when they fail to provide alternatives for each image and video in them. Except, it is a cheap shot and feels like a distraction from the problems the materials talked about. “You don’t follow your own rules, so why should I?” is a cop-out of those who don’t want to think about a certain matter.

It reminds me of this classic piece by Jeffrey Zeldman that calls out people criticising articles for the platform they are published on. “Isn’t it ironic that I can’t read your article on mobile best practices on my mobile device” and similar smart remarks. No, it isn’t ironic, and it is also not that important.

What do we gain by ensuring that a presentation about how people use screen readers is accessible by a screen reader? Is that the audience? The one who already knows this information? Who do we serve with this? Or – let’s turn it around – who do we miss out on when we spend a lot of effort on it? Unless the talk is about creating accessible presentations and you show with your talk materials how to do it, it seems extra effort not serving the right audience.

How about we stopped with this and instead concentrate on getting accessibility information to those who need it in a format engaging to them?

Here are a few accessibility truths/prejudices to tackle:

• Accessibility is scary – the best selling point for accessibility hasn’t been “making it work for everybody will create better products” but “you will be sued if your product isn’t accessible”. We’ve played that card for years – it works. However, it doesn’t result in accessible products, it results in compliant products. But it cemented accessibility as something people don’t strive for, but something they worry about instead.
• Accessibility is boring – by telling people they must do invisible things to be compliant we didn’t make accessibility a “wow, I want this”. We made it a chore, a task to do before you can release. Accessibility isn’t boring. Just look at how we use our mobile phones. Most of the features that make them cool (geolocation, voice recognition, read aloud…) were originally created for assistive technology. And yet we worry about not spicing up our accessibility presentations with multimedia as it isn’t accessible to all.
• Accessibility is complex – currently I work on developer tooling, and I try hard to make accessibility testing and creation of accessible interfaces easy. It isn’t though. The whole idea of the accessibility tree as an alternative representation of the document is confusing a lot of people. And while we have highly visual and intuitive tools for performance testing and CSS creation, the accessibility focused ones tend to be basic and bland. Right now, most of them are used by testers instead of developers/designers. That’s not enough.

We have a lot to gain by making accessibility, well, more accessible. We do not do that by blocking information from going out as it isn’t perfect when it comes to accessibility. We do cater to various audiences, and you catch hearts and minds by using a format that appeals to these audiences. Not the lowest common denominator.

So next time you feel like calling out a great video or presentation for lack of “accessible format” or captions, maybe do something about it instead. Write about the video or the presentation and publish your musings in a perfect, accessible format. Good luck.

Learn more: More about my approach to accessibility and how I ensure that our products have an accessibility built in from the get-go, in my Skillshare class Product Management: Tools for Improving Product Accessibility.

The other day, I mulled over the problem of bad user experience resulting in more usage of products.

Half your job as a product manager is not to get excited about rising usage numbers caused by bad UX. Often delivering a great experience means less usage - people get what they came for quickly. Tough to sell as success in a market obsessed with usage minutes.

— Chris Heilmann (@codepo8) July 14, 2021

And I followed up with wondering how we could get to a “happy user” metric.

We need a "happy user finished task they came for" metric, but this one is hard to measure as you are 10x more likely to get feedback from people who had a bad experience.

— Chris Heilmann (@codepo8) July 14, 2021

When measuring the success of software products, data is king. When I moved from DevRel to program management, my world got a lot more dashboards and charts. I found myself spending more time looking at user feedback. I learned about asking questions to find the real issue that caused dismay in users instead of adding a feature satisfying their request. I started feeling despair looking at the noise to signal ratio you get in feedback channels. And I started to question our razor-sharp focus on numbers and continuous growth.

We love growth and numbers. It is pretty depressing how much we see growth as the only thing that matters. Users, download numbers, sessions, minutes of usage – all have to go up from version to version – or you failed.

This makes sense when you grow and when the funding of your product is dependent on user numbers. It is the main thing that empty products like social platforms have. You need users to get content and engagement. You always need to get more to be able to tell advertisers that you have so and so many users. I remember working on app stores in another company and wanted to bang my head on the table. People measure the success of a store by the number of apps, not by their quality. At one time I met with a company offering to create 500 apps a week for a certain price. That way our app store can look bigger than the others. You’ve seen apps like these: “paint a cat”, “paint a dog”…

The big issue is that our fairytale success stories in software are the fast growing platforms millions of people use. Are you as successful as Facebook? Are you growing as fast as TikTok? Do you have as many active users as MySpace? Oh, wait…

Not all products are there to always grow. Some products are specialised, and you don’t even expect people to use them all the time. Many of the things I work on in the developer tooling space are things you only use when there is a certain problem. The happy path for the user is simple. Open the tool, use it to find the problem to fix, close the tool and forget about it until the next time.

No growth there, but something more important: helpfulness to the user. If the tool does not only allow you to track down a problem, but also gives you valid advice how to fix it, even better. I love when a tool educates me about a problem. I am happier, and I even learned how to avoid the issue in the future. Which means I don’t need to use the tool any time soon any longer.

As the tool creator, who has to show continuous growth, this is a problem. The only way to increase usage numbers is to ensure the problem happens more often. And that is beyond the reach of the tool creator.

The question then is, how do you measure the success of those? And even more interesting – how do you defend a drop in numbers when you fixed an issue?

The other day we encountered the issue that a highly used product also got a lot of feedback. Negative feedback, telling us that people don’t know what it is and why it is there and that they want to get rid of it. This is something you want to dive into. Unhappy user feedback is high priority, especially when your product confuses the users. People put effort in to tell you about the problem, you should reward them for that.

As it turns out, there was a simple way to accidentally hit the keyboard shortcut to open the product. For power users keyboard shortcuts are amazing. That’s why developer focused tools have dozens of them. For normal folk, they can appear as witchcraft.

The solution was to add an extra step the first time the keyboard shortcut happens. We show information telling you what will happen now, what product you will open and if that is what you wanted. We offer to never to do that again for people who triggered it by accident and never to show the message again for others.

We didn’t come up with this super clever way of dealing with this ourselves. We did user research and tested various ways to work around the problem.

This will cause a dip in our usage numbers for sure, but it also means that all we lose is accidental, unhappy users. Which is great. But what if I worked elsewhere and the next bonus or funding for my product is dependent on more users each month?

The interesting thing here is that we have proof that those users were not happy getting there. So we can point to the feedback data and show the drop off in negative feedback as a win of happy users. We can only do that as we have an easy to reach and use feedback mechanism in our tool. And this is where far too many products fail, in my book. If you don’t ask your users how they like what you do and allow them to complain about problems, you can’t find issues like these.

We need a new metric of happy users. But I am still at a loss how to get to that one. One thing I know though is that chasing more users or interactions for the sake of growth doesn’t make better products.

A few days ago I posted a graph I found some time ago that jokingly explained the benefits of subtitles in movies and tweeted about it.

Good #a11y features are beneficial for lots of people. pic.twitter.com/2RMnTzseey

— Chris Heilmann (@codepo8) June 28, 2021

The tweet went wild and so far has 35 answers, 290 retweets, 1,500 likes and 150,000 impressions. I love that the answers are all about people’s experiences with subtitles and why they choose to turn them on. These range from selfish reasons like being able to only pay half attention to the movie, to people trying to get linguistic nuances and utterly sweet things like being able to watch something without waking up a baby.

Personally, I am a huge fan of captions and subtitles. First of all, I learned English using them. Growing up in Germany, TV is dubbed and you normally don’t get the option to have subtitles. Growing up in the 80s also meant that there was no interactive TV, so all you got was what was on offer. Weirdly enough, one show that wasn’t dubbed was Monty Python’s Flying Circus, which instead came with German subtitles. This was great, as I could listen to the original audio and learn the meaning at the same time. Even more importantly, I learned about pronunciation of the words, not only their meaning. We learn the phonetics of a language by repetition and if you get a native speaker as the source, that’s an excellent start.

As this was a state channel (all of them were back then) they offered subtitles as an accessibility feature, and it was paid for by the taxes we pay to get access to TV and radio. They were meant to help people who are hard of hearing but were a great way for me to get started learning my first foreign language.

And this is what accessibility features should be in my book: necessary for some, but also beneficial to all. Now, with captions and subtitles, we have a problem. Good ones are expensive, and they seem to be a massive overhead for videos we provide.

However, we also live in amazing times where video platforms create transcripts of videos for us. On YouTube, for example, you only need to define the language of the video and some machine learning product will create a transcript for you. Even when you don’t add alternative text to images, many platforms like Twitter and Facebook will create some automatically generated description added as an “image may contain:” alt attribute.

The problem with those is that they are often full of misunderstandings and not necessarily well structured. The good news is though that most platforms also allow you to export automatically generated transcripts and edit them. Most video hosting platforms also have in-built editors that allow you to verify and tweak the transcript to fix these issues. It is still quite some work to do that, but really worth the effort.

Using these features has a few benefits.

• You can add the transcript not only to the video player but also as a text to the document. This allows visitors to search the video and find what they are looking for. As most video players allow you to jump to a certain time stamp you can link different keywords to certain times and thus allow people to only watch what they need rather than having to scrub through or watch the whole video.
• Some video players even offer a transcript search that makes the video as searchable as an text document.
• Having a transcript also allows people to use their browsers to translate it to their language and thus at least get an idea what you are talking about.
• Search engines can index the transcript and make your web product show up in search results even when people didn’t search for videos.

This kind of thinking is what I try to apply to any accessibility work that I do. We need to make our work accessible anyways, so we may as well try to find ways to make everybody benefit from it. Simpler language, easier interfaces, not overloading the user with lots of information or not using lots of animation means all our visitors have a quicker way to consume what we offer. Accessibility to me means hard-core usability. You make it work for extreme cases and thus make it better for everybody. And by thinking like that, accessibility work isn’t a chore or something we need to do to be legally compliant, but it is a quality feature of our products.

If you want to learn more about how I approach accessibility and how you can test for and fix the most obvious issues using only the browser you already have, you can check out my Tools for Improving Product Accessibility class on Skillshare.

Last week my former colleague Si Jobling interviewed me for his Make life work podcast about working from home, in different time zones and how to optimise your workflow.

This also tied in nicely with Tools and Tips to Optimize Your Workflow as a Developer class and I shared how this one got prepared and recorded.

It was great fun talking to Si again and catching up on the parts where our career crossed – working for Yahoo UK.