Navigating the age-old problem of checkmarks in UI with progressive enhancement

This means that ::checkmark , as simple, powerful, and useful as it is, is still very limited, and that’s a problem. So, do we rely on the traditional solutions we used to use in the past to style checkmarks? Are they better? In this article, we will be exploring how the problem of customised checkmarks was solved in the past and compare those solutions with the modern ::checkmark solution, providing recommendations as we go.

How we’ve traditionally approached checkmarks in menus

To create and style a traditional checkmark similar to the ones you see in elements under , first, we would create a custom dropdown to house the checkmark. To do that, we would have to consider a bunch of interactive states and rules. Your browser doesn’t provide these with non-semantic elements, so taking a few notes from Sandrina’s article, we need to have:

• A dropdown with the current selected option
• Box toggling ability to toggle the visibility of the options
• Clicking an option in the list updates the dropdown value. The dropdown text changes, and the list MUST be closed
• Clicking outside closes the list
• A customizable select dropdown icon to represent our picker
• A customizable select checkmark icon to represent our checkmark for any selected option

Here’s how our HTML would likely look:

    

      ::before
      ▼
    
    
    /* list menu */
    

      

        ✓
        ::before
          
        
      

        ✓
        ::after 
        
      

        ✓
        ::marker  
        
      

        ✓
        ::selection
        
        
      

        ✓
        ::placeholder
        
    
  

And our main CSS for the dropdown would look something like this:

/* position property sets the list dropdown menu to be centered and non-clickable, just below the button that reveals it*/
.cs-menu {
  position: absolute;
  top: calc(100% + 0.4rem);
  left: 0;
  right: 0;
  background: var(--surface);
  border: 1px solid var(--border);
  border-radius: 0.5rem;
  padding: 0.3rem;
  z-index: 20;
  box-shadow: 0 1.5rem 3rem oklch(0% 0 0 / 0.55);
  opacity: 0;
  transform: translateY(-0.4rem);
  pointer-events: none;
  transition: opacity 0.15s, transform 0.15s;
}

/* this reveals the menu list when the dropdown menu button is clicked if data-open attribute is present. It is hidden otherwise */ 
#cs[data-open] .cs-menu {
  opacity: 1;
  transform: translateY(0);
  pointer-events: all;
}

/* you can use flex here instead of grid. Just follow the pattern stated */
.item {
  display: grid;
  grid-template-columns: 1.2rem 1fr;
  align-items: center;
  gap: 0.65rem;
  padding: 0.6rem 0.75rem;
  border-radius: 0.4rem;
  cursor: pointer;
  transition: background 0.1s;
}
.item:hover {
  background: var(--hover);
}
.item[data-sel] {
  background: oklch(75% 0.18 55 / 0.08);
}

.label {
  font-size: 0.88rem;
  color: var(--muted);
  transition: color 0.12s;
}
.item[data-sel] .label {
  color: var(--accent);
}

/* checkmark over here 🙋‍♂️ */
.checkmark {
  justify-self: end;
  font-size: 0.75rem;
  font-weight: 700;
  color: var(--accent);
  visibility: hidden;
}
.item[data-sel] .checkmark {
  visibility: visible;
}

In essence, we’re using position absolute to remove the element from the normal document flow and hide it from the user. revealing the menu only when the dropdown is clicked. Then, we’re using grid to align and arrange the items in the dropdown menu.

Finally, we style the checkmark to be hidden by default on all list items, and only the selected item should reveal the checkmark, indicating it has been chosen!

Ah yes! That should be all, right?

All this code should make sure the dropdown and checkmark work as intended, fulfilling the requirements stated above. Surely, it works without JavaScript (JS). But, enough sarcastic talk, let’s see the result…

See the Pen The dilemma of custom select dropdown with checkmarks: no js, a problem by Andy Bell (@piccalilli) on CodePen.

Notice something not working? Yes, the dropdown is not working. Why? It’s because there’s no JS to provide the interactivity!

That’s a big issue with solutions like this because JS is required for them to work, and JS will fail for your users. Warnings about best practice aside, let’s provide some interactivity to at least get this sample working.

const cs = document.getElementById("cs");
const btn = document.getElementById("cs-btn");
const lbl = document.getElementById("btn-lbl");
const items = document.querySelectorAll(".item");

btn.addEventListener("click", () => cs.toggleAttribute("data-open"));

items.forEach((item) =>
  item.addEventListener("click", () => {
    items.forEach((x) => x.removeAttribute("data-sel"));
    item.setAttribute("data-sel", "");
    lbl.textContent = item.dataset.v;
    cs.removeAttribute("data-open");
  })
);

