Sometimes it is baffling to me why people publish on the web and don’t follow the simplest ideas that made the web what it is. Take a link for example. You can link anything in HTML so that when users interact with it they go to another URL, or a target inside the current document.

Links should do two things:

• Tell you where they are going
• Work for everyone

HTML links using the anchor element are amazingly accessible. They can be activated using mouse or keyboard, you can open the context menu on them and open them in a new tab, copy the link’s URL or bookmark them.

It is also immensely important that the link has some text and that this text is unique. The reason is that people who rely on assistive technology like screenreaders will access links outside of context.

Imagine that you can’t see and you want to quickly navigate a document without having to wait for the computer to read it all out to you. Screenreaders give you that option by offering the heading structure of a document and a list of landmarks in the document. Another fast way of navigating inside the document is getting a list of all the links in the document. According to WebAIM’s screen reader survey 67.7% of screenreader users navigate the document by skipping from heading to heading. 7.1% navigate via links and 8.1% read the whole document.

This weekend the Verge announced a new series on their magazine called The Installer, a newsletter that is also a web page. What a shocking new idea. What really baffled me though is that they chose to use a new way to display links that are part of the news announcement. And they chose one that breaks every link convention and represents an accessibility nightmare.

As explained in the screenshot, the installer displays news items as bold and not linked. Instead, each of the items is followed by the text “link” inside parenthesis. Why? Don’t know. What I do know though is that this means non-sighted people who’d love to consume the newsletter quickly and navigate only the links will get a list of items called “link” – and nothing else. Instead of getting a list of items to try out – the reason for the newsletter – they get a surprise every time they activate one of the links. Even without going through the links list but using the tab key to go through them with a screenreader enabled it’s easy to realise that this is an issue. Check out the following screen recording.

Isn’t it great that the email link and the subscribe link tell me what to do?

Sadly, this problem isn’t uncommon. WebAIM checks the accesssibility of the one million most used web sites every year. And the result is that 17.3% of pages had ambiguous link text like “click here”, “continue” and similar ones that only make sense in context and otherwise are just a nuisance. Image you are lost in a huge department store and you see arrows pointing down to the ground everywhere telling you that “you are here”.

I am not saying that all links should be blue and underlined (or purple when they are visited), although there are good reasons for that, too, but I am simply baffled how the most natural thing that makes the web work – the link – is still something people keep trying to reinvent instead of just using what works.

Do you want to be inclusive and reach the largest possible number of readers out there? Use headings, use links that are unique and write sensible alternative text for all images you use. It isn’t magic, it’s common sense.

Letzte Woche hatte ich ein Interview mit einem Redakteur vom Deutschlandfunk zum Thema “KI und Softwareentwicklung” und am letzten Samstag lief der Beitrag im Radio. Hier gibt es die online version .

Ich bin zufrieden mit dem Ergebnis, ausser das der O-Ton das 90% der Software bald von Software geschrieben wird nicht von mir stammt sondern von Thomas Dohmke, CEO von GitHub .

Web developers nowadays have full insight into how browsers work. The engines are open source, and you have programmatic access to almost anything they do. You even have in-built developer tools allowing you to see the effects your code has. You can see what the render engine does and how much memory gets allocated.

With assistive technology like screenreaders, zooming tools and voice recognition you got nothing. Often, you even don’t have access to them without paying.

Closed source stalled the web for years

For years, closed browsers held back the evolution of the web platform. When I started as a web developer, there was IE, Netscape and Opera. The DOM wasn’t standardised yet and it was a mess. Your job as a web developer was to 90% knowing how which browser failed to show the things you tell it to. Another skill was to know hacks to apply to make them behave. Starting with layout tables and ending with hasLayout and clearfix hacks.

It is no wonder that when Flash came about and promised a simpler and predictable way to build web applications, people flocked to it. We wanted to build software products, not fix the platform whilst doing that.

This has been an ongoing pattern. Every time the platform showed slow-ish improvement due to browser differences, developers acted by building an abstraction. DHTML was the first bit where we created everything in JavaScript detecting support where needed. And later on jQuery became the poster child of abstracting browser bugs and DOM inconvenience away from you, allowing you to achieve more by writing less.

Open source browsers are amazing

