DEV Community: Christian Heilmann

Accessibility question: is nesting interactive elements bad?

Christian Heilmann — Wed, 27 May 2026 14:09:19 +0000

I am currently writing a gallery script for myself and ran into an interesting accessibility question. I have a list of galleries with links to each of them. I also wanted to provide a checkbox to allow users to select several galleries and merge or download them. The HTML I use is the following. An unordered list with labels and checkboxes and links inside the label.

<ul>
    <li><label>
        <input type="checkbox" name="edit" value="Cats">
        <a href="index.php?gallery=Cats">Cats</a>
    </label></li>
</ul>

Given the right CSS and some breathing space this works well with a mouse and keyboard. You can click next to the link to check the checkbox and on the link to navigate to the gallery. It also works using a keyboard. You can tab through the list and check/uncheck using the space bar. The following screencast shows what that looks like.

Now, it feels wrong though. I am mixing two interaction modes here, navigation and selection, one being link based and the other form based. I am wondering if that creates any issues for screenreader users. The other thing I am wondering about is if there is an issue with nesting all in the label as some older assistive technology didn't like that. I can work around that using for and ids:

<ul>
    <li>
        <input id="CBDucks" type="checkbox" name="edit" value="Ducks">
        <label for="CBDucks">
            <a href="index.php?gallery=Ducks">Ducks</a>
        </label>
    </li>
</ul>

The question though is if that is still an accessibility issue and if it doesn't make more sense to show the navigation as links and create a toggle to switch to the selection use case? What do you think?

You can play with the demo page here.

Abandonware of the web: did you know that there is an HTML tables API?

Christian Heilmann — Wed, 08 Oct 2025 14:20:09 +0000

When people turn data into HTML tables using JavaScript, they either use the DOM methods (createElement and the likes), but most of the time just append a huge string and use innerHTML, which always is a security concern. However, did you know that HTML tables also have an old, forgotten API? Using this one, you can loop over tables, create bodies, rows, cells, heads, footers, captions an summaries (yes, HTML tables have all of those) and access the table cells. Without having to re-render the whole table on each change. Check out the Codepen to see how you can create a table from a nested array:

let table = [
  ['one','two','three'],
  ['four','five','six']
];
let b = document.body;
let t = document.createElement('table');
b.appendChild(t);
table.forEach((row,ri) => {
  let r = t.insertRow(ri);
  row.forEach((l,i) => {
    let c = r.insertCell(i);
    c.innerText = l;  
  })
});

You can then access each table cell with an index (with t being a reference to the table):

console.log(t.rows[1].cells[1]);
// => <td>five</td>

You can also delete and create cells and rows, if you want to add a row to the end of the table with a cell, all you need to do is:

t.insertRow(-1);
t.rows[2].insertCell(0);
t.rows[2].cells[0].innerText = 'foo';

There are a few things here that are odd - adding a -1 to add a row at the end for example - and there seems to be no way to create a TH element instead of a TD. All table cells are just cells.

However, seeing how much of a pain it is to create tables, it would be fun to re-visit this API and add more functionality to it. We did add a lot of things to HTML forms, like formData and the change event, so why not add events and other features to tables. That way they'd finally get the status as data structures and not a hack to layout content on the web.

A CSS only time progress bar to use in markdown / GitHub Pages

Christian Heilmann — Fri, 05 Sep 2025 06:44:10 +0000

For our weekly WeAreDevelopers Live Show I wanted to have a way to include a time progress bar into the page we show. The problem there was that these are markdown files using GitHub Pages and whilst I do use some scripting in them, I wanted to make sure that I could have this functionality in pure CSS so that it can be used on GitHub without having to create an html template. And here we are.

You can check out the demo page to see the effect in action with the liquid source code or play with the few lines of CSS in this codepen. Fork this repo to use it in your pages or just copy the _includes folder.

Using the CSS time progress bar

You can use as many bars as you want to in a single page. The syntax to include a bar is the following:

{% include cssbar.html duration="2s" id="guesttopic" styleblock="yes" %}