document.addEventListener("click", (e) => {
  if (!cs.contains(e.target)) cs.removeAttribute("data-open");
});

See the Pen Custom dropdown using grid/flex with position property by Andy Bell (@piccalilli) on CodePen.

We are missing two important points. What about accessibility and users who want to navigate via keyboard?

We will have to modify the HTML with some aria-haspopup , aria-expanded, aria-selected, role, tab-index, and aria-label . That would sort out our HTML accessibility dilemma. The code would look a lot like this. Setting it up this way from the start, although tedious, would ensure checkmarks in our dropdowns work as intended for all users:

	

		
      
        ::before
        ▼
      
      
      
      

        

          ✓
          ::before
        
        
        

          ✓
          ::after
        
        
        

          ✓
          ::marker
        
        
        

          ✓
          ::selection
        
        
        

          ✓
          ::placeholder
        
      
    
  

Then, for our JavaScript, that will be modified a bit from what you saw earlier. We would have to account for when the user uses the directional arrows up and down, and when they click enter and esc to navigate the dropdown and click on any option.

const cs = document.getElementById("cs");
const btn = document.getElementById("cs-btn");
const lbl = document.getElementById("btn-lbl");
const items = [...document.querySelectorAll(".item")];

let selected = items.find((i) => i.hasAttribute("data-sel"));

function open() {
  cs.setAttribute("data-open", "");
  btn.setAttribute("aria-expanded", "true");
  (selected ?? items[0]).focus();
}

function close() {
  cs.removeAttribute("data-open");
  btn.setAttribute("aria-expanded", "false");
  btn.focus();
}

function select(item) {
  selected?.removeAttribute("data-sel");
  selected?.setAttribute("aria-selected", "false");
  item.setAttribute("data-sel", "");
  item.setAttribute("aria-selected", "true");
  selected = item;
  lbl.textContent = item.dataset.v;
}

btn.addEventListener("click", () =>
  cs.hasAttribute("data-open") ? close() : open()
);

btn.addEventListener("keydown", (e) => {
  if (e.key === "ArrowDown") {
    e.preventDefault();
    open();
  }
});

/* accounting for keyboard up, down, enter and esc for the dropdown */
items.forEach((item) => {
  item.addEventListener("click", () => {
    select(item);
    close();
  });
  item.addEventListener("keydown", (e) => {
    const i = items.indexOf(item);
    if (e.key === "ArrowDown") {
      e.preventDefault();
      items[(i + 1) % items.length].focus();
    }
    if (e.key === "ArrowUp") {
      e.preventDefault();
      items[(i - 1 + items.length) % items.length].focus();
    }
    if (e.key === "Enter" || e.key === " ") {
      e.preventDefault();
      select(item);
      close();
    }
    if (e.key === "Escape") close();
  });
});

document.addEventListener("click", (e) => {
  if (!cs.contains(e.target)) close();
});

That’s a lot of JavaScript! And essentially, what I’m doing is accounting for when a user clicks the down arrow button on their keyboard, which can be used to expand the dropdown and also browse downwards through the options. The up arrow key inside the dropdown can be used to navigate up, enter selects the item, and esc leaves the dropdown.

See the Pen custom dropdown using grid/flex with position property by Andy Bell (@piccalilli) on CodePen.

Let’s also not forget the accessibility toggles that let the screen reader know that the dropdown has been expanded or that an item in the dropdown list has been selected.

This approach is how many developers have tackled the problem at hand before and here two key reasons why it is not the best solution:

1. When JS fails, the whole solution is dead. Not even a glimmer of hope is here. No JavaScript means no interaction and the markup we added likely ends up creating even more problems for people using assistive technology
2. Every single browser behavior has to be unnecessarily implemented from scratch. From option focusing, to accounting for what happens when the user clicks the button to expand and close the dropdown and also clicks outside of the dropdown to close it, has to be implemented

In essence, this solution is fragile and unreliable due to its over-reliance on JS. What’s more? Our checkmark styles are nonexistent if the dropdown cannot be revealed!

So, how do we solve these issues? Luckily, there’s a far less “heavy code” intensive solution that allows us to do style checkmarks anyhow we like.

Modern day ::checkmark styling

The CSS ::checkmark is a pseudo-element that allows us to apply styles to HTML elements that support a checkmark. It really helps remove the hassle of writing a bunch of HTML, CSS, and JS in order to make things work as they’re supposed to. Let’s take a custom dropdown and a checkmark designed using ::checkmark.

Take for example, this

dropdown:

	CSS
	JavaScript
	HTML
  TypeScript
  Rust