Lesson 30 of 30

Auditing a Real Component

Q: I'm going to show you a button component and ask what you'd change about it. Before I do — what's your actual process for auditing a component like that?

A strong answer covers: Run a repeatable checklist rather than a single subjective look: contrast (rendered color, not the hex), spacing-scale compliance, type-scale compliance, and focus visibility at minimum; Check the component against its page context too — a component can pass every internal check and still be wrong for its hierarchy relative to neighboring elements; Treat the audit as something to re-run after changes, not a one-time gate — a later change (like added opacity) can silently reintroduce a failure.

Every principle in this track is easy to state in isolation and easy to forget under deadline. This lesson is the checklist that turns eight separate ideas into one repeatable pass over one real component.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A button passes a contrast check (4.5:1+) and uses correct spacing-scale padding. Is the audit complete?

No — contrast and spacing are two of several independent checks; passing them says nothing about type, focus, or hierarchyYes — contrast and spacing are the only two checks that matter for a button specificallyYes, because spacing-scale compliance automatically implies correct type scale usage too

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Auditing a Real Component

What interviewers actually ask about this, and what a strong answer has to cover.

I'm going to show you a button component and ask what you'd change about it. Before I do — what's your actual process for auditing a component like that?

A strong answer covers

Run a repeatable checklist rather than a single subjective look: contrast (rendered color, not the hex), spacing-scale compliance, type-scale compliance, and focus visibility at minimum
Check the component against its page context too — a component can pass every internal check and still be wrong for its hierarchy relative to neighboring elements
Treat the audit as something to re-run after changes, not a one-time gate — a later change (like added opacity) can silently reintroduce a failure

Likely follow-ups

If a button passes contrast, spacing, and type checks individually, is the audit necessarily complete? What else would you check?
How would semantic HTML (a real <button> vs. a styled <div>) factor into this same audit?

Practice these with the AI interviewer →

The plain-language idea

Interviews rarely ask "define contrast ratio" in isolation — they hand you a component (a button, a card, a form) and ask "what's wrong with this, or how would you build it well." That's a synthesis question, and the honest way to answer it is the same way you'd actually do the work: run one component through a repeatable checklist, not through eight separate half-remembered facts.

This lesson is that checklist, applied to one plain "Continue" button — the same audit this platform's own components were actually put through this session, not a hypothetical.

See it in a real thing: one button, four checks

Auditing one button against everything aboveStep 1 of 4

Contrast: is the label's rendered color — not its hex — at least 4.5:1 against the button fill?

Contrast — is the rendered color (not the hex in the file) at least 4.5:1 against the fill? This is the check that caught a real bug earlier in this track: opacity on a label blended it toward its own background and silently dropped a 4.92:1 pass to a 3.44:1 failure.
Spacing — does the internal padding come from the spacing scale (a multiple of the base unit), not an arbitrary value someone typed to make it "look right" in one browser window?
Type — is the label's size and weight a real step on the type scale, matched to its role (a primary action reads differently from a secondary link, deliberately)?
Focus — does the button have a visible, on-brand focus ring for keyboard users, distinct from (and not dependent on) its mouse hover state?

A full audit extends further than these four — responsiveness (does it reflow instead of overflowing at 300px?), semantics (is it a real <button>, satisfying WCAG's Robust principle for free?), and motion (does its state change communicate something, and does it respect reduced motion?) — but contrast, spacing, type, and focus are the four that catch the most real bugs the fastest, which is why they're worth running first.

What people usually miss

Watch out

The checklist order matters less than running all of it. It's tempting to stop at the first obvious issue (a color that looks off) and declare the audit done — a component can pass contrast and still fail focus visibility, or pass focus and still use an arbitrary padding value nobody could explain.
"It looks fine to me" is not evidence, for exactly the reason this whole track keeps returning to. Every lesson in this track replaced a subjective judgment with a specific, checkable rule — a real audit uses those rules, not a fresh look.
A component can be internally consistent and still wrong for its context. A button that correctly uses the type scale, spacing scale, and passes contrast can still be the wrong size for its role if a "primary" and "secondary" action read as equally weighted — hierarchy (Gestalt, from earlier in this track) still has to be checked against the page, not just the component in isolation.
An audit is not a one-time gate. A component that passed every check at launch can regress silently — a later PR that adds opacity for a "subtle" effect, or a token retint that wasn't re-verified against contrast, is exactly how this platform's own real bugs happened. The checklist is something to re-run, not just something to pass once.

Why this matters in interviews

A take-home or live-coding round that says "here's a button component, tell me what you'd change" is testing exactly this synthesis — not whether you remember one fact in isolation, but whether you can run a real component through a repeatable set of checks and name specific, falsifiable problems instead of vague impressions. That's the entire arc of this track: from "looks readable to me" in the first lesson to a checklist you could run on any component by the last one.