The duration variable defines how long the progress should take
The id variable is necessary to and has to be unique to make the functionality work
If the styleblock is set, the include will add a style with the necessary css rules so you don't have to add them to the main site styles. You only need to do that in one of the includes.

Using the bar in HTML documents

You can of course also use the bar in pure HTML documents, as shown in the codepen. The syntax is:

<div class="progressbar" style="--duration: 2s;">
    <input type="checkbox" id="progress">
    <label for="progress">start</label>
</div>

Don't forget to set a unique id both in the checkbox and the label and define the duration in the inline style.

Drawbacks

This is a bit of a hack as it is not accessible to non-visual users and abuses checkboxes to keep it CSS only. It is keyboard accessible though.
In a better world, I'd have used an HTML progress element and styled that one…

Derpify.js – a tool for these trying times…

Christian Heilmann — Mon, 27 Jan 2025 13:59:51 +0000

As the times we live in demand it, I released Derpify.js. It is an npm package (3 line method) that turns strings into strings that are randomly mixed upper and lower case.

console.log(derpify('All he wanted to say was I love you all.'))

gives you:

ALL hE WANTed to SAY WAS I lOVe YoU AlL.

Get it:

Learning HTML is the best investment I ever did

Christian Heilmann — Wed, 15 Jan 2025 16:16:54 +0000

One of the running jokes and/or discussion I am sick and tired of is people belittling HTML. Yes, HTML is not a programming language. No, HTML should not just be a compilation target. Learning HTML is a solid investment and not hard to do.

I am not alone in this, Wired had a piece on HTML being a programming language and even for RAG training HTML makes a lot more sense than text.

HTML structures our content, makes it easier to index and gives us tons of accessible and easy to use interface elements. And it is straight forward to learn. The syntax is clear and the rules are only a few. And yet, nobody seems to even bother to look those up.

In last week's Bytes newsletter there was a "spot the bug" challenge that looked like this:

<main>
  <form onsubmit="handleSubmit(event)">
    <fieldset>
      <label for="name">Name:</label>
      <input type="text" name="name" value="Tyler"  />
      <label for="age">Age:</label>
      <input type="number" name="age" value="33" />
      <button>Submit</button>
    </fieldset>

  <hr />

  <form onsubmit="handleSubmit(event)">
    <fieldset>
      <label for="company">Company:</label>
      <input type="text" name="company" value="ui.dev"  />
      <label for="employees">Employees:</label>
      <input type="number" name="employees" value="33" />
      <button>Submit</button>
    </fieldset>
  </form>

  <script>
    function handleSubmit(event) {
      event.preventDefault();
      const formData = new FormData(event.target);
      alert([...formData.entries()]);
    }
  </script>
</main>

The bug described was that as the first form wasn't closed, the script got the wrong content. But there is so much more in this small amount of HTML that is wrong, it made me flinch.

Fieldsets need legends

It uses fieldsets without legends - why? The idea of a fieldset is to to group form elements and give that group a name. If you omit the name, all you did was paint a hard to style border around them.

Pointless labels

It uses labels, which is a happy surprise, but fails to connect them to the right form elements. For a label to describe a form element, you need the element to connect to an ID, not a name. A name attribute is not unique, instead it clusters form elements together. So, you could have a few elements with the same name, but you need to have an ID on each to connect it to the label. When the form gets submitted, the names become form data (or URL parameters), the IDs are there for HTML parser internal use. And more. IDs are the few multi-dimensional things on the web, as they can be accessed via the browser (hash at the end of the URL), they connect HTML elements together (a link pointing to it, or a label with for), they are easy to use in CSS and in DOM scripting. One weird thing is that every element with an ID also becomes a global JavaScript hook on the window. This is a convenience method of browsers, not a standard though.

A great example of this is a radio group. I hardly see those in use, but they are a great way to offer a "pick one of many" interface without needing any JavaScript.

Check this Codepen to see a radio group in action.

