DEV Community: Andrew K

Medium Zoom Next - JS library for image zooming

Andrew K — Mon, 22 Sep 2025 17:13:19 +0000

I rewrote and published a library for image zooming like in Medium. It’s Framework agnostic, small, dependencies free, and now (more or less) modern. The original library seemed to be abandoned for a few years now, and I needed some changes in it for my portfolio website, so I took it in my own hands.

The changes include, but are not limited to, adding a new method to swap zoomed images, updating event handlers to allow pinch-to-zoom on touch screens, rewriting to TypeScript, and modernizing the setup by changing most of the libraries and workflows.

https://github.com/SpasiboKojima/medium-zoom-next

I’ll be glad for any feedback!

A full changelog with some explanations is here:
https://github.com/SpasiboKojima/medium-zoom-next/pull/2

7 Easy UX Improvements for your Webapp

Andrew K — Wed, 18 Jun 2025 09:45:00 +0000

Introduction

Finishing my series of articles, I decided to wrap it up with a list of simpler tricks from my experience spanning across different aspects of web development, tricks not big enough for a separate article. With their own caveats, these are generally safe to just slap with a few lines of code and a little familiarization of said caveats.
As always, the topics cover the gap designers usually don't cover and developers usually don't notice.

Transitions with AutoAnimate

One of the harder things to animate are lists of items, especially when they are spanning across 2 axes. That's where @formkit/auto-animate shines the most - with a single line of code you can add some much-needed transitions to when an item gets moved, added, or deleted. Transitions that will help in visually indicating to users what exactly has changed.

With only 2.9kB gzipped, it offers a zero-config, drop-in animation utility that has many use cases, such as animating accordions and input errors, and bundles support not only for Native JS but for React, Solid, Vue, Preact, Svelte, and Angular as well. The transition animation is customizable and respects the prefers-reduced-motion setting. You can find more on it in the docs.

<script type="module">
  import autoAnimate from './js/autoAnimate.js'
  const dropdown = document.getElementById('list-container')
  autoAnimate(dropdown)
</script>

I personally used it in a few production React apps for accordions, input errors, and lists, and it worked 9/10 times (due to layout specifics).

Target size

A topic I have a whole article about is a practice to make interactive elements easy enough to click/touch by increasing their size. There's a WCAG standard, and a good size to aim for is 44x44 CSS pixels. There are a number of situations, and in the simplest case with single elements, you can just add necessary extra padding to them, and to counteract the layout shift, you can apply a similar negative margin. With Tailwind it will look like just -m-4 p-4, and with CSS:

.target-element {
  margin: -16px;
  padding: 16px;
}

In other cases, you might want to include other elements with your target element by using <label>. A situation I've seen many times neglected, leaving tiny checkboxes the only part that can be clicked to toggle them.

Why is it important? Because accessibility is all about making interfaces usable in a wider range of conditions, and these can be not only health-related specifics but also an inconvenient environment, like shaking transport or malfunctioning touch devices.
With just a few lines of code, we can expand the accessibility of our app in these conditions. And of course, it will be just a little more pleasant to use for everyone else.

Virtual keyboard shapes

Just like there are multiple types of inputs for collecting different types of data, there are different shapes a virtual keyboard can take to assist in entering this data. Virtual keyboards are used not only on mobile phones and tablets but also on laptops equipped with touchscreens.
Now there are 3 attributes that can actually affect the virtual keyboard presented to the user, and 2 of them are specifically meant for this.

Input's type attribute defines the shape of the input and what type of value it expects. While user agents may assume appropriate inputmode based on that with values like tel, url, and email, sometimes it may not be exactly what you want. And at least on iOS it handles numeric values differently (notice the lack of emoji button at the bottom).

iOS keyboard with type="number"

inputmode attribute is exactly for this, with values like "tel" | "url" | "email" | "numeric" | "decimal" | "search" it allows you to specify the appropriate virtual keyboard without affecting anything else.
enterkeyhint defines what action label (or icon) to present for the enter key on virtual keyboards. It accepts only predefined values like 'enter' | 'done' | 'go' | 'next' | 'previous' | 'search' | 'send', and the actual displayed result depends on user agent implementation. Keep in mind that just like inputmode this is only a hint - the actual logic for something like next and previous will have to be implemented separately.

inputmode="email" + enterkeyhint="search"

Keyboard shortcuts

