DEV Community: Srikar Phani Kumar Marti

ARIA Role Inheritance and Override: How Browsers Resolve Conflicting Semantics

Srikar Phani Kumar Marti — Wed, 26 Aug 2026 13:37:59 +0000

Ever had that moment where you slap an ARIA role on an element, only to find your screen reader ignores it or reads something totally unexpected? You double-check your markup, and then notice you also have some nested roles, or conflicting aria attributes nearby. What’s going on?

I ran into this while fixing accessibility bugs on a client site. A button inside a custom widget had role="button" but also aria-haspopup="menu" , and the screen reader would announce "menu" instead of "button." Digging in, I realized that the way browsers handle ARIA roles and properties isn’t just about what you explicitly set on an element. There’s a whole system of inheritance, overrides, and conflict resolution happening under the hood.

Let’s talk about how browsers actually resolve ARIA roles and properties when there are conflicts, and what that means for you when debugging accessibility issues.

The tangled web of ARIA roles and properties

ARIA roles describe what an element is to assistive technology. For example, role="button" tells a screen reader this element behaves like a button. Other roles include menu, checkbox, dialog, and so on.

But ARIA also has properties and states, like aria-haspopup, aria-checked, or aria-expanded, that modify or add semantic information.

The confusion starts when you put multiple roles or conflicting properties on the same element, or when nested elements define roles that might clash.

Here’s the kicker: an element can only have one computed role. While you can set multiple roles explicitly in your markup (like via role="button menu", which is invalid), browsers use a priority and inheritance system to pick one.

How browsers pick the winning ARIA role

The spec gives some guidelines, but browser implementations differ subtly. Here’s the gist:

Explicit role attribute wins: If you set role on an element, that role is the first candidate.
Implicit role fallback: If no explicit role is set, browsers may infer a role based on the tag name and attributes (like <button> implicitly has role="button").
Special roles override generic ones: Some roles have higher precedence. For example, alert overrides region.
ARIA role inheritance: Roles do not literally inherit like CSS properties, but some ARIA properties do affect descendants’ semantics.

For example, if you have role="menu" on a container and inside it a child with role="menuitem", the child’s role is explicit and independent.

What about conflicting ARIA properties?

This is where things get tricky. Properties like aria-haspopup can influence what screen readers announce.

In my example, adding aria-haspopup="menu" to a button tells the screen reader the button controls a menu , sometimes causing it to announce "menu" or "button with menu." But if you also set role="menu" on the same element, the role wins and it treats the element as a menu, not a button.

In other cases, properties can override or augment roles:

aria-checked on a checkbox or switch controls the checked state.
aria-expanded on a disclosure widget signals whether it’s open.

But if the role and the ARIA properties don’t align, screen readers may behave unpredictably.

Under the hood: the accessibility tree and role resolution

The secret sauce is the accessibility tree , a parallel structure browsers build from the DOM, CSS, and ARIA attributes that assistive tech consumes.

When the browser parses the DOM:

It looks for explicit roles on elements.
If absent, it infers implicit roles.
It collects ARIA properties, validating them against the role.
It resolves conflicts:
- Multiple roles aren’t allowed; the browser picks one by priority or last-known override.
- Conflicting properties may be ignored or cause fallback behavior.

This process can differ slightly between browsers and screen readers, which is why your accessibility testing must include multiple platforms.

Debugging tips: How to see the computed ARIA role and properties

Feeling lost? Here’s how to peek under the hood:

Use browser devtools accessibility pane: Chrome and Firefox have accessibility inspectors that show the computed role, name, states, and properties for any element.
VoiceOver or NVDA output: Listen carefully for what role and state the screen reader announces.
Accessibility tree snapshots: Tools like the Accessibility Object Model (AOM) inspector or axe-core can reveal discrepancies.

For example, in Chrome DevTools:

Right-click your element and inspect.
Go to the "Accessibility" tab.
See the "Computed Properties" , it shows the effective role and ARIA states.

If the computed role isn’t what you expect, check for conflicting role attributes on the same or ancestor elements.

Common pitfalls and how to avoid them

Don’t mix roles on the same element: Stick to one explicit role. If you need nested roles, use child elements.
Align ARIA properties with the role: Don’t add aria-haspopup="menu" on an element with role="menu"; it’s redundant and confusing.
Use native semantics when possible: Native HTML elements have implicit roles and states that assistive tech understands well.
Test with multiple screen readers: Behavior varies, so verify your ARIA usage under real conditions.

Why does this matter?

Misusing ARIA roles and properties can confuse users relying on assistive technology. Overriding or conflicting roles may cause screen readers to announce the wrong widget type, breaking navigation and interaction.

Understanding how browsers resolve these conflicts helps you write cleaner, more predictable accessible code.

Next time your ARIA role isn’t behaving as expected, remember it’s not just the markup but how the browser builds the accessibility tree and resolves those roles and properties. Use the tools to inspect what’s really going on, and keep your roles clear and consistent.

Accessibility isn’t just about adding attributes , it’s about making sure those attributes speak clearly and consistently to the user’s assistive technology.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Optimizing Keyboard Navigation in Complex Web Apps: Techniques and Debugging Tools

Srikar Phani Kumar Marti — Tue, 25 Aug 2026 13:03:52 +0000

Ever found yourself tabbing through a complex web app only to get trapped inside a modal, or worse, see the focus jump erratically like it’s playing hide and seek? I’ve been there, building custom widgets that looked sleek but turned into nightmares for keyboard users.

It’s one thing to have basic tab order working. It’s another story entirely when you have nested widgets, dynamic content, or custom keyboard shortcuts. You want your app to feel smooth and predictable for keyboard users, but the reality is often a tangled mess of tabindexes, event handlers, and accessibility quirks.

In this post, I’ll share what I learned about optimizing keyboard navigation in complex web apps. We’ll dive into techniques for managing focus order, handling keyboard events gracefully, and using browser and screen reader tools to track down the root causes of weird focus or event issues.

When Keyboard Navigation Gets Messy

Picture a custom dropdown inside a modal that itself lives inside a tabbed interface. You press Tab expecting to move logically through the UI, but suddenly the focus skips the dropdown’s toggle or gets stuck inside the modal with no way out.

Why does this happen?

Incorrect tabindex values: Misusing or overusing tabindex can break natural tab flow.
No focus management on dynamic UI: When widgets open or close, focus should move appropriately, but often it doesn’t.
Keyboard event conflicts: Overlapping handlers steal or swallow keys like Escape or Arrow keys.
Screen readers and assistive tech nuances: What looks fine visually might confuse screen readers.

I recently ran into this while building a complex combo box. The toggle button was focusable, but pressing Down Arrow didn’t move focus to the list items as expected. Worse, closing the list didn’t return focus to the toggle button. Keyboard users were left puzzled.

The Core Principles Under the Hood

Focusability: What Can Receive Focus?

Native interactive elements like <button>, <input>, and <a href> are focusable by default. Non-interactive elements like <div> or <span> are not unless you add tabindex="0" or tabindex="-1".

tabindex="0" makes an element keyboard focusable in natural tab order.
tabindex="-1" makes an element focusable only programmatically (e.g., via .focus()) but skipped in tab order.

Using tabindex incorrectly often leads to confusing tab sequences or focus traps.

Managing Focus on State Changes

When you open a dropdown or modal, you should:

Move focus into the widget (usually to the first interactive element inside).
Trap focus within the widget if appropriate (e.g., modals).
Restore focus to the originating element when closing.

Doing this manually means calling .focus() at the right time and managing keyboard event handlers to trap or release focus.

Keyboard Event Handling

Keyboard events come in three flavors: keydown, keypress, and keyup. For custom navigation, keydown is typically the best place to intercept keys because it fires earliest.

Be careful to:

Prevent default browser behavior only when necessary.
Avoid conflicts with other handlers.
Respect modifier keys like Shift or Alt.

For example, intercepting Arrow keys to move focus inside a list requires preventing default scrolling but letting other keys pass through.

Tools to See What’s Really Happening

Browser DevTools - Focus Debugging

Modern browsers have features to inspect focus:

Elements panel: Inspect the currently focused element with document.activeElement in the console.
Accessibility pane: See what the browser exposes to assistive tech.
Tab order visualization: Some browsers or extensions highlight tabbable elements.

Try this in Chrome’s console:

console.log(document.activeElement);

or even add event listeners to log focus changes:

document.addEventListener('focusin', (e) => {
  console.log('Focus moved to:', e.target);
});

This helps you verify where focus lands as you tab around.

Screen Reader Testing

Screen readers like NVDA (Windows), VoiceOver (macOS), or Narrator (Windows) expose how your app’s focus and roles are announced.

