Q246: Accessibility, Performance and Inclusive Interactions

What Interviewers Want To Evaluate

Interviewers want to know whether you understand that performance and accessibility are both user experience concerns.

They check keyboard responsiveness, focus management, reduced motion, accessible loading states, layout stability, screen reader announcements, semantic controls, and how performance optimizations can accidentally harm accessibility.

Short Interview Answer

Performance and accessibility should reinforce each other. A fast UI must still be keyboard accessible, announce loading and errors correctly, preserve focus, respect reduced motion, and avoid layout shifts that disorient users. I evaluate optimizations like virtualization, lazy loading, skeletons, animations, and client islands against accessibility behavior, not only metrics.

Detailed Interview Answer

Performance work can improve accessibility.

Examples:

fast input response helps keyboard users
stable layout helps screen magnifier users
reduced JavaScript improves low-end assistive tech setups
clear loading states help screen reader users

But performance work can also break accessibility.

Keyboard Responsiveness

Keyboard interactions need low latency.

Important interactions:

tab navigation
menu opening
dialog close
typeahead search
form input
accordion expand
practice console shortcuts

If JavaScript blocks the main thread, keyboard users feel it immediately.

INP is relevant here.

Focus Management

Performance optimizations must preserve focus.

Risky patterns:

remounting large UI sections
virtualizing focused items incorrectly
replacing content after async load
opening modal without moving focus
closing modal without restoring focus

If focus disappears, the interface becomes difficult or impossible to operate.

Reduced Motion

Respect user preference.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms;
    scroll-behavior: auto;
  }
}

Do not rely on motion as the only way to communicate state.

Reduced motion can also reduce rendering work.

Loading States

Loading states should be accessible.

Good loading UX:

stable layout
specific loading text where needed
aria-busy for relevant regions
live region for important completion
skeletons that match final size
localized failure states

Avoid blank pages and silent updates.

Virtualization Trade-Offs

Virtualization improves performance for large lists.

It can harm accessibility if:

screen reader cannot understand list size
focused item unmounts
keyboard navigation skips items
find-in-page cannot find offscreen content
scroll position becomes confusing

Use virtualization carefully for interactive lists.

For static readable content, pagination or server rendering may be better.

Lazy Loading Content

Lazy loading can improve initial performance.

But be careful with:

content needed by screen readers
content targeted by anchors
focusable controls loaded late
layout shifts
search and find behavior

Lazy load optional and below-the-fold content, not essential controls.

Semantic Controls

Do not replace native controls for styling.

Native controls provide:

keyboard behavior
focus behavior
semantics
disabled behavior
form integration
screen reader support

Custom controls need more JavaScript and more accessibility work.

Performance and accessibility often both prefer native elements.

Common Mistakes

Common mistakes include:

optimizing with virtualization but breaking focus
using animation-heavy feedback without reduced motion support
showing skeletons that cause layout shift
lazy-loading important controls
using divs instead of buttons
not announcing async errors
testing performance without keyboard usage

Accessibility bugs are user experience bugs.

Senior Trade-Offs

Optimization must be evaluated by user impact.

Trade-offs:

virtualization vs screen reader continuity
lazy loading vs discoverability
animation polish vs reduced motion
client islands vs focus preservation
skeletons vs semantic loading text

Metrics do not replace inclusive testing.

Interview Framing

In an interview, say:

I treat accessibility and performance together. I make interactions fast, but I verify focus, keyboard behavior, reduced motion, semantic controls, loading announcements, and layout stability after every optimization.

Revision Notes

• Fast UI still needs accessible behavior.
• Main-thread blocking hurts keyboard responsiveness.
• Focus must survive async loading and remounts.
• Reduced motion is both accessibility and comfort.
• Virtualization needs accessibility review.
• Native controls often improve both performance and accessibility.

Follow-Up Questions

• How can virtualization hurt accessibility?
• Why does INP matter for keyboard users?
• How should loading states be announced?
• What does reduced motion change?
• Why prefer native buttons over custom div controls?

How I Would Answer This In A Real Interview

I would say performance work is incomplete if it makes the product harder to use. I would check keyboard responsiveness, focus management, reduced motion, semantic controls, screen reader announcements, and layout stability. If I use virtualization, lazy loading, or client islands, I would test those choices with keyboard and assistive technology behavior, not just with performance scores.