Free lesson · Frontend System Design

The dimension that separates senior engineers from the rest

Medium10 min readfrontendsystem-design

There's a quiet test that runs through many senior frontend interviews, and most candidates fail it without realizing it was being administered. You're asked to design a component - an autocomplete, a modal, a custom dropdown - and you build something that works beautifully with a mouse, on your screen, for you. And the interviewer notes, silently, that you never once mentioned the keyboard, the screen reader, the focus order, or the contrast. That omission is the test, and failing it signals "builds for themselves, not for all users" - the opposite of the craftsmanship senior roles require. Accessibility is one of the clearest dividing lines between engineers who think a feature is done when it works for them and engineers who think it's done when it works for everyone. This cluster is about being on the right side of that line, and this opening lesson establishes why accessibility matters, what it encompasses, and why it shows up precisely in senior interviews.

The framing the cluster insists on, against the most common mistake: accessibility is a design concern from the start, not a remediation afterthought. Building it in is straightforward; bolting it on later is expensive, painful, and produces worse results - the same lesson as security and performance, which also fail when treated as a final polish step. Accessibility woven into how you build components is cheap and natural; accessibility retrofitted onto an inaccessible app is a costly remediation project. So the disposition this cluster cultivates is to consider accessibility as you design, the way you consider performance and security - continuously, not at the end.

What accessibility is

Accessibility (often abbreviated a11y) means building products that people with disabilities can use - and the range of disabilities is broader than most engineers picture:

Visual - people who are blind (using screen readers), have low vision (using magnification and high contrast), or are color blind (unable to distinguish certain colors).
Motor - people who can't use a mouse (using a keyboard, switch devices, or voice control), or who have limited dexterity or tremors.
Auditory - people who are deaf or hard of hearing (needing captions and transcripts for audio/video).
Cognitive - people with conditions affecting attention, memory, reading, or processing (needing clear structure, plain language, and predictable interfaces).

And crucially, disability isn't only permanent. The disability spectrum spans permanent, temporary, and situational:

Permanent - a person who is blind, or has one arm.
Temporary - a person with a broken arm (temporary motor limitation), or an eye infection (temporary visual limitation).
Situational - a person holding a baby (one-handed, like the broken arm), in bright sunlight (can't see a low-contrast screen, like low vision), in a loud environment (can't hear audio, like deafness), or on a slow connection in a moving train.

graph TD
    Disability[Disability spectrum] --> Perm[Permanent<br/>blind, one arm, deaf]
    Disability --> Temp[Temporary<br/>broken arm, eye infection]
    Disability --> Sit[Situational<br/>holding a baby, bright sun,<br/>loud room, moving train]
    Perm --> Same[Same access needs<br/>→ same solutions]
    Temp --> Same
    Sit --> Same
    Same --> Curb[Designing for disability<br/>helps EVERYONE<br/>'curb-cut effect']

This diagram shows the disability spectrum. Disabilities can be permanent, like being blind, having one arm, or being deaf; temporary, like a broken arm or an eye infection; or situational, like holding a baby, being in bright sunlight, in a loud room, or on a moving train. The important insight is that all three share the same access needs and therefore the same solutions - a one-handed solution serves the person with one arm, the broken arm, and the parent holding a baby alike. This is why designing for disability helps everyone, a phenomenon called the curb-cut effect.

The disability spectrum: permanent, temporary, and situational needs converge on the same solutions - which is why accessibility benefits everyone (the curb-cut effect).

This spectrum reframes accessibility profoundly: it's not a niche concern for a small group - at any given moment, a huge share of your users have some access need, whether permanent, temporary, or situational. The person holding a baby needs your interface to work one-handed exactly like the person with a motor disability. This is the curb-cut effect: curb cuts (the ramps in sidewalks) were built for wheelchairs but help everyone - people with strollers, luggage, bikes. Accessibility features follow the same pattern: captions help people in loud rooms and people learning the language; keyboard navigation helps power users; clear structure helps everyone. Designing for disability improves the product for all users, which is why accessibility isn't charity - it's good design.

Why accessibility matters

Several converging reasons make accessibility a genuine priority, not an optional nicety:

It's the right thing - inclusion. Excluding people with disabilities from your product is excluding real people from things they need to do (banking, shopping, working, learning). This connects to the equity theme from the performance cluster: just as performance is about not excluding users on poor devices, accessibility is about not excluding users with disabilities. Both are about who gets to use what you build.

It's the law. Accessibility is legally required in many contexts - the Americans with Disabilities Act (ADA) in the US, Section 508 for US government, the European Accessibility Act (EAA), and others - typically referencing the WCAG standard. Inaccessible products generate real legal risk; accessibility-related lawsuits are common and rising. For a business, accessibility is a compliance requirement, not a preference (much like the privacy compliance from the security cluster).

It's a larger audience. A significant percentage of the population has a disability, and accounting for temporary and situational needs, the share of users who benefit from accessibility is far larger still. Inaccessible products lose those users (and their business); accessible ones reach everyone.

It overlaps with quality. Accessible code tends to be better code - semantic HTML (the foundation of accessibility) also improves SEO, maintainability, and works better with the platform. Accessibility and engineering quality reinforce each other.

WCAG and the POUR principles

The standard for accessibility is WCAG (Web Content Accessibility Guidelines), and you should know its shape. WCAG is organized around four principles, remembered as POUR:

Perceivable - users must be able to perceive the information (text alternatives for images, captions for audio, sufficient contrast, content not relying on color alone).
Operable - users must be able to operate the interface (keyboard accessible, enough time, no seizure-inducing content, navigable).
Understandable - the content and operation must be understandable (readable, predictable, helpful error handling).
Robust - content must be robust enough to work with assistive technologies (valid, semantic markup that screen readers can interpret).

WCAG also defines conformance levels: A (minimum), AA (the standard most organizations and laws target - the practical bar), and AAA (the strictest, rarely required wholesale). WCAG 2.1 AA (and increasingly 2.2) is the common compliance target, so "we aim for WCAG AA" is the standard answer for the bar to hit. Knowing POUR and that AA is the typical target is baseline accessibility literacy.

WCAG at a glance: the four POUR principles and the three conformance levels, with AA as the practical compliance bar most organizations target.

Why it shows up in senior interviews

Now the lesson's titular point. Accessibility appears in senior frontend interviews specifically because it's a strong signal of seniority and craftsmanship. Junior engineers build the happy path - works with a mouse, on their screen. Senior engineers build for the full range of users and contexts, and accessibility is the clearest demonstration of that breadth of consideration. So when an interviewer asks you to design a component, unprompted accessibility consideration - "I'd make sure it's keyboard operable, works with a screen reader, manages focus correctly, and has sufficient contrast" - marks you as someone who builds complete, professional, inclusive products. Conversely, never mentioning it marks the opposite.

Frontend system design rounds increasingly probe this directly: "how would you make this autocomplete accessible?", "what happens when a screen reader user hits this modal?", "is this keyboard operable?" These are senior questions, and the components this very course will build (modals, autocompletes, the LLD flagships) are exactly where accessibility gets tested. So accessibility isn't a side topic - it's woven into how senior frontend work is evaluated. Treating it as integral to every component you design, and raising it without being asked, is one of the highest-leverage things you can do to read as senior in these rounds.

Important: Accessibility (a11y) means building so people with disabilities - visual, motor, auditory, cognitive - can use your product, and the disability spectrum (permanent, temporary, situational) means a huge share of users benefit, via the curb-cut effect where designing for disability helps everyone. It matters on four grounds: it's right (inclusion), it's the law (ADA, EAA, referencing WCAG), it's a large audience, and it overlaps with quality. The standard is WCAG, organized by POUR (Perceivable, Operable, Understandable, Robust), with AA the common compliance target. It's a design concern from the start, not an afterthought - and it appears in senior interviews precisely because unprompted accessibility consideration signals the craftsmanship and user-breadth that distinguish senior engineers.

Interview: Raise accessibility unprompted when designing any component - it's a senior signal in itself: "As I design this, I'd build in accessibility from the start rather than retrofitting it - that means keyboard operability, screen-reader support through semantic HTML, correct focus management, and sufficient contrast, targeting WCAG AA. Accessibility isn't a niche concern: between permanent, temporary, and situational disabilities, a large share of users benefit, and via the curb-cut effect it improves the experience for everyone. It's also legally required and overlaps with code quality." Mentioning accessibility before being asked, framing it as design-time not afterthought, and naming WCAG AA and POUR demonstrates exactly the breadth of consideration senior rounds are testing for.