Fast forward to now where every browser is based on some open source engine or another. Developers get more insight into why things don’t work and can contribute patches. Abstractions are used to increase developer convenience and to offer more full stack functionality than only showing a page. The platform thrives and there are new and exciting innovations happening almost every week. Adoption and implementation of these features is now in a several months timeframe rather than years. A big step here was to separate browsers from the OS, so you don’t need to wait for a new version of Windows to get a new browser version.

Assistive technology is amazing, but we don’t know why

And then we look at assistive technology and things go dark and confusing. If you ask most web developers how screenreaders work and what to do to enable voice recognition things get awry quick. You either hear outdated information or that people haven’t even considered looking at that.

Being accessible isn’t a nice to have. It is a necessity for software and often even a legal requirement to be allowed to release a product.

At Microsoft, this was a big part of my job. Making sure that our software is accessible to all. And this is where things got annoying quick.

There are ways to make things accessible and the best thing to start with is to use semantic HTML. When you use a sensible heading structure and landmarks, people can navigate the document. When you use a button element instead of a DIV, it becomes keyboard and mouse accessible. At least that’s the idea. There are several browser bugs and engine maker decisions that put a spanner in the works. But on the whole, this is a great start. When things get more problematic, you can use ARIA to describe functionality. And hope that assistive technology understands it.

I’ve been blessed with a dedicated and skilled team of people who bent over backwards to make things accessible. The most frustrating thing though was that we had a ton of “won’t fix” bugs that we could not do anything about. We did all according to spec, but the assistive technology wouldn’t do anything with the information we provided. We had no way to fix that as there was no insight into how the software worked. We couldn’t access it to verify ourselves and there was no communication channel where we could file bugs.

We could talk to the Windows Narrator team and fix issues there. We filed bugs for MacOS Voiceover with varying success of getting answers. We even submitted a patch for Orca that never got merged. And when it came to JAWS, well, there was a just a wall of silence.

Ironically, assistive technology isn’t very accessible

Every accessibility advocate will tell you that nothing beats testing with real assistive technology. That makes sense. Much like you can simulate mobile devices but you will find most of the issues when you use the real thing. But assistive technology is not easy to use. I keep seeing developers use a screenreader whilst looking at the screen and tabbing to move around. Screenreaders have complex keyboard shortcuts to navigate. These are muscle memory to their users, but quite a challenge to get into only to test your own products.

Then there’s the price tag. Dragon natural speaking ranges from 70 to 320 Euro. JAWS is a $95 a year licence in the US only, or a $1110 license for the home edition or $1475 professional license. You can also get a 90 day license for $290. So, I could use a VPN to hack around that or keep resetting my machine date and time, much like we did with shareware in the mid-90s?

I’ve been to a lot of accessibility conferences and kicked off the subject of the price of assistive technology. Often it is dismissed as not a problem as people with disabilities do get them paid by their employers or government benefit programs. Sounds like a great way to make money by keeping software closed and proprietary, right?

Well, NVDA showed that there is a counter movement. It is open source, built by developers who also rely on it to use a computer and responsive to feedback. Excellent, now we only need it to be cross-platform.

When you look at the annual screenreader survey, JAWS has 53.7% of the market, followed by NVDA at 30%. The assistive tools that come for free with the operating system are hardly used. Voiceover on MacOS is 6.5% of the users and Microsoft Narrator even 0.5%.

The reason why these newer tools don’t seem to get as much adoption is that people used JAWS for a long time and are used to it. Understandable, considering how much work it is to get accustomed to it. But it means that I as a developer who wants to do the right thing and create accessible content have no way to do so. If JAWS or Dragon Natural Speaking doesn’t understand the correct markup or code I create, everybody loses.

Access needs to me more transparent

I really would love open source solutions to disrupt the assistive technology market. I’d love people who can’t see getting all they need from the operating system and not having to fork over a lot of money just to access content. I want Narrator and Voiceover and Orca to be the leaders in innovation and user convenience. NVDA could be an open source solution for others to build their solutions on, much like Webkit and Chromium is for browsers.