If your interface involves a sequence of repetitive actions, shortcuts are a great way to speed things up. With a lack of standards, it might be a little hard to come up with a combination that would be intuitive to use and easy to remember. With the amount of browsers and OSs, it might be hard to find a combination that hasn't already been taken. Ideally, we would need to match a hotkey that will already be associated with the corresponding action from the previous user's experience. After all, your users are also interacting with dozens of other interfaces besides yours. That is, it seems to be acceptable to override browser/system shortcuts, but with a lot of considerations (to allow remapping or disabling them).

Notion's list of keyboard shortcuts

Let's try to cover the most common and generally safe ones:
Esc - Close modal/dialog, cancel action. <dialog> supports it out of the box.
Enter, Ctrl + Enter / Cmd + Enter – Submit (send message, submit form, etc.). With the <form> element, you can get submit on Enter automatically inside inputs, but you might want to add this manually for <textarea>.
↑↓ - a little special usecase built in <input type="number" />, make sure you don't lose it if you are handling numbers.
Ctrl + K / Cmd + K - becomes more common to use for search or command palette, seemingly started by Slack. There are libraries for components that come with this shortcut now.
Ctrl + / – Also command palette or help menu.
Formatting hotkeys (Ctrl + B, Ctrl + I, Ctrl + U) - some text editor libraries already come with them. Usually these are okay to override reserved combinations, assuming that the user easily unfocuses the editor to lose the override.

Now you can actually add event listeners to the whole page or just to the element you want your shortcuts to take effect in. Make sure to handle both Windows and macOS special keys. e.preventDefault() here is to stop the default behavior of the hotkey.

document.addEventListener('keydown', (e) => {
  if (e.key === 'k' && (e.metaKey || e.ctrlKey)) {
    e.preventDefault();
    openSearchBar();
  }
});

<form
  onKeyDown={(e) => {
    if (e.key === 'k' && (e.metaKey || e.ctrlKey)) {
      e.preventDefault();
      openSearchBar();
    }
  }}
>
  {...}
</form>

View Transitions

With hardware advancement and increasing internet speed, web apps are also bulkier and can still have a noticeable loading process for switching between pages, usually accompanied by an empty screen. To reduce perceived loading latency, we can add a smooth transition there, and to do that, the easiest way would be to use the View Transitions API.
View Transitions can be used for both MPA to transition between pages and SPA for changes to parts of the DOM. It ensures that any element that’s getting unchanged stays exactly in place, with no blinks, and the changing elements transition in a crossfade.

View Transitions are supported by most of the browsers (82% at the time), and you can start using them for page navigation today as progressive enhancement. These 2 lines of code are all you need for a start, before you decide to customize the transition animation and manipulate the view transition itself which the API also allows.

@view-transition {
  navigation: auto;
}

Skip links

The standard way of putting navigation links on the web is at the very top of every page, right before the main content. Where a mouse or touchscreen user could just point straight down, a keyboard user has to grind through this repeated content that can have dozens of entries before they can get to the primary part. For the purpose of getting straight to the main part, a lot of pages have Skip Links placed before the header (dev.to also has a skip link, try reloading the page and pressing tab). It makes sense to add it if your header has, say, 4+ elements in it.

A Skip Link is just an anchor tag visually hidden that targets an existing ID on the current page. It should be positioned as the first focusable element inside the body and header.

You can even have more than one Skip Link positioned one after another if you have a particularly lengthy content.

Corresponding WCAG rule - 2.4.1 Bypass Blocks.

For correct visual hiding, there are a few catches that are explained here, and with the recommended pattern at the end, it will be more robust than simple absolute positioning with offsetting.