The assistive technologies you're building for

It helps to know concretely what people use to access the web, because accessible code is ultimately about working well with these tools:

Screen readers narrate the page aloud for blind and low-vision users, who navigate by keyboard and gestures (covered in depth two lessons from now). The page must be meaningful as audio.
Screen magnifiers enlarge portions of the screen for low-vision users - which means layouts must reflow sensibly and not break when zoomed, and important information must not depend on seeing the whole screen at once.
Keyboard-only navigation serves users who can't use a mouse - the foundation covered in the very next lesson.
Switch devices let users with severe motor disabilities operate the interface with one or a few physical switches (a button, a sip-and-puff device), typically emulating keyboard input - which is why keyboard accessibility also serves switch users.
Voice control lets users operate the interface by speaking commands, often activating elements by their visible labels or accessible names - which is why properly named, semantic controls matter for voice users too.
Browser and OS settings - high-contrast modes, increased text size, reduced motion, forced colors - that users configure for their needs, which your interface must respect rather than override.

The throughline is that all of these depend on the same underlying foundations: semantic markup, keyboard operability, sufficient contrast, respect for user preferences. So you don't build separately "for screen readers" and "for switch devices" - you build correctly, and the correct foundations serve all the assistive technologies at once. This is why the cluster's techniques (keyboard, semantic HTML/ARIA, focus, contrast) aren't a checklist of separate features but a coherent foundation that, done right, serves the whole range of how people access the web. Understanding that the techniques converge - that semantic HTML serves screen readers and voice control, that keyboard access serves motor disabilities and switch devices and screen readers - is what lets you build accessibly without treating each assistive technology as a separate project.

Why "from the start" matters so much

The cluster's framing - accessibility as a design concern, not an afterthought - deserves a concrete justification, because it's not just a slogan. Retrofitting accessibility onto an inaccessible product is dramatically more expensive than building it in, for the same reason late-stage changes are always costly: the inaccessibility is woven through the markup, the component structure, the interaction patterns, and the visual design, so fixing it means re-architecting rather than adding. A clickable-<div> design that's pervasive across an app is a large refactor to make accessible; choosing <button> from the start costs nothing. A color palette with poor contrast baked into the brand is painful to change after launch; checking contrast during design is trivial. A custom widget built without keyboard or screen-reader support needs substantial rework; building it accessibly the first time is incremental effort.

This is the same "shift left" logic as security and performance: the cost of addressing a quality concern rises the later you address it, so the economical move is to address it early and continuously. Concretely, that means accessibility belongs in design (contrast, focus order, interaction patterns considered as the design is made), in component development (each component built keyboard-operable, semantic, and focus-managed as it's written), and in review (accessibility checked alongside functionality), rather than as a pre-launch audit that discovers a mountain of expensive problems. The teams that do accessibility well don't have a heroic remediation phase - they have a habit woven through their normal process, which is both cheaper and more effective. Internalizing that accessibility is cheaper and better when built in - not a cost center bolted on at the end - is what turns the "design concern, not afterthought" framing from a platitude into a practiced discipline.

What you should carry out of this lesson

Accessibility means building so people with disabilities - visual, motor, auditory, cognitive - can use your product, and the disability spectrum (permanent, temporary, situational) plus the curb-cut effect means designing for disability benefits a huge share of users and improves the product for everyone. It matters because it's right (inclusion), legally required (ADA, EAA, via WCAG), a large audience, and overlapping with engineering quality. The standard is WCAG, organized by POUR (Perceivable, Operable, Understandable, Robust), with AA the common compliance target. The governing disposition is that accessibility is a design concern built in from the start, not an afterthought to remediate - and it shows up in senior interviews because unprompted accessibility consideration signals the craftsmanship and full-user-range thinking that mark a senior engineer.

The rest of the cluster makes accessibility concrete, technique by technique. We begin with the most fundamental requirement - the one that, if missing, makes an interface unusable for a large group regardless of anything else: everything must work with a keyboard alone. Keyboard accessibility is the foundation the other techniques build on, and it's next.

Back to Frontend System Design