But there is not much happening in that space. Maybe because it is cooler to build yet another JavaScript component framework. Or because assistive technology has always been a dark matter area. There is not much information how these tools work, and if my experience as a developer of over 20 years is anything to go by, it might be that this is by design. Early assistive technology had to do a lot of hacking as the operating systems didn’t have standardised accessibility APIs yet. So maybe there are decades of spaghetti code held together by chewing gum and unicorn tears people don’t want to show the world.

Generative AI is only as good as its integration in your work environment. GitHub Copilot Chat in Visual Studio Code is a great example how to do that right.

You can highlight code in the editor and press `CMD + I` on Mac or `Ctrl + I` on Linux/Windows and you get a text box to chat about this piece of code. For example, you can ask Copilot to explain it.

If you ask Copilot to modify the code, for example by asking it to add step-by-step instructions, it won’t replace the code immediately, but give you a diff view to see and change the recommendations before applying them.

Together with an extension to verify the validity of your code, like webhint this becomes a safe and thoroughly enjoyable way of working.

Generative AI is amazing – but good UX makes it even better.

As part of the WeAreDevelopers World Congress 2023, we did a quick session on starting out as a public speaker. To this end, I was asked to do a “Five things about public speaking” video. Here is the video and a write-up about the tips.

In the world of public speaking, engaging, informing, and delighting an audience is both an art and a science. If you’re a novice speaker ready to step onto the stage and into the spotlight, here are some tips.

Share Your Story

Every aspect of your talk should reflect who you are as an individual. Your slides, while offering informative visuals, are merely wallpaper lending a backdrop to your core message. Therefore, presentation success lies largely in your personal connection to the topic at hand.

Share your enthusiasm by explaining why the subject excites you, how you discovered it, and what resources you’ve used—all of which your audience can use later when they want do learn more about the topic.

How you learned about a topic, why it matters to you, and why it should matter to the audience, is the best way to bring something across.

Dealing with Nerves

While it’s perfectly natural to be nervous before a talk, it’s crucial to manage these emotions productively. Use this energy to fuel your performance on stage. If the anxiety feels overwhelming, open up about it—authenticity resonates with people.

Redirect your focus from potential judgement to your fundamental purpose: to show excitement and share knowledge.

Preparing for your Talk

Primarily, prepare by conducting thorough research to master your content. Find something current and relative to your topic to serve as a hook for your audience, demonstrating the immediacy and relevance of what you’re discussing.

Secure your presentation by making sure all your demos and materials function offline and are accessible to your audience afterwards. Familiarise yourself with the technological equipment available to avoid overcomplicating or failing demonstrations.

It is highly important to learn about your audience and cater your presentation to their needs. Aim to provide them with a key takeaway they can use to impress their superiors.

Do’s and Don’ts

Do’s

1. Tell Stories. Make the subject human and exciting, and point to materials where your audience can learn more.
2. Limit Yourself. Instead of overwhelming the audience with excessive amounts of information, focus on delivering one key point exceptionally well.
3. Use Clear and Simple Language. Avoid showing off your mastery over sophisticated vocabulary and instead strive to be comprehensible to your audience.

Don’ts

1. Take all the credit. Give credit where it’s due, acknowledging the people from whom you’ve learned.
2. Read out your slides to the audience. You’re not an audience member but the show-runner. The human factor in a presentation is what can’t be digested from simply reading a slide.
3. Try to be funny for the sake of being funny. Humor is great, but only when it doesn’t become a distraction from your main message.

Harness the Unexpected

During one of my keynotes on machine learning, a power outage left me delivering my message in the dark, and later, my slides appearing in an unintended random order. Instead of panicking, I leveraged these mishaps to emphasise the unreliability of machines—ironically, the exact message I had come to share.

Remember, when unexpected situations arise during your talk, flip them to your advantage. Owning your story and being an expert on your content equips you for effectively dealing with any hurdles that may occur on stage.

In conclusion, successful public speaking requires substantial preparation, an understanding of your audience, and most importantly, a genuine passion for your topic. Serve as a guide to your audience by threading a story throughout your presentation, and never lose sight of why the subject holds significance for both you and your listeners.

We are looking for presenters!

If you want to start as a public speaker, remember that WeAreDevelopers has a “live” video series and we are looking for presenters. Check out the WeAreDevelopers live site and the call for papers .

This post has partly been created using VideoTap .