Turn on your screen reader and:

Tab through your app.
Listen for announcements.
Verify the focus highlights match what’s announced.

Discrepancies here often reveal mismatches between aria-* attributes and actual focus.

Keyboard Event Listeners in Debug Mode

Adding verbose logging on keyboard events can clarify which handlers run and in what order.

document.addEventListener('keydown', (e) => {
  console.log('Key down:', e.key, 'Target:', e.target);
});

Use this to detect if some handler is calling e.preventDefault() too early or swallowing events.

Practical Techniques to Fix Common Issues

1. Prefer Native Elements When Possible

Buttons, links, inputs come with built-in keyboard support. When you need custom widgets, start from a native element or at least use role and tabindex carefully.

2. Use `tabindex` Sparingly and Correctly

Avoid positive tabindex values (e.g., tabindex="1") as they reorder tabbing unpredictably.
Use tabindex="0" for elements that must be focusable in order.
Use tabindex="-1" for programmatic focus targets.

3. Implement Focus Management on Open/Close

When opening a dropdown or modal:

function openDropdown() {
  dropdownElement.style.display = 'block';
  dropdownElement.querySelector('li').focus();
}

When closing:

function closeDropdown() {
  dropdownElement.style.display = 'none';
  toggleButton.focus();
}

4. Trap Focus Inside Modals

Trap focus by listening to keydown for Tab and Shift+Tab:

document.addEventListener('keydown', (e) => {
  if (e.key === 'Tab') {
    // logic to cycle focus inside modal
    e.preventDefault();
  }
});

Libraries like focus-trap automate this.

5. Handle Arrow Keys and Other Navigation Keys

For list widgets, intercept Up/Down arrows to move focus between items:

function onKeyDown(e) {
  if (e.key === 'ArrowDown') {
    e.preventDefault();
    moveFocusToNextItem();
  }
}

Make sure to update aria-activedescendant or focus accordingly.

Wrangling a Real Bug: A Case Study

In my combo box, pressing Down Arrow didn’t move focus to the list items. Turns out I had:

The toggle button focusable with tabindex="0".
The list container with tabindex="-1" but no focus shifting on open.
Keyboard handler on the toggle button that didn’t prevent default or move focus.

Fix:

Added code to focus the first list item on open.
Prevented default on Arrow Down.
Managed aria-expanded and aria-controls attributes properly.

Once fixed, keyboard navigation felt natural and predictable.

Wrapping Up

Keyboard navigation in complex apps is tricky because you’re fighting the browser’s natural tab order, your app’s dynamic UI, and the expectations of assistive tech users.

By understanding focusability, carefully managing focus on UI state changes, and using browser and screen reader tools for debugging, you can make keyboard navigation smooth and reliable.

Next time your keyboard users get lost or stuck, you’ll have a better idea of where to look and how to fix it.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

CSS Container Queries: How Browsers Calculate and Recalculate Styles

Srikar Phani Kumar Marti — Mon, 24 Aug 2026 10:38:55 +0000

Ever had a layout break because a component looked perfect on your screen but warped on a colleague’s? Or tried to build a responsive widget that adapts to its container , not just the viewport , only to realize CSS media queries don’t cut it?

That’s exactly where CSS container queries come in. They let you apply styles based on the size of a container element instead of the whole viewport. It feels like magic until you hit bugs or weird reflows and start wondering: how exactly do browsers figure out when to apply those styles? How do they know the container size changed, and what happens next?

I spent a few weeks poking around browser engines and experimenting with container queries in real projects. Here’s what I learned about the mechanics under the hood, how browsers detect container resizes, what triggers style recalculations, and how to debug tricky issues.

When container queries hit the scene

Imagine you have a card component inside a sidebar. The sidebar can be narrow or wide. You want the card’s content to switch layout based on the card’s actual width , not the viewport width.

Previously, this was a headache. You’d either need JavaScript resize listeners or complex hacks. Now, with container queries, you write something like:

.card {
  container-type: inline-size;
}