<fieldset>
    <legend>Record Label</legend>
    <p><input name="recordlabel" type="radio" value="Trojan" id="company1">
    <label for="company1">Trojan</label></p>
    <p><input name="recordlabel" type="radio" value="Epitaph" id="company2">
    <label for="company2">Epitaph</label></p>
    <p><input name="recordlabel" type="radio" value="Hellcat" id="company3">
    <label for="company3">Hellcat</label></p>
    <!-- … -->
</fieldset>

Notice that the name of the ID can be random, but needs to be unique, whereas the name makes sense to be human readable. This is even part of the specification:

Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute.

As an extra, activate the Toggle checkbox/radio button to see that simply by changing the type attribute of an HTML input, you can allow users to either submit one or several values. By using properly connected labels, we also allow users to click/tap/hit space on the whole text to select instead of having to hit the small radio control.

HTML was and is fun!

HTML is - dare I say it - fun to me. The reason is that I started a long time ago. Building my first web site instead of creating things with Visual Basic or C builder was amazing. HTML appeared to me all powerful. I didn't have to spend any money, install and understand a development environment. All it needed was an index.html file and writing the code using a text editor that came with the OS. I went to htmlhelp.com and downloaded the HTML spec as a zip and put it on a floppy to look things up. I was only online at work, my home internet connection came a lot later.

Unforgiving browsers

In the early days, making HTML mistakes was a problem as browsers would punish you for it. Netscape would not render tables that weren't closed. And back then tables was the only way to create complex layouts. This was a bad use of HTML as it was non-semantic, but we had nothing else.

Later, when CSS became a thing there was still a lot of interference of HTML in the final product. Whitespace should not make a difference in HTML but it caused a lot of extra space in table cells and with images. The best advice I would give to designers back then that banged their head on the desk was to validate their HTML. The HTML Validator became my power tool to fixing issues for clients.

These days, HTML gathers less interest as with the HTML5 parser, things became a lot more lenient.

A lack of HTML interest and respect

As browsers bend over backwards to fix broken HTML, developers stopped caring about it. If it doesn't break the build, it's less important than getting those JavaScript packages bundled. But this, to me, is lazy development. Why rely on a platform to fix bugs that we could avoid if we put in a tiny bit of effort?

HTML has some exciting new features for us in 2025. A single element could replace a whole component library. Sure, the component might give us more predictable styling and more control. But it also is one more dependency, and could be a security, performance and maintenance issue. An issue we can't fix as we don't control it.

No matter how you create things for the web, the end product will be HTML. Either HTML generated on the server or with JavaScript. With AI search bots not rendering JavaScript yet maybe this is a good time to re-learn what HTML can do for you. It has not let me down in over 25 years, whereas lots of other "magical solutions" did.

trimMiddle() - the missing String trim method

Christian Heilmann — Fri, 03 Jan 2025 15:37:01 +0000

One of the cool features of MacOS' Finder app is that it does not trim file names that don't fit the space at the end, but in the middle of the file name. This does make a lot more sense, as it also shows what format the file is.

Neither JavaScript nor CSS have a method for that kind of functionality at the moment (although there is a CSS discussion on the matter), so I thought I write one. I give you trimMiddle() as an addition to trimStart and trimEnd.

You can find it:

On NPM: https://www.npmjs.com/package/trimmiddle
On GitHub: https://github.com/codepo8/trimMiddle

and you can play with the demo page to see it in action:

To use it in your own products, either use npm -i trimmiddle or use the client-side version via unpkg.

<script src="https://unpkg.com/trimmiddle@0.1.0/clientside.js"></script>

The method allows you to define the amount of letters you want to show and what the character in between the parts should be. Default is 16 characters and the ellipsis character. The script uses the Intl.Segmenter API when the string is longer than the character limit, which means that it also works with strings containing compound Emoji. The normal split or substring methods fail in this case.

What’s your excuse for not using the web share API?

Christian Heilmann — Sat, 16 Nov 2024 11:48:45 +0000