Tailwind offers the sr-only class implementing this pattern (with the name being a little off since it's not only for screen readers) that you would need to prepend with focus:, or you can use the plain CSS version below.

<header>
  <a href="#main" class="skip-link">
    Skip to main content
  </a>
  <!-- Other header content -->
</header>
<main id="main">
  <!-- Main page content -->
</main>

.skip-link:not(:focus):not(:active) {
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

PWA Shortcuts

Just like native apps, PWAs can be installed on mobile and desktop devices, which will give the app access to more device-specific APIs and the users a way to use it quicker with fewer browser distractions. Converting to PWA is as easy as adding a manifest.json file with a few necessary fields. With one single addition, we can go a little further and give our users a way to quickly jump to the most commonly used screens.

This list of shortcuts is only displayed by right-clicking or long-pressing the app icon, meaning they're only available once the PWA is installed on the user's device.

To define shortcuts for your PWA, use the shortcuts property of your app's manifest.json. This property is an array of objects defining each shortcut's name and URL, as well as the optional short name, description, and icons. For example, here's the web app manifest of a calendar app that defines two shortcuts:

{
  "name": "Calendar",
  "start_url": "/",
  "display": "standalone",
  "icons": [...],
  "shortcuts": [
    {
      "name": "New event",
      "url": "/new-event"
    },
    {
      "name": "View today's events",
      "url": "/today"
    }
  ]
}

Wrap up

Applying even all of these points won't really cost you anything. So if we can make our apps a little more pleasant, why not do it?
If you feel like something could be presented better, feel free to reach out!

Resources

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/inputmode
https://www.tempertemper.net/blog/skip-links-what-why-and-how?ref=dailydev#main
https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Expose_common_actions_as_shortcuts

Anticipating User Errors in Web

Andrew K — Thu, 20 Mar 2025 11:00:00 +0000

Introduction

This article came to me as a logical continuation of my first article. After finishing it, I kept exploring the topic of UX in general and realized that it's not only hitting targets that our users can struggle with.
This time I'll be talking about how we usually make our interfaces react to various types of incorrect user input (or lack of any) and how it can create even more confusion for our users.
And again, this article covers mostly how we, developers, can contribute to improving this.

Disabled Buttons

The first thing that comes to mind when thinking about where users can make mistakes is a form element. It's very common for web apps to disable the main submit button until the user fills everything and fills it correctly. This happens on login screens, personal information pages, contact forms, some long onboarding flows, and so on. It may seem like a no-brainer to just set that disabled attribute until the user passes all the validation, but there can be a lot of confusion for users. It can be that they don’t even know exactly whether it was disabled initially or if it has changed its state to disabled in response to any of their actions. Most importantly, it makes the button practically non-existent for screen readers and keyboard navigation, because it can't receive focus.

Usually we disable buttons instead of hiding them when we want to show that they can be enabled at some point, but many times we don't properly explain to our users what should enable it. In most cases they don't even need to be disabled. Exceptions where we could use the attribute could be buttons in loading states, disabled because something is unavailable on our side, or other special cases.

As Matthew Standage notes, “when we disable a button on a form we are often disabling the call-to-action — that thing on the page we trying to encourage users to click to proceed with their journey.“

That's why by default react-hook-form library is configured in a way that it doesn't validate anything inline until the first submit, suggesting that way to leave the button initially enabled.

So, the first and simplest solution is to keep them enabled from the beginning. Let users submit their forms, validate their input, and then explicitly explain and point to any errors they have. Сomplementary to this, inline validation on the field's blur event still fits rather well. It's a good practice to inform users orderly and not overload them with information at once only when the submit is made.

Another less ideal fallback solution - aria-disabled attribute. disabled applies a lot of modifications to an element, while aria-disabled just conveys the semantics of it, meaning that you would need to add some CSS and JS to make it complete. If you absolutely need to have a disabled button, here's a great article by Sandrina Pereira on how to do it more inclusively with steps on applying aria-disabled.

Generally, disabled attribute can be used for many other cases and elements, but for form buttons aria-disabled is better. From MDN:

The header button element associated with non-collapsible accordion panel,

A button which is important to keep in the page's focus order, but its action is presently unavailable - such as submitting a form,

Temporarily inactive items in a menu widget that would otherwise be skipped over via standard keyboard navigation.

Bonus point: Displaying error messages

Since we are talking about forms and input errors, it should be the right place to figure out how to properly display them. Probably the most popular position to place validation errors is directly below the corresponding field. It might be a good idea to reconsider this.

Google has an error message covered by autocomplete. Inaccurately unfolding element has both input and errors obstructed

In these cases it might be very well obvious what kind of error gets hidden, but in a less common scenario this behavior can become pretty inconvenient.
Let's cover now how to properly present them from an accessibility standpoint.

First of all, to mark an input itself as invalid, we use aria-invalid="true", which will make the screen reader recognize and announce that the field is invalid when it’s focused.
Error messages related to input also need to be connected to it, and not only visually, but for screen readers as well. For that, we can use aria-describedby with an id of the element containing the error message. You can also pass multiple ids with aria-describedby="addressError addressHint".
One gotcha:

Important to note that although aria-describedby supports multiple ids, if you change them (or the elements’ content) dynamically while the input is focused, the SR won’t re-announce its new content automatically. It will only read the new content after you leave the input and focus it again.
Source

Finally, since errors appear dynamically in the form, we need to properly announce their appearance to the screen readers by using aria-live="assertive". Otherwise, the SR won’t announce it unless the user manually navigates to it.

Note that the aria-live attribute must be present in the DOM right from the beginning, even if the element doesn’t hold any message yet, otherwise, Assistive Technologies may not work properly.

Borrowing example from the code snippet above, the end result should look like this:

<div class="field">
    <label for="ticketCount"><span>Number of</span> Tickets</label>
    <input id="ticketCount" type="text" aria-invalid="true" aria-describedby="ticketError">
    <p aria-live="assertive" id="ticketError">Add between 1 and 9 tickets.</p>
</div>

So called Live Regions should be used for other dynamic messages as well, but that's a different broad topic.
From the article mentioned above:

There’s much more to tell you about this little aria-live attribute and the big things it does. There are gotchas as well. For example, if it is applied incorrectly, the attribute can do more harm than good. It’s worth reading “Using aria-live” by Ire Aderinokun and Adrian Roselli’s “Loading Skeletons” to better understand how it works and how to use it.

Navigation errors

I already mentioned my first article in the introduction, which basically covers a similar topic of how to make hitting elements less error-prone and a little more pleasant.

But there's one more related case I omitted.
Hover menus that unfold with a list of items, a UI pattern that's been tackled many years ago, still fail to deliver an effortless navigation sometimes. It doesn't have to be a menu, sometimes it can be some tooltip with buttons or other selectors that appear only on hover. Essentially, it's a set of controls hidden behind a smaller element to save space that appears on hover, trying to save the user a click.

Try to open the menus and move your pointer directly to the last item:

Instinctively, we are going with the shortest route when we see our target right in our reach, but apparently the path to it lies beyond the hover area of the whole menu, and we see our target disappear. This is a complication of pointer devices; on a touch device, there won't be any problem at all.

Of course, for some shapes of menus, you can rely on libraries, but there may be a need to handle more peculiar cases.
There are at least 4 ways to deal with this, and you can use a combination of the last 3 to better suit your needs.

Click — changing menu to open on click is by far the simplest method, whether it's worth all the extra effort that comes with the other methods or you are stopping here is up to you.
Timer — setting some delay on pointer events to not close the menu instantly. Implementation is up to you; I left mine simplified for the demo.
Static Safe Triangles — a middle ground between relative simplicity and implementing fully dynamic safe triangles. Basically, you add curved invisible (made visible for demo purposes) triangles to the sides of your button. The triangles will make a path to your last submenu items while not obstructing much navigation to other menu items. Inspired by this.

Let me break down a little the last one.
First, we are placing the safe area inside the submenu and making it the same height. With position: absolute; we push it outside to cover the width of the button (in my case, the button and submenu have equal width). Unlike with other solutions, you don't need to set any pointer-events: none;, the triangles themselves will be an active part of your submenu in a shape you already see.
The triangles are drawn with one relatively simple path() string using clip-path: path();. In my example the coordinates are hardcoded, but you can use your framework of choice to calculate the values dynamically.
You can use this tool to have an explanation of each step of the path drawing.

Setting this dynamically with a template string will look like this:

`path("M ${width} 0 S ${width} ${topDistance + 1} , 0 ${topDistance + 1} L ${width} ${topDistance + 1} L ${width} 0 M ${width} ${height} S ${width} ${bottomDistance - 1} , 0 ${bottomDistance - 1} L ${width} ${bottomDistance - 1} L ${width} ${height}")`

width, height - width and height of the area (also width of the opening button and height of the unfolding submenu);
topDistance - distance between the top edge of the submenu and the button by Y coordinate;
bottomDistance - distance between the bottom edge of the submenu and the button by Y coordinate.

I do a 1 pixel adjustment into the button's area to prevent any small gaps that could appear between them during rounding or other weird behavior of Firefox, which happened to me. Same goes for the right: 99%; line of .safeAreaElement, this will leave 1% of the area inside the submenu.

Dynamic Safe Triangle — the most complicated solution with its own nuances. One Safe Triangle is now dynamically drawn starting from your pointer position. This is the best implementation I could find, with interactive examples and code explanations, and I have nothing to add to it.

Navigation Blocking

A behavioral pattern I feel like used to be more common before, but now I barely see it anywhere. Navigation blocking is supposed to occur when you are filling a form, making a transaction, i.e., in the process of doing a multi-step task, and you have some unsaved progress. It won't be possible, of course, to fully block your navigation. This will just open a modal dialog to double-check that you won't be losing anything important. Traditional implementation would prevent you from accidentally clicking on a link, hitting the browser's navigation buttons, or even closing the tab or the whole browser.

Firefox message displayed before leaving the page

The code for this would look like this:

window.addEventListener('beforeunload', function (e) {
  if (isTaskInProgress) {
    e.preventDefault();
    e.returnValue = true;
  }
});

MDN on beforeunload event

Now, this is something you would do for MPA. For SPA you would ideally need both listening to the beforeunload event (to have browser navigation/closure covered) and router-specific logic, since for SPA that's where the majority of routing really happens. Depending on your router of choice, one or both of these cases may already be covered by the library.

I'll list some implementations in my stack:

Tanstack Router
React Router's and useBeforeUnload
Solid Router
Next.js removed it from app router, leaving place only for custom solutions

As in many cases, this is one of the techniques that should be used sparingly, and in the next section we’ll be talking about the relevance of such confirm modals.

Modals on destructive actions

Modal dialogs is another important topic, as they are usually what guarding users from critical actions. Modals in general are a common thing in UI, they can be used for different scoped tasks to take users out of their current context. But a confirmation modal is something that can also be easily overused, leading to creating a habit of automatically confirming them and losing it's meaning in the first place.

In general, users don’t show much annoyance with self-initiated modals, but they get very frustrated with any kind of auto-triggered modals. But if a modal helps users avoid critical mistakes, they find them acceptable.

Use modal dialogs to avoid an irreversible error/action that will have serious consequences, like deleting or transferring something. This kind of modal should be something they normally don't do, something to grab their attention and slow them down, letting them consciously process the action taking place.

When it comes to implementation, we need to consider accessibility with how the focus will be handled when the modal is opened and closed, prevent the underlying page from scrolling, as well as provide obvious ways to close it, like a big enough X button, ESC keyboard button, and clicking outside of it.
Thankfully, modern <dialog> element makes implementing all of it easy, with very little JS needed. It's well supported with global adoption of 96%, customizable, has some more complicated cases like hitting ESC with multiple dialogs open handled, and can be well animated. As far as I know, all past issues with native dialogs were fixed, and now there's no real reason not to use it. I really like the implementation of modals in DaisyUI.

The better approach to safeguard a critical action is the undo option. By allowing users to rollback their unintended operation, we encourage some to use the app without the fear of breaking something and entrust others with an uninterrupted flow of decisions. It's a good safety net that doesn't get in the way, unlike modals.
Unfortunately, the undo is much harder to implement and requires designing on all levels, while it may not be possible at all in some cases.

Wrap up

I wanted to put together all the ways to handle user errors, the ways we can trap them inadvertently sometimes, and the ways to make some improvements here.
The solutions are not always simple. Sometimes it takes more than one safety net, and sometimes it's very easy to overdo it with our efforts.
If you feel like something could be presented better, feel free to reach out!

Resources

https://www.nngroup.com/articles/slips
https://www.smashingmagazine.com/2023/08/better-context-menus-safe-triangles
https://www.smashingmagazine.com/2024/09/how-manage-dangerous-actions-user-interfaces/#when-to-use-it-2

Fixing Target Size or A Fat Finger Problem

Andrew K — Mon, 21 Oct 2024 09:35:00 +0000

Introduction

A few years ago, a client of mine said, "Andrew, these designs are great, but let's make everything twice as large, because, you know, these fat finger Americans will have a hard time clicking that.". It was a long form with lots of small elements, like checkboxes and toggles, and what he said actually made sense and led me to think about what the rules are and to what extent we should adjust our interfaces. Half of the topic is a designer's concern, but as a Frontend developer, I'll be talking about the developer's part and what we can do better while not messing with artistic choice.

Theory

What is a Fat Finger Error?

A fat finger error is a human error caused by pressing the wrong key when using a computer to input data.
Source

The term became broadly known in the finance field after it caused some serious damage on numerous occasions (see examples in the source above). In a consumer app, it can lead to a clunky user experience or rage taps even in a perfect environment and can turn out to be unusable in a non-conventional environment or for users with special needs. And we want to leave the margin for error as little as possible for our users if we want them to keep coming back to our app.

The term "target" in this topic refers to basically any interactive area in a UI that accepts a pointer action (click, touch). This could be buttons, inputs of every type, navigation links, media controls, etc.

So, generally, what's the target size requirement? According to WCAG 2.5.5 guideline, it should be at least 44x44 CSS pixels (except for targets in a sentence or block of text, i.e., links inside of text or help icons at the end of it). That's the size we will be targeting whenever possible, the recommended upper bar. As the last resort, according to WCAG 2.5.8 Minimum guideline, we should ensure a proper spacing between targets is set.

Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;

That is, technically, everything bigger than 24x24 pixels is not required to have any spacing from other targets.

There are other UI design guidelines, of course, which can even use different units of measurement (e.g., Apple Human Interface Guidelines, Google Material Design). Let's stick to pixels for web, since with other units there's a lot going on.

Practice

Single targets

As we discussed above, even an undersized target with enough spacing around it is considered acceptable. It will be easy to hit on touch devices due to the broad area they can cover with a single touch. With pointer devices, however, it will be a different case since the pointer covers only 1 pixel directly under it. That being said, if we can easily improve user experience and increase target size in this case with no drawbacks, I don't see a reason not to do it.

To increase the target size, we can simply add padding to it. In certain cases, however, this can shift around the layout, like when your target is part of a smaller flexbox. In such cases, I match the added padding with a negative margin applied to the same side. It's a simple trick that shouldn't really confuse the next developer reading your code, it's easy to calculate if there's another margin that has to be set, and it works well with Tailwind.

Increasing target size with padding without affecting the outside layout

The alternative to margins would be adding a pseudo-element, and perhaps in some cases it will be the only way, but usually a padding + margin is more efficient and easier.

.target-element:after {
  content: "";
  position: absolute;
  inset: 0;
  width: 100px;
  height: 100px;
}

Lists and composite elements

A lot of times in all kinds of navigational lists, spacing gets added to the surrounding container, leaving the items themselves small and harder to pinpoint. Whenever possible, you should prefer full-width or full-height bars for lists. Gaps between items can also be replaced with padding, but it may result in extra spacing around the container. To counteract this, once again, you can apply a negative margin to the container.

For inputs of all types (like checkbox, radio, file, etc.), we can use the <label> element. In this case, the target area extends to the label as well, which makes a night and day difference when working with small elements like checkboxes.
Quoting MDN:

When a user clicks or touches/taps a label, the browser passes the focus to its associated input (the resulting event is also raised for the input). That increased hit area for focusing the input provides an advantage to anyone trying to activate it — including those using a touch-screen device.

You can either provide id and for attributes to the target element and label respectively, or an easier way would be to nest the target element inside the label.
Elements that can be associated with a <label> element include <button>, <input> (except for type="hidden"), <meter>, <output>, <progress>, <select> and <textarea>.

The last obstacles in input's accessibility I saw in various forms are prefixes/adornments that get used with them. An icon or badge that's placed on top of input and not interactive shouldn't obstruct the input's target area. It could be avoided by simply adding the pointer-events: none; CSS rule or by using <label> as well. Similarly, a label can be used to extend the target area to include an icon positioned near the input when visually it's not clear where the input's target area extends to.

Range slider

A common issue I noticed with range sliders is that the target area is limited to its track and thumb, overlooking the area that covers the thumb's height. Some component libraries with custom range slider implementations suffer from that, at least with the setup they come with out of the box. So the first step we should do is increase the target area to thumb's height. We can go even further by extending the slider's target height beyond the thumb's height, which can be especially useful if your thumb is small.

Youtube's player target area

Native HTML5 range slider (range input) supports it out of the box easily. Unfortunately, it's very limited in terms of style options and inconsistent across browsers, so it's hard to recommend it.

Below I'm comparing 3 common types of target sizes in range sliders. The last one, in my opinion, being ideal in terms of its target size, and I think that's where we should aim. Of course it's possible that you'll be able to tweak your library of choice to this state, but in the short time I tried with some libraries, I wasn't able to.

Comparison of slider's target area options

You can try it here (ignore the extra styles, and keep in mind that it looks best in Firefox):

Testing an existing codebase

Pesticide for Chrome / Pesticide for Firefox

The easiest way to test manually would be using this browser extension, which simply injects some CSS and adds an outline around all elements on the page.

You could also, of course, add your own global CSS. Just keep in mind that if you are testing someone else's codebase, you'd never know if some supposedly non-interactive tags were made interactive by previous developers.

Wrap up

Check out the amazing article by Ahmad Shadeed linked below if you want a deep dive into the topic. He has the best interactive examples I've seen. I wanted to add some things from my experience and also make the topic more approachable and directed to us developers. Hence, I decided to write the first article of my own.
If you feel like something could be presented better, feel free to reach out!

Resources

https://ishadeed.com/article/target-size/
https://www.smashingmagazine.com/2022/02/fitts-law-touch-era/