“html” Articles

It’s common for a table design to feature alternating row colors, which is pretty trivial to accomplish with CSS. But then if you need to hide some rows later, the striped background gets all messed up.

Or at least it used to. It turns out I completely slept on a cool CSS feature that makes this a non-issue.

Have you ever had to implement a modal dialog with a close button designed to hang off of the corner?

While not a huge lift for most developers, there’s a few steps involved. It also requires extra care to avoid accessibility gotchas. I did this recently and wondered if there was a simpler approach using modern CSS.

Something I started doing lately is using the padding of a <label> element to create the space between it and an <input> instead of a margin or grid/flexbox gap. I’m sure a bunch of people already do this, but it’s something that only recently dawned on me.

The <table> element is one of the oldest and most-common elements on the web. But it's also been long overlooked in terms of receiving new CSS features and quality-of-life improvements, unlike other elements that tend to get more love and attention.

I think it's time for the <table> element to get a few CSS improvements of its own. Here's three features that I'd like to see.

I know it’s been awhile (*checks notes* wow, almost two years!), but I’m finally back with the next article in my “screen readers and drag-and-drop” article series. Here, I’ll be diving into how to convey to screen reader users when an element has been picked up or put down. Ideally, I’ll be able to identify at least a few approaches to prototype into full patterns to test later.

Most screen reader users have limited to no vision and will miss visual cues showing an item’s been grabbed. So it’s important to communicate these actions programmatically as well so that everyone can perceive the interaction.

I recently needed to test the support of a dynamic accessible description – a element’s description that is initially one (or no) value, then changes to another value after an action takes place.

I created a page of examples to test and a document to record my findings, but then realized that I could just make this a blog post that I periodically update. That way, others can use it as a reference as well, if they choose.

Recently, I added a dark mode setting to my website. Dark mode is a color theme feature that’s pretty common these days. Letting users adjust the color of content so it’s easier to see is a nice usability improvement.

Many developers I follow have written great articles about their implementations, which are full of valuable insight. To name a few: Hidde de Vries, Sarah Fossheim, and Josh Comeau all have smart approaches with valuable takeaways.

However, I decided to take a slightly different approach than a lot of the solutions I’d seen – a progressively-enhanced version that works with or without JavaScript (JS).

The other day I was skimming Webkit’s Safari Technology Preview 153 release notes and noticed that they had added support for aria-description.

I always found it odd that developers could set an element’s accessible name/label with the aria-label and aria-labelledby attributes, but only had aria-describedby for setting accessible descriptions. So seeing aria-description being added to Safari was an interesting surprise.

I decided to do a mini dive and test of support for aria-description to fill in my knowledge gap and be prepared to use it when the time comes. A sort of crash-course, if you will. I’m sharing my findings here in case it’s valuable for anyone else.

I’ve been using the HTML Drag and Drop API (DNDAPI) a fair amount lately, which is a native way to build draggable interfaces. Despite some quirks, it works pretty well – making it easy for developers to create drag-and-drop functionality.

But the DNDAPI has a big flaw: there’s no built-in accessibility features. This means screen reader users (and many others) won’t be able to use interfaces built with it without a lot of mindful, additional work from developers (which, let’s face it, most don’t do).

Last year, I worked on a project which contained a reorderable list component – essentially, a group of items that users can rearrange in any order. Though I had no prior experience designing such a pattern, the end result worked well for our purposes. But I was sure that my lack of familiarity meant that there were improvements to the usability and experience that I could implement for the future.

As a result, I dove deep into the pattern – learning, creating, and testing versions of it to deduce as much as I could. In this article, I'm going to channel my findings into how we can create a reorderable list with a great user experience (UX).

The title element is often one of the first elements covered when learning HTML. But because changing a page’s title is trivial, many website creators mistakenly view it as optional or purely decorative, leaving it neglected. But the truth is that the title is a functional element that aids users in a variety of situations.

This is part 2 of an article series on the title element, where we’ll review some best practices that give a title its meaning and usefulness.

The title element is often one of the first elements covered when learning HTML. But because changing a page’s title is trivial, many website creators mistakenly view it as optional or purely decorative, leaving it neglected. But the truth is that the title is a functional element that aids users in a variety of situations.

This is part 1 of an article series on the title element. Here, we’ll look at what this element is and does, and how it affects a user’s experience.