The WebShare API is so easy to use, it is a crime people don't use it more. Instead, we have tons of dead "share on $thing" buttons on the web. Many of which spy on your users and lots of them that started as Wordpress plugins but now are security concerns. Instead of guessing how your visitors want to share the current URL or a file you provide, you can call the API and they can pick their favourite:

This is the code and you can also check it on codepen:

let shareButton = document.querySelector('button');
shareButton.addEventListener("click", async () => {
  try {
    await navigator.share({ title: "Example Page", url: "" });
    console.log("Data was shared successfully");
  } catch (err) {
    console.error("Share failed:", err.message);
  }
});

An empty url means the current document is shared. You can also add a different title, which makes more sense than "Example page".

httpstat.us is a great service to test your APIs and scripts

Christian Heilmann — Fri, 15 Nov 2024 13:30:06 +0000

Just discovered https://httpstat.us which returns a HTTP response you request. You can request by number, like:

https://httpstat.us/404

Randomly from a range and/or list:

https://httpstat.us/random/400-410,202,200

And you can set a timeout in ms:

https://httpstat.us/200?sleep=3000

Movie industry facts

Christian Heilmann — Sat, 05 Oct 2024 17:51:20 +0000

const Marvel = ['Lights','Camera','Action'];
const DC = Marvel.slice(1);

Quick tip: using flatMap() to extract data from a huge set without having to write a loop

Christian Heilmann — Fri, 06 Sep 2024 12:00:34 +0000

I just created a massive dataset of all the AI generated metadata of the videos of the WeAreDeveloper World Congress" and I wanted to extract only the tags.

The dataset is a huge array with each item containing a description, generated title, an array of tags, the original and their title, like this:

{
  "description": "The talk begins with an introduction to Twilio…", 
  "generatedtitle: "Enhancing Developer Experience: Strategies… ",
  "tags": ["Twilio", "DeveloperExperience", "CognitiveJourney"],
  "title": "Diving into Developer Experience"
}

What I wanted was an alphabetical lost of all the tags in the whole dataset, and this is a one-liner if you use flatMap():

data.flatMap(d => d.tags);

You can sort them alphabetically with sort():

data.flatMap(d => d.tags).sort();

And you can de-dupe the data and only get unique tags when you use Set():

new Set(data.flatMap(d => d.tags).sort());

You can try this in this codepen.

No more "Expert, Intermediate, Beginner": Classifying talks in Call for Papers/Conference agendas

Christian Heilmann — Fri, 06 Sep 2024 05:55:08 +0000

I am currently working on creating the new Call for Papers for the next WeAreDevelopers World Congress and one of the feedback items we got was that levels like "Expert, Intermediate and Beginner" don't make much sense. First of all, speakers do not choose the right level as they are worried that a beginner or expert talk will not attract enough audience. Secondly, attendees might feel peer pressure to not watch the "beginner" talk, as that might be more suited to be a workshop.

So I thought that instead of levels, I ask speakers for classifications:

Case Study - "How we use Kololores.js in company Blumentopferde and how it made us 30% more effective"
Deep Dive - "Looking under the hood of Kokolores.js and why it works so well"
Technology Introduction - "How Databaserandomising will change the way you think about structured databases"
Tool Explanation - "Taking the pain out of Kokolores.js with Pillepalle - a visual interface and API to get you started quicker"
Thought Piece - "Kokolores.js isn't the answer - we need to approach this in a different way"
Expert Advice - "How we scaled Kokolores.js to 231242 users and what to look out for"
Level Up - "So you started using Kokolores.js - here is how to become more efficient with it"
Learnings - "How we got rid of Kokolores.js and what it meant for our users"
Creative - "Did you know you can use Kokolores.js to do Pillepalle?"

This should make it easier for audiences to pick a talk without having to value themselves. What do you think?

The best carb.js

Christian Heilmann — Tue, 03 Sep 2024 13:03:29 +0000

Array.from(+{}+'')
    .map((_,$)=>$>=1?_.repeat(2):_.toLowerCase())
    .reverse().join('')
.slice(1,5);