@container (min-width: 300px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

Perfect. But how does the browser know when the card’s size crosses that 300px threshold?

The container query workflow inside browsers

At a high level, browsers treat container queries as a new kind of style condition. But unlike media queries , which depend on the viewport or device , container queries depend on the size of the container element itself.

Here’s the rough flow:

Container detection: The browser looks for elements styled with container-type. This tells it which elements are containers and what dimension (inline-size, block-size, or both) to watch.
Size measurement: On layout, the browser measures those container elements’ dimensions.
Style matching: When applying styles, the browser evaluates @container rules using the measured container size instead of viewport size.
Style recalculation: If the container size changes, the browser reevaluates container queries for all descendants that rely on that container.
Layout and paint: If styles changed, it triggers layout and paint updates as usual.

How does the browser detect container size changes?

This is the trickiest part. Browsers don’t constantly measure every container element on every frame , that would tank performance.

Instead, they rely on a combination of mechanisms:

Intrinsic size changes: If the container’s content or style changes in a way that affects its size, the layout engine notices during its normal flow.
Explicit resize observation: Browsers implement something similar to the Resize Observer API internally to detect size changes on container elements. When a container’s size changes, the browser marks it as needing container query reevaluation.
Cached sizes: To avoid thrashing, browsers cache container sizes and only trigger container query reevaluation if sizes actually differ beyond subpixel rounding.

This means if your container’s width changes from 290.4px to 310.1px, that crossing of the 300px threshold triggers new container query matches.

What happens when a container size changes?

When a container’s size changes:

The browser schedules a style recalculation focused on container queries inside that container.
It reevaluates any @container rules whose conditions depend on that container.
If styles for some elements change, it triggers a layout update for those elements and their children.
Finally, it paints the updated parts.

Since container queries can cascade, a single container size change might ripple to multiple nested containers, but browsers optimize to avoid unnecessary recalculations.

Under the hood: container queries and the rendering pipeline

Container queries introduce a dependency in the style system that looks like this:

Container size → style rules → layout → paint

This dependency means the browser’s rendering pipeline adds a new observation step:

During the style calculation phase, container sizes are used to pick styles.
If container sizes change, style recalculation happens, which can cascade to layout.

This is a subtle change compared to media queries because container queries depend on dynamic element size instead of global viewport size, which can change as a side effect of style or layout itself.

Real-world debugging tips for container queries

1. Check if your container actually has `container-type` set

Without this property, container queries silently don’t work. It’s not enough that you have @container rules , the container element must declare itself.

2. Verify the container’s size

Use DevTools to inspect the container’s box size. Sometimes padding, borders, or box-sizing cause the size to be different than you expect.

Resize your container manually (e.g., by resizing a pane or window) and watch if styles update.

3. Understand container sizing modes

container-type can be size, inline-size, or normal. The most common is inline-size, which watches width in horizontal writing modes.

If your @container queries use block-size conditions but your container only reports inline-size, those queries won’t match.

4. Beware of nested containers

If you have multiple nested containers, each with their own queries, the browser tracks each container separately. Styles inside nested containers can re-trigger layout, so be mindful of complexity.

5. Watch out for layout thrashing

If container queries cause style changes that affect container sizes themselves, you can get layout loops or jank.

Try to avoid container query rules that increase container size when the container size is already near your breakpoints.

6. Use Resize Observer for debugging

You can also add a ResizeObserver in your JS to watch container sizes and log when they change. This helps confirm when the browser detects size changes.

const container = document.querySelector('.card');
const ro = new ResizeObserver(entries => {
  for (let entry of entries) {
    console.log('Container size changed:', entry.contentRect.width);
  }
});
ro.observe(container);

What’s next with container queries?

Browser support is solid and growing, but some quirks remain:

Container queries don’t yet work inside iframes or shadow DOM in all browsers.
Performance is still evolving. Benchmark your layouts if you use many or deeply nested containers.
The spec may add more features like container query lists or interaction-based queries.

Wrap-up

Container queries feel like a breath of fresh air for responsive design that adapts to component size, not just viewport size. But under the hood, they add a new dimension to the browser’s rendering pipeline , tracking container sizes, recalculating styles dynamically, and triggering layout updates selectively.

Understanding how browsers detect container size changes and apply container query styles helps you avoid surprises and debug issues faster.

Next time your card flips layout on a size boundary, you’ll know exactly what’s going on inside the browser to make that happen.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

React Portals: How They Work and When to Use Them for Modals and Tooltips

Srikar Phani Kumar Marti — Wed, 19 Aug 2026 11:11:08 +0000

You’ve probably built a modal or tooltip in React and hit a weird snag: the overlay appears visually outside your usual component tree, but events don’t behave as you expect. Maybe clicks inside the modal don’t bubble the way you thought, or keyboard focus seems lost when you open it.

That’s React portals messing with your head , in a good way. They let you render children into a DOM node outside your React root, which is great for modals, tooltips, dropdowns, and other overlays. But under the hood, portals change the event propagation and focus flow in subtle ways.

I ran into this recently while debugging a modal that wouldn’t close on outside clicks. The culprit? A misunderstanding of how portals handle events and focus in the DOM.

Let me walk you through how React portals work, what happens to events and focus, and some practical debugging tips when using portals for modals and tooltips.

What Exactly Is a React Portal?

React portals are an escape hatch. Normally, React renders your component tree inside a single root DOM node , often <div id="root">. But what if you want a component somewhere else in the DOM, like a modal appended to document.body?

Portals let you do that:

ReactDOM.createPortal(children, container)

This tells React: render children into DOM container, outside the main React DOM tree.

Why?

Modals and tooltips often need to break out of parent containers that may have overflow: hidden or z-index stacking contexts.
They need to sit at a higher DOM level for proper layering and positioning.

So portals let you keep React’s declarative component model while placing DOM nodes where they need to be.

What Happens Under the Hood?

React internally keeps track of the portal’s target container. It renders the portal’s children into that container as real DOM nodes.

But React’s component tree and the DOM tree then diverge. Your React tree says "Modal is a child of App," but the DOM says "Modal is a child of document.body."

This divergence is the core of what trips people up.

Event Propagation Isn’t Broken , But It’s Different

Here’s the key: React uses a single event delegation system at the root container. Events bubble through the DOM, then React maps them back to components.

With portals, the DOM tree is split. The portal’s DOM nodes live somewhere else, outside the root container where React listens for events.

So how does React handle events from portal nodes?

React attaches event listeners at the root of each React render tree , and for portals, it attaches them at the portal’s container node too.

This means events inside a portal bubble through the portal container, then propagate to the React root container.

In practice, this usually works seamlessly, but there are some event propagation edge cases:

Events that rely on the DOM tree hierarchy (like native event bubbling) behave normally because the portal nodes are real DOM children of the portal container.
But React’s synthetic event system treats portal containers as roots for event delegation, so some event listeners might fire in different orders.

This explains why outside click detection on portals sometimes fails if you’re relying on event bubbling inside the React tree without accounting for the portal’s container boundaries.

Focus Management: The Invisible Trap

Modals and tooltips often trap focus for accessibility: when the modal opens, keyboard focus should move inside it, and tabbing should cycle within the modal.

Portals complicate this because the modal’s DOM nodes are outside the React root and its focus context.

Browsers don’t care about React internals , they only see DOM nodes. So focus will move normally, but your app’s logic to restore focus or detect focused elements needs to account for the portal container.

For example, if you try to detect clicks outside a modal by checking if the event target is inside your React tree, it won’t work , because the modal lives in a separate DOM subtree.

Also, keyboard navigation and focus outlines might behave unexpectedly if CSS styles or focus management code assume the modal is nested inside the React root.

Practical Debugging Tips for Portal-Based Modals and Tooltips

1. Use `ref` on the Portal Container

Keep a ref to the portal container DOM node (document.body or a div you created). When handling clicks or focus events, check if the event target is inside that container using container.contains(event.target).

This is more reliable than React tree checks.

2. Attach Event Listeners on the Portal Container

For outside click detection, attach mouse event handlers on the portal container or even document.

React’s synthetic events may not catch all events correctly when portals are involved, so sometimes native event listeners are more reliable.

3. Manage Focus Explicitly

When opening a modal:

Focus the first focusable element inside the portal.
Trap tab focus inside the portal container.
Return focus to the opener element when closing.

Use libraries like focus-trap-react or build your own with careful DOM traversal.

4. Watch for CSS Stacking Context Issues

Since portals render outside your main tree, your modal or tooltip might be affected by z-index, position, or overflow styles on ancestor nodes.

Debug with DevTools by inspecting the portal container and ancestors to ensure it’s visible and on top.

5. Beware of Event Ordering Differences

If you have both portal and non-portal components listening for the same events, event firing order might surprise you.

Test carefully and consider using native event listeners in tricky cases.

When Should You Reach for Portals?

Use portals when you need UI elements that:

Break out of clipping or stacking of parent containers
Need to be siblings of your root app node for layering
Require focus management separate from the main React tree

Modals, tooltips, dropdown menus, fullscreen overlays, and context menus are classic portal use cases.

If your popup content can stay within parent containers without clipping or z-index issues, portals might be overkill and add complexity.

A Real Debugging Story

I once built a tooltip that disappeared as soon as I clicked inside it , even though I had an outside click handler to close it only if the click was truly outside.

The problem was the click event inside the portal was bubbling to the portal container, but my handler was checking if the click target was inside the React component tree , which it wasn’t.

Solution: I switched to checking if the click target was inside the portal container DOM node instead. Suddenly, clicks inside the tooltip didn’t trigger the outside click handler.

That tiny change saved me hours of head-scratching.

Wrapping Up

React portals let you render components outside your main React root for UI elements like modals and tooltips. This is powerful but comes with quirks:

Event propagation crosses DOM boundaries differently than standard React tree events.
Focus management requires explicit handling because the portal’s DOM nodes are outside your main tree.
Debugging portal issues means thinking in terms of DOM containment and event flow outside React’s usual model.

Next time your modal misbehaves or your tooltip’s keyboard navigation feels off, remember: portals are working exactly as designed , but you might need to adapt your event and focus logic to their outside-the-tree reality.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Debugging React Memoization: When useMemo and React.memo Backfire

Srikar Phani Kumar Marti — Mon, 17 Aug 2026 10:47:42 +0000

You’ve wrapped a component with React.memo or used useMemo to optimize rendering. You expect fewer renders, snappier UI, maybe even a better frame rate.

But then, surprise! Your component still re-renders way more often than you think it should. Or worse, it seems stuck showing stale props or state.

This exact problem had me banging my head against the wall recently. Memoization in React isn’t magic , it’s a subtle mechanism with traps that can silently backfire.

Why Memoization Exists in React

React components re-render when their parent renders, their props change, or their state updates. Sometimes you want to avoid unnecessary work when inputs haven’t changed.

React.memo is a higher-order component that shallowly compares props and skips rendering if they’re equal.

useMemo caches a computed value between renders, recomputing only when dependencies change.

Sounds straightforward, right? But the devil is in how equality is checked and dependencies are tracked.

The Shallow Equality Trap

React.memo does a shallow comparison of props using Object.is by default. That means it only compares primitive values or references, not deep object contents.

Here’s a classic example:

const MyComponent = React.memo(({ user }) => {
  console.log('Rendering', user.name);
  return <div>{user.name}</div>;
});

function Parent() {
  const user = { name: 'Alice' };
  return <MyComponent user={user} />;
}

You’d expect MyComponent to render once, right? Nope. Every render of Parent creates a fresh user object with a new reference, so React.memo sees different props and re-renders.

What’s going on?

React.memo compares the previous user prop and the new one by reference. Since Parent creates a new object inline, React.memo thinks props changed.

How to fix it?

Memoize the object outside render:

function Parent() {
  const user = React.useMemo(() => ({ name: 'Alice' }), []);
  return <MyComponent user={user} />;
}

Now MyComponent skips renders unless user changes.

When useMemo Doesn’t Memoize What You Think

useMemo works similarly , it caches a value between renders, recomputing only if dependencies change. But it’s easy to misuse.

Consider this snippet:

const memoizedValue = useMemo(() => computeExpensive(), [data]);

If data is an object or array recreated every render, your memoization fails because the dependency changes every time.

This is a common pitfall when you see useMemo not preventing expensive recalculations.

Debug tip:

Log your dependencies and check if their references are stable.

Stale Props and State Due to Memoization

Another tricky scenario: your memoized component doesn’t update when props seem to change.

This usually happens because of stale closures or incorrect dependency arrays.

Example:

const MyComponent = React.memo(({ onClick }) => {
  const handleClick = React.useCallback(() => {
    console.log('Clicked');
  }, []);

  return <button onClick={handleClick}>Click me</button>;
});

If the parent passes a new onClick prop every render but your component uses a memoized handleClick with an empty array, it might ignore the new prop.

What’s the solution?

Make sure callbacks and memoized values depend on all relevant props and state.

React.memo with Custom Comparison Functions

If your props are complex objects that change frequently but contain stable values, you can provide a custom comparator:

function areEqual(prevProps, nextProps) {
  return prevProps.user.id === nextProps.user.id;
}

const MyComponent = React.memo(Component, areEqual);

This lets you control when to skip renders more precisely.

But beware: writing incorrect comparators can cause subtle bugs where your UI doesn’t update as expected.

Debugging Memoization Issues Step-by-Step

Log Every Render

Add console.log inside your component to see when it renders.

Check Prop References

Log props before passing them to memoized components. Use console.log(prop, Object.is(prevProp, prop)) to check if references change.

Inspect Dependency Arrays

For useMemo and useCallback, ensure dependencies include everything used inside the function.

Use React DevTools Profiler

It highlights which components re-render and why. You can spot unexpected renders this way.

Try Removing Memoization

Temporarily remove React.memo or useMemo to see if behavior changes.

When Not to Use Memoization

Memoization isn’t free. It adds complexity and some overhead.

If your components are cheap to render or your app isn’t bottlenecked by rendering, memoization might be premature optimization.

Wrapping Up

React’s memoization tools are powerful but delicate. They rely on reference equality and correct dependencies. If you don’t get those right, you get surprise re-renders or stale UI.

The key is to treat memoization as a contract , you must keep references stable and dependencies accurate. When that contract breaks, React’s memoization works against you.

Next time your useMemo or React.memo seems broken, grab your console, check those references, and track down the sneaky object or function that’s tripping you up.

Happy debugging!

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Keyboard Accessibility in Custom Components: Implementing and Debugging Focus Management

Srikar Phani Kumar Marti — Wed, 12 Aug 2026 10:38:47 +0000

Ever tried tabbing through a custom dropdown or a fancy toggle switch you built, only to find the keyboard focus just skips over it, or worse, gets trapped inside with no way out? I’ve been there, frustrated by a UI that looked perfect but was a nightmare to navigate without a mouse.

Keyboard accessibility can easily slip through the cracks when you roll your own components. Native elements like <button> and <select> come with built-in keyboard behavior and focus handling baked in. Custom stuff? Not so much. You get the visuals, but the focus order, keyboard events, and screen reader cues? That’s all on you.

Let me walk you through the key challenges I ran into, how keyboard focus really works under the hood, and some concrete ways to implement and debug accessible keyboard navigation in custom UI components.

The focus trap: Why keyboard users get stuck or skipped

I once built a custom dropdown with divs and spans for styling freedom. It looked slick, but when I tested keyboard navigation, tabbing would jump right past it. Or sometimes the focus would enter the dropdown, but arrow keys didn’t move selection as expected. Worse, shift+tabbing out of the dropdown was impossible; the focus got stuck inside.

Why? Because by default, only certain elements are focusable , mostly interactive native elements like buttons and inputs. A div or span? Not focusable unless you add tabindex.

I had neglected to:

Make the dropdown toggle button focusable with tabindex="0" (or better, use a native <button>)
Manage keyboard events like ArrowUp, ArrowDown, Escape to open/close and navigate items
Control focus movement on open to the first menu item
Restore focus to the toggle when closing

Without explicit focus management, keyboard users either can’t reach the dropdown or get lost inside it.

How browser focus and tab order really work

Browsers assign a tab order based on the document’s focusable elements:

Native focusable elements (<button>, <input>, <a href>, etc.) come first
Elements with positive tabindex (rarely recommended)
Elements with tabindex=0 (focusable in DOM order)
Elements with negative tabindex are focusable programmatically but skipped in tab order

If your custom component’s parts lack tabindex=0 or aren’t native focusables, the keyboard will skip them.

Also, when you open something like a menu, you typically want to move focus into it programmatically (e.g., focus the first menu item). This prevents keyboard users from losing context.

Implementing keyboard support in custom components

Here’s a checklist I use when coding custom keyboard interactions:

Use semantic elements whenever possible. If your toggle behaves like a button, use <button>.
Make interactive elements focusable. Use tabindex="0" on divs or spans if needed, but sparingly.
Handle keyboard events explicitly. Listen for keydown events on your component, and respond to keys like Enter, Space, Arrow keys, Escape.
Manage focus on open/close. When a dropdown opens, move focus to the first item. When it closes, return focus to the toggle.
Trap focus if needed. For modal dialogs or complex widgets, keep focus inside until the user closes or presses Escape.
Use ARIA roles and attributes properly. role="menu", role="menuitem", aria-expanded, aria-haspopup, and aria-activedescendant help assistive tech understand your widget.

For example, for a custom dropdown:

<button
  aria-haspopup="listbox"
  aria-expanded={isOpen}
  onClick={toggleOpen}
  ref={toggleRef}
>
  Select an option
</button>
{isOpen && (
  <ul
    role="listbox"
    tabIndex={-1}
    ref={listboxRef}
    onKeyDown={handleKeyDown}
  >
    {options.map((option, i) => (
      <li
        key={option.id}
        role="option"
        tabIndex={focusedIndex === i ? 0 : -1}
        onClick={() => selectOption(option)}
        onFocus={() => setFocusedIndex(i)}
      >
        {option.label}
      </li>
    ))}
  </ul>
)}

In handleKeyDown, you’d manage ArrowUp/Down to move focusedIndex, Enter or Space to select, and Escape to close and return focus.

Debugging keyboard navigation woes

Testing keyboard accessibility is simple but powerful:

Use Tab and Shift+Tab to navigate through your app’s interactive elements.
Use screen reader tools to check announcements and focus highlights.
Inspect the Accessibility Tree with browser devtools to verify roles and focusability.

If tab skips your component, check:

Does the toggle have a native focusable element or tabindex="0"?
Are interactive items focusable and in tab order?
Are you accidentally using tabindex="-1" where you want tab to land?

If focus gets trapped:

Are you managing focus programmatically on open and close?
Do you have a focus trap or modal code that might be overzealous?

If keyboard events don’t work:

Are you listening for keydown instead of keypress or keyup? keydown is best for handling navigation keys.
Are you calling event.preventDefault() appropriately to avoid default scrolling or key behavior?

Browser devtools Accessibility pane lets you simulate keyboard focus and see the accessibility tree. Also, extensions like Axe or Lighthouse can flag common accessibility issues.

Beyond keyboard: Why accessibility is a team sport

Focus management is just one piece of accessibility. ARIA roles, visual focus indicators, announcements, and semantic HTML all matter. When you build custom UI, you’re responsible for recreating these affordances.

I learned that the best practice is to start with semantic HTML and enhance, rather than replace, native behavior. Use custom components only when necessary, and always test early and often with keyboard and assistive tech.

If you’re stuck, look at well-tested open source libraries like Reach UI or Radix UI. Their source code is a goldmine for how to handle focus and keyboard events right.

Final thoughts

Keyboard accessibility is not a checkbox , it’s a mindset. When you build a custom UI, imagine your app without a mouse. Walk through it with Tab. If you hit a blind spot, that’s where focus management needs work.

Fixing keyboard navigation bugs might feel tedious, but it makes your app usable by millions who rely on keyboards or assistive technology. And often, the fixes improve your code quality and UX for everyone.

So next time you craft a custom dropdown, toggle, or modal, don’t just make it look good , make sure you can tab through it cleanly, see where you are, and never get stuck.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Browser Garbage Collection: What Frontend Engineers Should Know

Srikar Phani Kumar Marti — Mon, 10 Aug 2026 10:41:40 +0000

Ever had your web app slow down after a while or start feeling like it’s chewing through more and more memory? You might have suspected memory leaks , but where exactly do they come from in a browser? How does the browser even decide what memory to free or keep?

I hit this problem recently debugging a single-page app that got sluggish after a few minutes. Some tabs just ballooned their memory usage, and Chrome’s Task Manager was confirming my suspicion: memory just kept climbing.

Turns out, understanding how browsers do garbage collection under the hood cleared up a lot of mystery. It’s not just about your JavaScript variables. The DOM, event listeners, and even closures can silently hold onto memory long after you think you’re done with them.

Let’s walk through what’s really going on.

Garbage collection basics: the browser’s janitor

Your browser’s JavaScript engine, like V8 in Chrome or SpiderMonkey in Firefox, runs your scripts and manages memory. Garbage collection (GC) is the process that finds objects in memory that are no longer reachable by your running code and frees that memory so the app doesn’t grow endlessly.

But how does the browser know what’s "no longer reachable"? It uses a concept called reachability. If your code or the system can still access a value through some chain of references, it’s considered live. Anything else is garbage and eligible to be collected.

Imagine a graph where nodes are objects and edges are references. GC algorithms like mark-and-sweep start from root objects (globals, stack variables) and mark everything reachable. Then everything unmarked is swept away.

But things get tricky when you add the DOM and event listeners into the mix.

JavaScript objects and closures: Your typical GC suspects

When you create variables, objects, functions, or closures, they live in memory as long as you keep references to them. For example:

function makeCounter() {
  let count = 0;
  return () => ++count;
}

const counter = makeCounter();
counter();

Here, the closure returned by makeCounter keeps a hidden reference to count. Garbage collection won’t free count as long as the counter function exists.

This is straightforward, but leaks happen when you accidentally keep references alive longer than needed. For example, storing large objects in global variables or arrays you never clear.

The DOM’s role in memory management

Unlike plain JavaScript objects, DOM nodes are managed both by the browser’s rendering engine and the JavaScript engine. When you create elements:

const div = document.createElement('div');
document.body.appendChild(div);

The browser creates a DOM tree node for that element. But what happens when you remove it?

document.body.removeChild(div);

You might think the node is gone, but if you still hold a JavaScript reference to div, the browser cannot reclaim that memory. That node , and all its children and event listeners , remain in memory.

This is a classic source of leaks: detached DOM nodes.

Event listeners: The sneaky retainers

Event listeners can silently keep DOM nodes and other objects alive. Consider this:

const button = document.querySelector('button');
function onClick() {
  console.log('Clicked');
}
button.addEventListener('click', onClick);

// Later
button.remove();

If you remove button from the DOM but never call button.removeEventListener('click', onClick), the event listener reference stays registered. Many browsers keep that listener and the node alive because the event system holds a reference to the callback and the node.

This leads to memory leaks from unremoved event listeners.

Common memory leak patterns to watch out for

Detached DOM nodes: You remove elements from the document but keep references to them in JavaScript variables or closures.
Forgotten event listeners: Adding listeners without removing them when elements or components unmount.
Closures over large objects: Closures accidentally capturing large data structures that are no longer needed.
Timers and intervals: Using setInterval or setTimeout without clearing them when components unmount, keeping references alive.
Caches that grow indefinitely: Storing data in arrays or maps without eviction policies.

How browsers perform garbage collection under the hood

Modern JavaScript engines use generational garbage collection. They optimize for the fact that most objects die young.

Young generation: Newly created objects are allocated here. GC runs frequently and quickly here.
Old generation: Objects that survive multiple GC cycles are promoted here. GC runs less frequently but is more thorough.

This means your memory leaks often occur in the old generation , objects that never get freed because something still holds a reference.

When a GC cycle runs, it starts from root objects like:

Global window and document objects
Active function call stacks
Registered event listeners

and marks all reachable objects.

Anything not reachable is cleaned up, including detached DOM nodes and unused JavaScript objects.

Debugging memory leaks: Practical tips

Chrome DevTools Memory tab

Open Chrome DevTools and go to the Memory panel.

Heap snapshot: Take snapshots before and after interactions to see what objects remain.
Allocation instrumentation: Record allocations over time to find growing memory.
Allocation sampling: Profile allocations to find high-memory objects.

Detect detached DOM nodes

In the Elements panel, you can search for nodes that are no longer attached to the document but still in memory.

You can also use this snippet to find detached nodes:

const all = [...document.querySelectorAll('*')];
const detached = all.filter(el => !document.contains(el));
console.log(detached);

Track event listeners

Chrome DevTools also lets you inspect event listeners on DOM nodes. Make sure listeners are removed when not needed.

Use getEventListeners(node) in the console to list them.

Heap snapshot comparisons

Take snapshots at different times and compare to see what objects persist unexpectedly.

Profiling closures

Closures holding memory can be tricky. Look for retained objects in heap snapshots and trace retainers.

Practical habits to avoid leaks

Always clean up event listeners when elements or components unmount.
Remove references to DOM nodes after removing them from the document.
Clear timers and intervals when no longer needed.
Avoid storing large data in global variables or long-lived caches without limits.
Use tools like Chrome DevTools regularly to profile memory, especially after complex UI interactions or dynamic content loads.

When frameworks help , and when they don’t

Modern frontend frameworks like React, Vue, and Angular help manage DOM lifecycle and event listeners for you. But leaks still happen:

If you create event listeners outside the framework lifecycle.
If you keep references to DOM nodes in variables or closures.
If you misuse refs or fail to clean up timers.

Understanding browser GC mechanics helps you spot these issues even when using frameworks.

Next time your web app feels sluggish or your tab’s memory ballooning, remember it’s usually a matter of references the browser can’t drop. The garbage collector is silently cleaning up what it can, but it can’t free what you still hold.

Knowing how JavaScript objects, DOM nodes, and event listeners interact with memory lets you write cleaner code, prevent leaks, and keep your app running smoothly , no magic, just a bit of detective work under the hood.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

React Suspense and Error Boundaries: How They Interact and How to Debug Failures

Srikar Phani Kumar Marti — Thu, 06 Aug 2026 14:02:57 +0000

Ever had your React component throw an error inside a Suspense boundary and wondered why neither your Suspense fallback nor your Error Boundary’s fallback UI showed up?

I ran into this exact headache recently. I wrapped my lazy-loaded component with Suspense and an Error Boundary, expecting either a spinner or an error message. Instead, I got… nothing. Blank screen. No clues.

Turns out, Suspense and Error Boundaries have a subtle but important dance happening under the hood. Let me walk you through what’s really going on, why React sometimes seems to silently swallow errors or fallbacks, and how you can debug these tricky states.

The moment when Suspense and errors collide

Imagine this setup:

<Suspense fallback={<LoadingSpinner />}>
  <ErrorBoundary fallback={<ErrorMessage />}>
    <LazyComponent />
  </ErrorBoundary>
</Suspense>

Your LazyComponent suspends while fetching data, so the spinner shows up. Great. But what if LazyComponent throws an error before the data arrives? You’d expect the ErrorBoundary to catch that and show the error message, right?

Not always.

In React’s commit phase , that is, when React applies changes to the DOM , if a component suspends, React bails out of rendering that tree and instead shows the Suspense fallback immediately. But if the same component throws an error (instead of suspending), React tries to find the nearest Error Boundary to handle it.

Here’s the catch: Suspense boundaries only catch suspensions. They don’t catch errors. Error Boundaries catch errors but don’t catch suspensions.

When a component inside Suspense throws an error, React’s update flow attempts to recover by unwinding to the Error Boundary. But if Suspense is the outer wrapper, React’s internal scheduling and commit phases can get tangled, causing neither fallback UI to appear.

What React does internally when errors happen inside Suspense

React uses a concept called "lanes" to prioritize updates and tracks whether a component tree is suspended or errored during render and commit phases.

When an error is thrown during rendering, React marks the fiber tree as "errored" and looks up the tree for the closest Error Boundary to handle it. If found, React schedules an error recovery update to replace the errored subtree with the Error Boundary’s fallback UI.

But if that errored subtree is inside a Suspense boundary that also suspended, React’s internal state can get confused:

Suspense boundaries expect a suspension to show fallback UI.
Error Boundaries expect an error to show fallback UI.
When both happen close together or in nested trees, React prioritizes suspensions and sometimes skips error handling in that render cycle.

This can cause your app to render nothing or show stale UI with no clear indication of what went wrong.

Common bugs that cause fallback UI to silently fail

1. Wrapping Suspense outside Error Boundaries

In the example earlier, Suspense wraps the Error Boundary. This means Suspense tries to handle suspensions first. If an error happens inside, Suspense doesn’t catch it , and the error bubbles up past Suspense.

But React’s commit phase handles Suspense boundaries differently than Error Boundaries, and because Suspense is outermost, React can get stuck showing no fallback.

Fix: Wrap Suspense inside the Error Boundary instead:

<ErrorBoundary fallback={<ErrorMessage />}>
  <Suspense fallback={<LoadingSpinner />}>
    <LazyComponent />
  </Suspense>
</ErrorBoundary>

Now errors get caught by the Error Boundary before Suspense tries to handle suspensions.

2. Throwing errors asynchronously after suspending

If your component suspends by throwing a Promise, then later throws an error during commit or an effect, React’s update flow can get tricky. The Suspense fallback might show briefly, then the error triggers. But the Error Boundary’s fallback may not replace the Suspense fallback immediately, causing flickers or blank UI.

3. Nested Suspense boundaries with missing Error Boundaries

If you have multiple nested Suspense boundaries but no Error Boundary catching errors inside, React renders fallback UIs for suspensions but crashes silently on errors, often logging cryptic warnings.

Debugging strategies to untangle Suspense + Error Boundary issues

Inspect React DevTools Fiber tree

React DevTools now show Suspense and Error Boundary components explicitly. When your UI disappears or fallback UI doesn’t appear, inspect the fiber tree.

Look for:

Suspense boundaries marked as "suspended"
Error Boundaries marked as "errored"

If you see Suspense suspended but no error, it means React is still waiting on a Promise.

If you see Error Boundaries errored but no fallback UI, React might be skipping commit phases or your fallback component itself is throwing.

Add logging in error handlers

In your Error Boundary’s componentDidCatch or getDerivedStateFromError, log the error and info objects. This confirms the boundary is catching the error.

If you never see logs, React didn’t find your boundary.

Use `React.unstable_DebugTracingMode` (experimental)

In recent React versions, enabling this mode helps trace Suspense and error boundary interactions in the console, showing when boundaries suspend, resume, or error.

Check your error fallback components

Sometimes Error Boundary fallbacks throw errors themselves, causing React to unmount everything.

Wrap fallback UI in try/catch or keep it simple to isolate this.

How React’s update phases influence fallback rendering

React separates rendering into two steps:

Render phase: React calls your components to build a new fiber tree. This phase is pure , no side effects or DOM mutations.
Commit phase: React applies changes to the DOM, runs effects, and handles errors thrown here differently.

Suspensions happen during render phase, triggering React to delay committing the new UI and show Suspense fallback instead.

Errors can happen during render or commit.

If an error occurs during render, React tries to recover by rendering the nearest Error Boundary’s fallback in the next render phase.

If an error happens during commit (e.g., in an effect or lifecycle method), React unmounts the whole tree unless you have an error boundary.

Understanding this helps you see why sometimes the Suspense fallback shows, but the Error Boundary never does , or vice versa.

Practical takeaway: how to organize Suspense and Error Boundaries

Wrap Suspense inside Error Boundary if you want to catch errors thrown inside lazy or suspenseful components.
Keep your error fallback UI simple and robust to avoid cascading failures.
Avoid throwing errors asynchronously after suspensions if possible, or handle those with additional boundaries.
Test your boundaries by manually throwing errors and suspending promises to see the fallback behavior.

Final thought

React’s Suspense and Error Boundaries are powerful but can trip you up when they interact. When your fallback UI disappears or you see a blank screen, the problem is often in how these boundaries are nested and how React schedules updates.

With a little digging into React’s phases and careful boundary placement, you can tame these quirks and build reliable loading and error states. Next time you hit a ghostly blank screen, you’ll know exactly where to look.

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Debugging Complex Pointer and Touch Event Interactions in Mobile Browsers

Srikar Phani Kumar Marti — Tue, 04 Aug 2026 14:31:01 +0000

Ever tried to build a smooth swipe or pinch gesture on mobile only to find it firing weird events, missing touches, or blocking scroll? If you’ve been there, you know it quickly devolves into a maze of event handlers, mysterious no-ops, and contradictory docs.

I recently spent days debugging a custom gesture recognizer for a mobile web app and finally got to the bottom of how browsers handle pointer, touch, and gesture events differently on mobile versus desktop. Spoiler: it’s not just about firing different events , it’s the event order, default behaviors, and subtle browser quirks that trip you up.

Let’s get practical. I’ll share concrete examples, what’s going on under the hood, and exactly how to debug these interactions using Chrome DevTools.

The moment things got weird: touch events firing but pointer events missing

My app needed to detect a two-finger swipe. I started by listening to pointerdown, pointermove, and pointerup events because pointer events unify mouse, touch, and pen input nicely on desktop.

On laptop browsers, this was smooth sailing. But on mobile, sometimes the pointer events never fired, or fired inconsistently. I was baffled.

Digging deeper, I learned that on mobile browsers, pointer events are often built on top of touch events but with extra layers of logic to handle gestures and scrolling. Sometimes the browser suppresses pointer events after detecting a gesture like scrolling, or delays them until it’s sure the user isn’t zooming. This behavior differs a lot across browsers and platforms.

Here’s a quick example:

el.addEventListener('touchstart', e => console.log('touchstart'));
el.addEventListener('pointerdown', e => console.log('pointerdown'));

On desktop emulation, you’ll see both events fire. But on real mobile Safari, pointerdown might not fire at all if the browser thinks the touch might become a gesture.

Why event sequences differ so much on mobile

The event pipeline on mobile is more complex because the browser must decide whether a touch is:

A tap
A scroll
A zoom (pinch or double tap)
A custom gesture

To do this, browsers delay or cancel pointer events based on heuristics like touch slop (how far a finger moves before the gesture is considered a scroll).

For example, if the user places a finger and starts scrolling, the browser may:

Fire touchstart
Delay or cancel pointerdown
Fire touchmove
Cancel pointer events entirely if scrolling starts

This means your pointer event handlers might never get called if the browser claims the gesture.

The tricky default behaviors and event.preventDefault()

Another common trap is the interaction between the browser’s default touch behaviors (like scrolling and zooming) and your event handlers.

Calling event.preventDefault() on touchstart or touchmove can stop scrolling, but:

On some browsers, touch-action CSS is a better way to declare which gestures your app handles
Using preventDefault() indiscriminately can hurt scroll performance and cause jank

For example, to enable custom horizontal swipe but preserve vertical scroll, setting CSS like this helps:

.swipe-area {
  touch-action: pan-y;
}

This tells the browser: "I want to handle horizontal gestures myself, but let vertical scrolling happen normally." Browsers then won’t cancel pointer events for vertical scrolls.

Common pitfalls with custom gesture recognizers

If you’re building gestures from scratch, here are things I ran into:

Mixing touch and pointer events without clear strategy: Listening to both can cause duplicate events or missed ones if you don’t account for the browser’s gesture detection.
Not using touch-action properly: Without it, browsers may cancel pointer events or delay them, breaking your recognizer.
Ignoring multiple pointers: Mobile touch means multiple fingers at once. Pointer events help here, but on some browsers, pointer events don’t fire or lose track of pointer IDs.
Relying on event.preventDefault() too much: Blocks scrolling and hurts performance.

How I debugged these issues in DevTools

Mobile event debugging is tricky because you need to see event timing and ordering on real devices. Here’s what helped me:

Remote debugging with Chrome DevTools: Connect your Android device via USB and use chrome://inspect to debug mobile Chrome. You can set breakpoints in event handlers and watch event objects.
Logging event sequences: I added console logs for every pointer, touch, and gesture event with timestamps and pointer IDs, so I could see exactly which events fired and in what order.
Using the "Event Listener Breakpoints" feature: In DevTools, under Sources > Event Listener Breakpoints, I enabled breakpoints for touch and pointer events to pause exactly when they fire.
Inspecting CSS touch-action: I repeatedly inspected the element’s computed styles to verify touch-action was set as intended.
Testing on multiple browsers: I tested on Chrome, Firefox, and Safari on iOS because they behave differently. Sometimes a solution works in one but fails in another.

A concrete example: building a horizontal swipe recognizer that doesn’t block vertical scroll

Here’s a minimal setup that worked after much trial and error:

<div id="swipe" style="touch-action: pan-y; width: 100vw; height: 200px; background: #eee;">
  Swipe me horizontally
</div>
<script>
  const el = document.getElementById('swipe');
  let startX = null;
  let startY = null;

  el.addEventListener('pointerdown', e => {
    startX = e.clientX;
    startY = e.clientY;
  });

  el.addEventListener('pointermove', e => {
    if (startX === null) return;
    const dx = e.clientX - startX;
    const dy = e.clientY - startY;

    if (Math.abs(dx) > Math.abs(dy)) {
      // Horizontal swipe detected
      e.preventDefault(); // prevent scrolling horizontally
      console.log('Horizontal swipe', dx);
    }
  });

  el.addEventListener('pointerup', () => {
    startX = null;
    startY = null;
  });
</script>

Key points:

touch-action: pan-y lets vertical scroll happen normally.
We listen only to pointer events for clarity.
e.preventDefault() is called only when a horizontal swipe is actually detected, minimizing interference with scroll.

Wrapping up

Mobile pointer and touch event handling feels like a black box until you see the browser’s hesitation and decision tree in action. Knowing the event sequence differences, the role of touch-action, and how default behaviors affect your handlers can save hours of debugging.

Next time your custom gesture is flaky on mobile, try logging every touch and pointer event with timestamps, check your touch-action CSS, and don’t throw preventDefault() around blindly. Use remote debugging tools to watch the event flow live.

You’ll find the browser is trying to help you , it just wants to make sure scrolling and zooming work smoothly, even while you capture your fancy new gesture.

Happy debugging!

Helpful learning resources

MDN Web Docs
web.dev performance guidance
OpenAI developer resources Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

React Concurrent Rendering: Scheduling, Interruptions, and Debugging Suspense Boundaries

Srikar Phani Kumar Marti — Mon, 03 Aug 2026 12:53:45 +0000

You know that moment when your React Suspense fallback jumps on the screen, then disappears, then reappears, leaving you wondering if you did something wrong? I’ve been there , seeing flickers, multiple loading spinners, or even UI glitches around Suspense felt like chasing ghosts.

Turns out, React’s concurrent rendering scheduler is doing a lot behind the scenes , juggling priorities, pausing work, and restarting it , and Suspense boundaries are right in the middle of this dance. Understanding how React schedules work and handles interruptions can save you hours of frustration.

React’s concurrent rendering scheduler: what’s it really doing?

React’s concurrent mode isn’t just a fancy name; it means React doesn’t blindly render your entire component tree all at once. Instead, it breaks rendering work into chunks and spreads it out over multiple frames. This keeps your app responsive to user input and other high-priority tasks.

Imagine you’re painting a huge mural. Instead of finishing it in one go (blocking everything else), you paint a little, step back, listen if someone calls you, then paint some more. React’s scheduler works similarly:

Units of work: React slices rendering into small units it can pause and resume.
Priorities: Some updates are more urgent , like responding to a click , so they jump ahead.
Interruptions: If something more important comes up, React pauses current work and switches.

This model makes React apps feel snappy even when doing heavy rendering or fetching data.

What happens when Suspense enters the scene?

Suspense boundaries are React’s way to say, “Hey, if this component isn’t ready yet (because it’s waiting on data, code, or something else), show this fallback for now.”

Under the hood, when a component suspends (throws a Promise), React marks that unit of work as "waiting," and the Suspense boundary kicks in to show the fallback UI immediately.

But here’s the catch: React keeps trying to finish rendering the suspended component in the background. When the Promise resolves, React attempts to commit the real UI.

Since this happens with React’s concurrent scheduler, the work can be interrupted or retried multiple times before committing, which explains those flickers or fallback flashes you see.

How React prioritizes and interrupts updates

Let’s say the Suspense boundary is showing a spinner for a data fetch. While the fetch is pending, React is rendering lower-priority work. But if the user types or clicks, React wants to respond immediately:

The scheduler interrupts the current render.
It pauses the Suspense boundary’s work.
It starts a higher-priority render (like updating an input).

Once high-priority work is done, React resumes the Suspense boundary rendering.

This pause-and-resume cycle can happen multiple times, which often causes the fallback to appear and disappear several times rapidly.

Why does Suspense sometimes unexpectedly remount or reset state?

One tricky side effect is that when Suspense boundaries retry rendering, React may discard work in progress and start over. This can cause components inside Suspense to unmount and remount , resetting local state.

For example, if you have a form inside a Suspense boundary, users might lose their input unexpectedly if the boundary retries.

This happens because React’s internal fiber tree abandons the current render and attempts a fresh one when interrupted or when new data arrives.

Debugging Suspense boundaries in production

When Suspense boundaries behave oddly, here’s how to get a clearer picture:

Enable React DevTools Profiler: It shows you when rendering work starts, suspends, and commits.
Use React.unstable_trace or React 18’s tracing APIs: They help track update flows and see interruptions.
Add logging inside your Suspense fallback and wrapped components: Knowing when they mount, unmount, or suspend helps.
Check for state resets: If state inside Suspense resets unexpectedly, consider moving state above the boundary or using useRef to preserve values.

Practical tips to reduce flickers and interruptions

Batch updates: Group multiple setState calls to reduce intermediate renders.
Use useTransition wisely: Mark non-urgent updates as transitions so React can better prioritize.
Split Suspense boundaries thoughtfully: Smaller boundaries isolate suspensions and reduce widespread UI resets.
Avoid putting critical state inside Suspense boundaries that might remount.

When you want to dive deeper into the scheduler

React’s scheduler uses priority lanes internally , like lanes on a highway , to organize and reorder work. High priority lanes are for urgent tasks like user input, while low priority lanes are for background data loading.

If you’re curious, the React source code and some community tools expose these internals so you can peek under the hood.

Understanding this helps explain why some updates interrupt others and how React keeps your app responsive even during heavy lifting.

React’s concurrent rendering isn’t magic, but it’s subtle. That flickering spinner or disappearing UI isn’t a bug , it’s React doing its best to balance responsiveness and completeness.

With this inside view of scheduling, interruptions, and Suspense boundaries, you can debug smarter, design boundaries better, and build smoother experiences for your users.

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

How Browsers Handle Keyboard Events: From Raw Input to DOM Events

Srikar Phani Kumar Marti — Fri, 31 Jul 2026 12:57:23 +0000

Ever been bitten by a keyboard event bug where your app gets multiple keydown events for a single press, or where input composition (hello, IMEs!) breaks your form? Or maybe you’ve seen different browsers fire keyboard events in different orders and wondered what’s going on.

I recently spent a frustrating afternoon debugging exactly that kind of issue. The app had subtle bugs: repeated characters flooding inputs, missed keyup events, and weird behavior when users typed accented characters on macOS vs Windows.

Turns out, keyboard event handling in browsers is a surprisingly intricate dance. It’s not just “key pressed, event fired.” There’s a whole pipeline from the raw OS input, through composition and key repeat, to DOM events that your JavaScript sees.

Let me walk you through the journey of a single keystroke, from the raw hardware signal all the way to the DOM event listeners that your code hooks into, and why understanding this can save you hours of debugging.

When you press a key, the OS speaks first

Your keyboard doesn’t talk directly to the browser. It communicates with the operating system, which interprets raw scan codes and decides what key was pressed, taking into account keyboard layout, modifiers, accessibility settings, and input method editors (IMEs).

The OS then sends processed key events to the browser. This is why your keyboard layout or system language can change the keys you get in JavaScript.

The browser’s input pipeline: raw event to DOM event

Browsers receive low-level key signals from the OS and transform them into the DOM keyboard events you use: keydown, keypress (deprecated but still around), and keyup.

Here’s the usual event flow for a single physical key press:

keydown: Fired immediately when the key is physically pressed down.
keypress: Fired only for keys that produce a character value. This event is deprecated but still emitted in many browsers.
input: For text input fields, when the key produces a character, the input event fires to reflect text changes.
keyup: Fired when the key is released.

But it’s not always this simple.

Key repeat

Holding down a key triggers multiple keydown and keypress events due to key repeat. The browser fires these events repeatedly until you release the key, and then a single keyup is fired.

This often surprises developers who expect only one keydown per press. Handling key repeat requires explicit logic if you want to ignore repeats or treat them differently.

You can check event.repeat to distinguish repeated keydown events.

Composition events for IMEs

Input Method Editors introduce another layer. For complex input like Japanese, Chinese, or accented characters, a single character can require multiple keystrokes before it’s finalized.

During composition, browsers emit compositionstart, multiple compositionupdate, and finally compositionend events. The DOM does not emit normal keydown/keypress events for every raw key during composition, or the text input changes might be incomplete or wrong.

Handling composition properly is critical for internationalized apps, or you’ll break input for a large user base.

Order matters: event sequence and quirks across browsers

The exact event sequence can differ between browsers or platforms. For example:

Some browsers fire keypress after keydown, others fire it before.
macOS Safari historically fires keydown only once per physical press, not repeating with key hold.
Windows Chrome and Firefox repeat keydown and keypress during key hold.
During IME composition, key events may be suppressed or delayed.

These differences make debugging keyboard input across browsers a headache.

Practical debugging tips

If you’re confused why your key handler behaves differently across browsers, try this:

window.addEventListener('keydown', e => console.log('keydown', e.key, e.code, 'repeat:', e.repeat));
window.addEventListener('keypress', e => console.log('keypress', e.key, e.code));
window.addEventListener('keyup', e => console.log('keyup', e.key, e.code));
window.addEventListener('compositionstart', e => console.log('compositionstart'));
window.addEventListener('compositionupdate', e => console.log('compositionupdate'));
window.addEventListener('compositionend', e => console.log('compositionend'));

Test typing normal keys, holding keys down, and using IMEs. Notice the event order, which events fire, and whether repeat is true.

Why your input bugs might be composition bugs

If you see your input event handlers getting unexpected partial text or spamming multiple events during accented character input, check your composition event handling.

Ignoring composition events can make your app behave like it’s broken when users type non-ASCII characters.

A common pattern is to ignore key events during composition:

let isComposing = false;

input.addEventListener('compositionstart', () => { isComposing = true; });
input.addEventListener('compositionend', () => { isComposing = false; });

input.addEventListener('keydown', e => {
  if (isComposing) return; // ignore during composition
  // handle keydown normally
});

Wrapping up

Keyboard input is deceptively complex. The OS, the browser, and your app all play a part in deciding how key events flow.

Understanding the event sequence, key repeat, and composition events helps you write more robust input handlers, avoid cross-browser bugs, and build better user experiences, especially for international users.

Next time you debug a keyboard event mystery, remember: it’s not just your code. It’s a whole pipeline under the hood.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Screen Reader Handling of ARIA Live Regions: Timing, Interruptions, and Debugging

Srikar Phani Kumar Marti — Tue, 28 Jul 2026 11:16:13 +0000

Ever had a situation where you update a live notification region in your SPA, but the screen reader stays silent? Or worse, it reads some old message, then skips your update altogether?

I ran into this exact problem recently while working on an accessibility feature that used ARIA live regions to announce dynamic content changes. The updates were there, the DOM was correct, but screen readers just wouldn’t read the new content reliably.

Turns out, live region announcements are not as straightforward as just toggling aria-live. There’s a subtle timing dance behind the scenes, and interruptions can silently swallow your messages. Let me walk you through what I learned debugging this, how screen readers handle live region updates, why timing matters, and practical ways to get your ARIA live announcements working consistently.

The weird silence: live region updates don’t always get announced

I had a <div aria-live="polite"> that I updated with new status messages from an async process. When I tested with NVDA and VoiceOver, the first message would be read, but subsequent updates were sometimes ignored.

At first, I thought my updates weren’t reaching the DOM or the live region was stale. But inspecting with accessibility tools confirmed everything was in place.

Why the silence?

How screen readers process ARIA live regions

Screen readers maintain an internal accessibility tree representing the current UI state. When the DOM changes inside an ARIA live region, the screen reader detects those changes and queues announcements.

But this queue is subject to:

Timing thresholds: screen readers batch rapid-fire changes to avoid reading an avalanche of messages.
Interruptions: a user’s current announcement can block or cancel queued messages.
Change heuristics: not all changes trigger announcements, e.g., if the content didn't actually change textually.

For example, NVDA waits a little after an update before announcing, to gather potential additional changes. If you update the live region content multiple times quickly, only the last change might get read.

The problem with rapid updates and DOM mutations

Imagine your async process emits several updates in under a second. You might:

liveRegion.textContent = 'Step 1 completed';
liveRegion.textContent = 'Step 2 completed';
liveRegion.textContent = 'All done!';

Only "All done!" might get announced, because the screen reader batches the changes and only reads the final state.

Sometimes, if the updates happen too fast, the screen reader might not even detect intermediate changes.

Interruptions: how user focus and speech affect announcements

Screen readers can interrupt or suppress live region announcements if the user is already listening to something else:

If the user is navigating the page with the keyboard or mouse.
If another alert or live region is currently being read.
If the screen reader is busy announcing system messages.

This means your live region updates can be silently dropped or delayed.

Debugging live region announcements

To figure out what’s going on, I tried:

Logging live region content changes to confirm updates happened.
Slowing down updates with setTimeout to space out announcements.
Using different aria-live values like assertive and polite to test priority impacts.
Testing with multiple screen readers (NVDA, JAWS, VoiceOver) since each has quirks.
Using browser extensions like Accessibility Insights or VoiceOver Utility to inspect the live region's accessibility tree.

One useful trick was creating a small demo page where I manually controlled live region updates via buttons and timers. This let me isolate timing and interruption behaviors.

Under the hood: what you can do to improve live region reliability

Throttle or debounce your updates. Avoid flooding the live region with rapid changes. Group related updates and announce consolidated messages.
Clear the live region before updating. Setting textContent = '' briefly before inserting new text can force screen readers to recognize a fresh change.
Use a hidden off-screen live region element. Sometimes toggling visibility or using a separate hidden live region helps isolate announcements.
Experiment with aria-atomic. Setting aria-atomic="true" tells screen readers to read the entire live region content on change, which helps when partial updates confuse them.
Match your live region role to the context. Use role="alert" for urgent messages (immediate announcements) and aria-live="polite" for less disruptive updates.
Test with real users and multiple screen readers. Each has different heuristics and timing rules.

A concrete example: reliable live region updates in a SPA

Here’s a snippet I ended up using for a status message live region:

const liveRegion = document.getElementById('statusLiveRegion');

function announceStatus(message) {
  // Clear the region to reset announcer
  liveRegion.textContent = '';

  // Add a small delay before updating content
  setTimeout(() => {
    liveRegion.textContent = message;
  }, 100);
}

This brief delay and clearing step forces screen readers to catch the change as new content, not just an update.

On the HTML side:

<div
  id="statusLiveRegion"
  aria-live="polite"
  aria-atomic="true"
  style="position:absolute; width:1px; height:1px; overflow:hidden; clip:rect(1px, 1px, 1px, 1px);"
></div>

This setup worked consistently across NVDA, JAWS, and VoiceOver during my testing.

Why this still isn’t perfect

Screen reader implementations vary wildly. Some might ignore live region updates if the user has disabled announcements or if the browser accessibility API behaves differently.

Also, complex content inside live regions (HTML markup, images, or dynamic widgets) can confuse announcements.

The best you can do is:

Keep live region content simple and textual.
Minimize rapid updates.
Test on your target platforms.

What I wish I knew sooner

I wasted hours chasing bugs where live region content was correct but announcements silent. Understanding the importance of timing and interruptions was a game changer.

Also, don’t assume aria-live is magic. It’s a hint to screen readers, which have their own rules and priorities.

Next time you build dynamic live notifications in your app, remember it’s a conversation between your DOM and the screen reader’s internal queue. Getting the timing and content right is how you make that conversation audible.

Give these tips a try and save yourself the frustration of silent live regions!

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

DEV Community: Srikar Phani Kumar Marti

ARIA Role Inheritance and Override: How Browsers Resolve Conflicting Semantics

The tangled web of ARIA roles and properties

How browsers pick the winning ARIA role

What about conflicting ARIA properties?

Under the hood: the accessibility tree and role resolution

Debugging tips: How to see the computed ARIA role and properties

Common pitfalls and how to avoid them

Why does this matter?

Helpful learning resources

Optimizing Keyboard Navigation in Complex Web Apps: Techniques and Debugging Tools

When Keyboard Navigation Gets Messy

The Core Principles Under the Hood

Focusability: What Can Receive Focus?

Managing Focus on State Changes

Keyboard Event Handling

Tools to See What’s Really Happening

Browser DevTools - Focus Debugging

Screen Reader Testing

Keyboard Event Listeners in Debug Mode

Practical Techniques to Fix Common Issues

1. Prefer Native Elements When Possible

2. Use tabindex Sparingly and Correctly

3. Implement Focus Management on Open/Close

4. Trap Focus Inside Modals

5. Handle Arrow Keys and Other Navigation Keys

Wrangling a Real Bug: A Case Study

Wrapping Up

Helpful learning resources

CSS Container Queries: How Browsers Calculate and Recalculate Styles

When container queries hit the scene

The container query workflow inside browsers

How does the browser detect container size changes?

What happens when a container size changes?

Under the hood: container queries and the rendering pipeline

Real-world debugging tips for container queries

1. Check if your container actually has container-type set

2. Verify the container’s size

3. Understand container sizing modes

4. Beware of nested containers

5. Watch out for layout thrashing

6. Use Resize Observer for debugging

What’s next with container queries?

Wrap-up

Helpful learning resources

React Portals: How They Work and When to Use Them for Modals and Tooltips

What Exactly Is a React Portal?

What Happens Under the Hood?

Event Propagation Isn’t Broken , But It’s Different

Focus Management: The Invisible Trap

Practical Debugging Tips for Portal-Based Modals and Tooltips

1. Use ref on the Portal Container

2. Attach Event Listeners on the Portal Container

3. Manage Focus Explicitly

4. Watch for CSS Stacking Context Issues

5. Beware of Event Ordering Differences

When Should You Reach for Portals?

A Real Debugging Story

Wrapping Up

Helpful learning resources

Debugging React Memoization: When useMemo and React.memo Backfire

Why Memoization Exists in React

The Shallow Equality Trap

What’s going on?

How to fix it?

When useMemo Doesn’t Memoize What You Think

Debug tip:

Stale Props and State Due to Memoization

Example:

What’s the solution?

React.memo with Custom Comparison Functions

Debugging Memoization Issues Step-by-Step

When Not to Use Memoization

Wrapping Up

Helpful learning resources

Keyboard Accessibility in Custom Components: Implementing and Debugging Focus Management

The focus trap: Why keyboard users get stuck or skipped

How browser focus and tab order really work

Implementing keyboard support in custom components

Debugging keyboard navigation woes

2. Use `tabindex` Sparingly and Correctly

1. Check if your container actually has `container-type` set

1. Use `ref` on the Portal Container

Use `React.unstable_DebugTracingMode` (experimental)