CSS and Accessible UI from the Inside Out

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: .01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: .01ms !important;
  }
}

:root {
  --color-text: #e5e7eb;
  --color-surface: #111827;
  --color-accent: #60a5fa;
  --space-2: .5rem;
  --space-4: 1rem;
  --radius: .75rem;
}

to resemble a button does not give it keyboard activation, focus behaviour or a useful role. Start with the correct element, then style it.

13. “Why does it matter to understand the cascade is a decision process?”

When declarations compete, the browser considers origin and importance, cascade layer, specificity, scoping proximity where applicable, then source order. Do not fight this with ever-longer selectors.

@layer reset, base, components, utilities;

@layer base {
  button { font: inherit; }
}

@layer components {
  .button { background: var(--action-bg); }
}

@layer utilities {
  .danger { background: var(--danger-bg); }
}

Layers make priority an explicit architectural decision. Keep component selectors low-specificity with :where() when useful:

:where(.card) h2 { margin-block: 0; }

Inline styles, !important and deeply nested selectors are difficult to override. Reserve importance for controlled cases such as accessibility utilities.

14. “How should I think about inheritance and custom properties?”

Some properties, including color and font-family, normally inherit; margins and borders do not. Custom properties inherit by default and are evaluated where used.

.theme-dark {
  --surface: #111827;
  --text: #f9fafb;
}

.card {
  color: var(--text, #111827);
  background: var(--surface, white);
}

This is more than variable substitution. A component can accept a small styling contract without knowing which theme surrounds it.

15. “Can you explain the box model without mystery?”

Every ordinary element has content, padding, border and margin. With content-box, declared width describes content only. With border-box, padding and border fit inside it.

*, *::before, *::after { box-sizing: border-box; }

.panel {
  inline-size: min(100%, 42rem);
  padding: 1rem;
  border: 1px solid currentColor;
}

Prefer logical properties such as inline-size, margin-inline and padding-block; they adapt more naturally to right-to-left and vertical writing modes.

16. “What should I understand about normal flow first?”

Normal document flow is responsive by default. Block content stacks; inline content wraps. Removing everything with absolute positioning creates a fragile poster instead of an adaptable document.

Use layout tools for their strengths:

• Flexbox arranges items primarily in one dimension.
• Grid coordinates rows and columns in two dimensions.
• Normal flow handles most reading order.
• Absolute/fixed positioning is for genuine overlays or anchored decoration.

.toolbar {
  display: flex;
  flex-wrap: wrap;
  gap: .75rem;
  align-items: center;
}

.lesson-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(16rem, 100%), 1fr));
  gap: 1rem;
}

The DOM order should remain sensible because keyboard and screen-reader navigation usually follow it even if CSS visually rearranges items.

17. “Can we unpack flexbox: sharing space?”

Think of people sitting on a bench. flex-basis is each person's requested space, flex-grow distributes spare space and flex-shrink decides how items compress.

.search { flex: 1 1 18rem; min-inline-size: 10rem; }
.actions { flex: 0 0 auto; }

A common surprise is a flex child refusing to shrink because its automatic minimum size is based on content. min-inline-size: 0 on the child can allow truncation or wrapping.

18. “Why does it matter to understand grid: naming the floor plan?”

.dashboard {
  display: grid;
  grid-template:
    "header header" auto
    "nav main" 1fr
    / minmax(12rem, 18rem) 1fr;
  min-block-size: 100dvh;
}

header { grid-area: header; }
nav { grid-area: nav; }
main { grid-area: main; min-inline-size: 0; }

Grid is excellent when relationships across both axes matter. On narrow screens, redefine the template rather than visually squeezing a desktop floor plan.

19. “How should I think about positioning and stacking contexts?”

z-index: 999999 cannot escape every parent. Certain properties—such as transforms, opacity below 1 and positioned elements with z-index—create stacking contexts. Children are layered inside that local context.

Use a small documented layer scale:

:root {
  --layer-base: 0;
  --layer-sticky: 10;
  --layer-overlay: 20;
  --layer-modal: 30;
}

When a tooltip appears behind something, inspect ancestor stacking contexts instead of merely increasing the number.

20. “Can you explain responsive and container-aware design?”

Design around content stress, not fashionable device names. Start with a narrow layout, then add space when the content needs it.

.course-shell { container-type: inline-size; }

@container (min-width: 42rem) {
  .course-card {
    display: grid;
    grid-template-columns: 12rem 1fr;
  }
}

Viewport media queries describe the page; container queries let a component respond to its available home. Test long names, zoom, translated text and missing images—the awkward cases reveal real responsiveness.

21. “What should I understand about typography is interface design?”

Readable text needs an appropriate line length, line height and scalable size.

body {
  font-size: clamp(1rem, .95rem + .25vw, 1.125rem);
  line-height: 1.6;
}

.prose { max-inline-size: 70ch; }

Avoid fixed-height text containers. A user may zoom, choose a larger default font or load a language whose words occupy more space.

22. “Can we unpack semantic HTML and the accessibility tree?”

The browser derives an accessibility tree from the DOM, semantics, styles and ARIA. Assistive technologies use this tree to find headings, landmarks, controls, names and states.

<header>...</header>
<nav aria-label="Primary">...</nav>
<main id="main-content">
  <h1>JavaScript course</h1>
  <section aria-labelledby="progress-heading">
    <h2 id="progress-heading">Your progress</h2>
  </section>
</main>

Use one descriptive page heading and a logical hierarchy. Do not choose heading levels because of font size; style the correct heading.

23. “Why does it matter to understand accessible names?”

A control needs a name that communicates purpose. Visible text often supplies it best.

<button type="button">Save lesson</button>

<button type="button" aria-label="Close course details">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Do not duplicate or contradict visible labels with aria-label. Speech-input users may say the visible words, so those words should be part of the accessible name.

24. “How should I think about keyboard interaction and focus?”

Everything clickable should work without a pointer. Tab moves between interactive elements; Enter activates links and buttons; Space activates buttons. Composite widgets such as tabs have richer patterns documented by ARIA Authoring Practices.

:focus-visible {
  outline: 3px solid #fbbf24;
  outline-offset: 3px;
}

Never remove focus outlines without a clear replacement. Avoid positive tabindex values, which create a second, brittle navigation order. Use tabindex="-1" when code must focus a normally non-tabbable heading after navigation or an error.

25. “Can you explain forms that teach instead of punish?”

Give instructions before errors happen, preserve entered values and place errors next to fields.

<label for="email">Email address</label>
<input id="email" name="email" type="email"
       autocomplete="email" aria-describedby="email-error"
       aria-invalid="true">
<p id="email-error">Enter an address such as name@example.com.</p>

On failed submission, provide a summary linked to invalid fields and move focus to the summary when appropriate. Do not rely only on red borders. Server validation is still required; client validation is user assistance, not a trust boundary.

26. “What should I understand about a modal dialog workshop?”

The native dialog gives useful platform behaviour:

<button id="open">Delete course</button>
<dialog id="confirm" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Delete this course?</h2>
  <p>This cannot be undone.</p>
  <form method="dialog">
    <button value="cancel">Cancel</button>
    <button value="confirm">Delete course</button>
  </form>
</dialog>

const dialog = document.querySelector("#confirm");
document.querySelector("#open").addEventListener("click", () => {
  dialog.showModal();
});

Test initial focus, Escape, focus containment, the accessible name, focus restoration and the destructive action. Modal means background content cannot be operated—not merely that a box is centred.

27. “Can we unpack motion, contrast and forced colours?”

Animation can explain change, but may also cause nausea or distraction. Respect prefers-reduced-motion and ensure the interface remains understandable when movement is removed.

Use sufficient contrast and never use colour as the only signal. In forced-colour modes, custom shadows and backgrounds may disappear. Test with system colours and visible borders.

.error {
  color: var(--error-text);
  border-inline-start: .3rem solid currentColor;
}

@media (forced-colors: active) {
  .button { border: 2px solid ButtonText; }
}

28. “Why does it matter to understand design-system component contract?”

A component API should include semantics and behaviour:

type ButtonProps = React.ButtonHTMLAttributes<HTMLButtonElement> & {
  variant?: "primary" | "quiet" | "danger";
  pending?: boolean;
};

function Button({ pending, disabled, children, ...props }: ButtonProps) {
  return (
    <button {...props} disabled={disabled || pending} aria-busy={pending || undefined}>
      {pending ? "Working…" : children}
    </button>
  );
}

Preserve native attributes rather than inventing substitutes. Document names, roles, keyboard behaviour, disabled/pending states, high contrast and localization alongside visual variants.

29. “How should I think about accessibility testing ladder?”

Use several layers:

1. Lint obvious semantic mistakes.
2. Query components by role and accessible name.
3. Run automated accessibility rules.
4. Navigate major journeys with keyboard only.
5. Inspect zoom, reflow, contrast and reduced motion.
6. Test representative journeys with screen readers and real users where possible.

Automation catches only some barriers. It cannot decide whether link wording is understandable or a workflow is cognitively exhausting.

30. “Can you explain seven-day revision plan?”

• Day 1: rebuild a page using semantic landmarks and headings.
• Day 2: practise cascade, layers, inheritance and the box model.
• Day 3: recreate layouts with normal flow, Flexbox and Grid.
• Day 4: make one component work in narrow, wide, zoomed and RTL contexts.
• Day 5: operate every control by keyboard and repair focus.
• Day 6: improve a form's labels, help, validation and errors.
• Day 7: test a dialog and full journey with automated and manual checks.

Final self-test: can you explain why semantic HTML improves keyboard behaviour, accessibility APIs, resilience and maintainability at the same time? That connection is the centre of accessible frontend engineering.

31. “What should I understand about let us slow the whole subject down?”

CSS becomes frustrating when we treat every visible result as an isolated trick. Accessibility becomes frightening when we treat it as a list of special accommodations added after design. Both become calmer when we begin with relationships.

HTML describes meaning and structure. CSS resolves presentation through rules, context and available space. The browser exposes semantics and states to accessibility APIs. Users then interact through sight, hearing, touch, voice, keyboard, pointer, switches or combinations we did not predict.

Our goal is not to make one screenshot perfect. It is to create an interface that remains understandable when text grows, fonts change, the viewport narrows, colors are overridden, animation is reduced, a pointer is unavailable or content is translated.

32. “Can we unpack cSS is a constraint system?”

When you write:

.article {
  inline-size: min(100% - 2rem, 70ch);
  margin-inline: auto;
}

you are not assigning final pixels. You are describing constraints: leave space, never exceed the available width, limit comfortable line length and center the resulting box. The browser resolves those constraints against content, writing mode, containing block and viewport.

This mindset is more resilient than copying coordinates from a design tool. Ask, “What relationship should hold?” instead of “Which pixel value makes this screenshot match?”

33. “Why does it matter to understand where CSS declarations come from?”

Styles can come from the browser's user-agent sheet, the author, user preferences and animations/transitions. Within author CSS, styles may be inline, embedded, linked, imported or generated through adopted sheets.

<link rel="stylesheet" href="/styles/app.css">
<style>.temporary-banner { display: block; }</style>
<div style="color: rebeccapurple">...</div>

Prefer maintainable stylesheets and component contracts to scattered inline declarations. Inline style is not inherently evil, but it occupies a high-priority position and cannot express every state or media query.

The browser must decide one value for each property on each element. That decision process is the cascade.

34. “How should I think about cascade order in working language?”

For competing declarations, think through:

1. Does the selector match and is its condition active?
2. Which origin and importance level wins?
3. Which cascade layer wins?
4. Which selector has greater specificity inside that winning context?
5. If scoped rules apply, which is closer?
6. If still tied, which appears later?

Specificity does not compare declarations that already lost at a higher cascade dimension. That is why a low-specificity unlayered author rule can beat a high-specificity rule inside a normal layer.

@layer reset, foundation, components, utilities;

@layer foundation {
  a { color: var(--link-color); }
}

@layer components {
  .button { color: var(--button-text); }
}

@layer utilities {
  .visually-hidden { /* intentional utility */ }
}

Declare order once. Layers are architectural priority groups, not folders.

35. “Can you explain specificity without arithmetic anxiety?”

A practical hierarchy is inline style, IDs, classes/attributes/pseudo-classes, then type selectors/pseudo-elements. Think in columns rather than one decimal number.

#app .card h2 { color: navy; }       /* high and coupled */
.course-card__title { color: navy; } /* focused component hook */

:is(), :not() and :has() take specificity from their selector arguments. :where() always contributes zero specificity.

:where(.prose) :where(h2, h3, p) {
  margin-block-start: 0;
}

Keep defaults easy to override. Do not add an ID or !important merely to win today; you charge future maintainers interest.

!important reverses priorities within relevant cascade origins/layers and can be appropriate for carefully controlled overrides such as a critical accessibility utility. Document why.

36. “What should I understand about inheritance, initial values and reset keywords?”

Inheritance happens from parent to child for properties designed to inherit, commonly color and typography. It is separate from selector matching.

.course-card { color: #334155; }
.course-card button { color: inherit; }

Keywords:

• inherit: use the parent's computed value;
• initial: use the property's specification-defined initial value;
• unset: inherit if normally inherited, otherwise initial;
• revert: roll back to a lower origin/cascade result;
• revert-layer: roll back within the current layer.

Test them in DevTools rather than treating all as “remove style.”

37. “Can we unpack custom properties are late-bound values?”

Custom properties participate in cascade and normally inherit.

:root {
  --space: 1rem;
  --surface: #fff;
  --text: #172033;
}

[data-theme="dark"] {
  --surface: #111827;
  --text: #f9fafb;
}

.card {
  padding: var(--space);
  background: var(--surface);
  color: var(--text);
}

The variable is resolved where used, so descendants can provide local values. Use semantic names such as --color-text-danger rather than raw names such as --red-600 at component boundaries.

Fallback applies when the custom property is missing/invalid at substitution:

color: var(--course-heading-color, var(--color-text));

Custom properties can hold invalid-for-this-property token streams until use. Inspect the computed declaration when a fallback surprises you.

38. “Why does it matter to understand the box model with calculations?”

An ordinary box has content, padding, border and margin.

.panel {
  box-sizing: content-box;
  width: 300px;
  padding: 20px;
  border: 2px solid;
}

Its border-box width is 344 pixels: 300 content + 40 padding + 4 border. Margins sit outside.

With border-box:

*, *::before, *::after { box-sizing: border-box; }

.panel {
  width: 300px;
  padding: 20px;
  border: 2px solid;
}

The declared 300 includes padding and border, leaving 256 for content. border-box often makes component sizing easier.

Vertical margins between normal block boxes can collapse in specific situations. Padding, border, a new formatting context or layout mode changes that behavior. When spacing seems to “escape,” inspect boxes rather than adding random negative margins.

39. “How should I think about display generates boxes?”

display influences outer participation and inner layout.

.inline-link { display: inline; }
.block-section { display: block; }
.toolbar { display: flex; }
.dashboard { display: grid; }
.gone { display: none; }

Inline content participates in line boxes and wraps. Block boxes generally fill available inline space and stack. Flex and grid establish specialized formatting contexts for children.

display: none removes the element's boxes and generally removes it from the accessibility tree. visibility: hidden usually preserves layout space but hides content and interaction. opacity: 0 makes pixels transparent while the element may still occupy space and receive focus/pointer input. Choose based on intended semantics, not appearance alone.

40. “Can you explain normal flow is your resilient default?”

Normal flow naturally responds to text size and viewport width. A reading page can need surprisingly little layout code:

main {
  inline-size: min(100% - 2rem, 70rem);
  margin-inline: auto;
  padding-block: 2rem;
}

.prose {
  max-inline-size: 68ch;
}

Absolute positioning removes an element from ordinary flow. If you use it for every card, text expansion causes overlap because neighboring boxes no longer respond.

Use positioning for overlays, badges and anchored decorations where the relationship truly demands it.

41. “What should I understand about formatting contexts and overflow?”

A block formatting context changes how floats and margins interact and can contain floats. display: flow-root creates one without unrelated side effects:

.article-section { display: flow-root; }
.article-section img { float: inline-start; margin-inline-end: 1rem; }

Overflow behavior is part of layout:

.code-sample {
  overflow-x: auto;
  max-inline-size: 100%;
}

Avoid overflow: hidden as a casual layout fix; it clips focus rings, shadows, sticky descendants and content. Use it when clipping is the requirement.

42. “Can we unpack containing blocks?”

Percentages and positioned offsets resolve against a containing block. An absolutely positioned element commonly uses the nearest positioned ancestor:

.avatar {
  position: relative;
  inline-size: 4rem;
  aspect-ratio: 1;
}

.avatar__status {
  position: absolute;
  inset-inline-end: 0;
  inset-block-end: 0;
}

Transforms, containment and other properties can establish containing blocks, including surprising behavior for descendants you expected to be viewport-fixed. Inspect ancestors in DevTools when coordinates appear wrong.

Logical inset properties (inset-inline-start) adapt to writing direction better than physical left when the relationship is semantic.

43. “Why does it matter to understand positioning and sticky behavior?”

• static: normal default positioning.
• relative: remains in flow; visual offsets and positioning context can apply.
• absolute: removed from normal flow and positioned against a containing block.
• fixed: commonly positioned relative to the viewport, subject to containing-block rules.
• sticky: behaves in flow until reaching an inset within a scrolling container.

.section-nav {
  position: sticky;
  inset-block-start: 1rem;
  align-self: start;
}

Sticky fails when no inset is provided, when there is insufficient scroll room or when an ancestor's overflow establishes a different scroll container. Inspect the scroll container before increasing z-index.

44. “How should I think about stacking contexts?”

A stacking context is a local layering world. It can be created by positioned elements with z-index, transforms, opacity below one, isolation and other properties.

.app-shell { isolation: isolate; }
.sticky-header { position: sticky; z-index: 10; }
.popover-layer { position: fixed; z-index: 30; }

A child's z-index: 99999 cannot escape a lower ancestor stacking context. Use a documented layer scale and platform top-layer features for modal dialogs/popovers when suitable. Do not turn layer numbers into an arms race.

45. “Can you explain flexbox from first principles?”

Flexbox distributes space along a main axis and aligns along a cross axis.

.toolbar {
  display: flex;
  flex-wrap: wrap;
  gap: .75rem;
  align-items: center;
}

.toolbar__search { flex: 1 1 18rem; }
.toolbar__actions { flex: 0 0 auto; }

flex: grow shrink basis. Basis supplies the starting size, grow distributes positive free space and shrink handles negative free space according to factors and base sizes.

The default automatic minimum can prevent a child from shrinking:

.card__content { min-inline-size: 0; }

This permits content area shrinkage; then decide whether text wraps or truncates. Truncation must not hide essential content without another accessible path.

Use gap for relationships between flex/grid children. Auto margins can absorb free space intentionally:

.toolbar__account { margin-inline-start: auto; }

46. “What should I understand about grid from first principles?”

Grid defines tracks in two dimensions.

.course-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(16rem, 100%), 1fr));
  gap: 1rem;
}

auto-fit collapses empty tracks; minmax sets bounds; fr distributes leftover space after fixed and intrinsic contributions.

For a page shell:

.layout {
  display: grid;
  grid-template:
    "header header" auto
    "sidebar main" 1fr
    / minmax(12rem, 18rem) minmax(0, 1fr);
  min-block-size: 100dvh;
}

Named areas communicate intent. The minmax(0, 1fr) main track allows content to shrink rather than overflow because of an automatic intrinsic minimum.

Visual reordering does not necessarily change DOM, focus or reading order. Keep source order meaningful and use layout to enhance, not contradict it.

47. “Can we unpack subgrid and alignment?”

Nested cards often need headings and footers aligned across rows. subgrid lets a child grid participate in ancestor tracks where supported:

.cards { display: grid; grid-template-columns: repeat(3, 1fr); }

.card {
  display: grid;
  grid-row: span 3;
  grid-template-rows: subgrid;
}

Alignment properties separate container distribution (justify-content) from item alignment (justify-items) and individual overrides (justify-self). In flexbox, justify-content follows the main axis; align-items follows the cross axis. Writing mode and flex direction affect what those axes mean.

48. “Why does it matter to understand intrinsic and responsive sizing?”

Useful sizing functions:

.heading { font-size: clamp(2rem, 1.2rem + 4vw, 4.5rem); }
.sidebar { inline-size: min(22rem, 100%); }
.logo { inline-size: max(8rem, 15vw); }
.grid { grid-template-columns: repeat(auto-fill, minmax(15rem, 1fr)); }

min-content approximates the smallest intrinsic width without avoidable overflow; max-content the preferred unwrapped width. fit-content constrains an intrinsic size.

Avoid fixed heights for text containers. Users zoom, choose larger fonts and translate content. Prefer min-block-size where a visual minimum is necessary.

49. “How should I think about media queries from content pressure?”

Start with a narrow layout, then add a breakpoint when content has enough room:

.course-page { display: block; }

@media (min-width: 52rem) {
  .course-page {
    display: grid;
    grid-template-columns: 16rem minmax(0, 1fr);
    gap: 2rem;
  }
}

Do not name breakpoints “iPad” or “desktop” as if devices were fixed. Name tokens by layout purpose if tokens are useful.

Media features include user preferences:

@media (prefers-reduced-motion: reduce) { /* reduce nonessential motion */ }
@media (prefers-contrast: more) { /* strengthen distinctions where supported */ }
@media (forced-colors: active) { /* cooperate with system palette */ }

50. “Can you explain container queries?”

A component often needs to respond to its container rather than the viewport.

.course-region {
  container: course / inline-size;
}

.course-card { display: block; }

@container course (min-width: 36rem) {
  .course-card {
    display: grid;
    grid-template-columns: 10rem 1fr;
    gap: 1rem;
  }
}

Now the same card adapts in a wide main region and a narrow sidebar. Container query units such as cqi can scale relative to container dimensions, but keep text within readable minimum and maximum sizes.

51. “What should I understand about logical properties and international layout?”

Physical left/right assumptions break in right-to-left or vertical writing modes.

.callout {
  border-inline-start: .3rem solid var(--accent);
  padding-inline: 1rem;
  padding-block: .75rem;
  margin-block: 1.5rem;
}

inline follows the text line; block follows block progression. start and end adapt to direction. Test actual RTL content; flipping icons and ordering is a semantic question, not a blanket transform.

Use the HTML dir attribute based on content direction. CSS direction is not a general-purpose layout trick.

52. “Can we unpack typography and readability?”

Typography carries meaning and determines layout.

body {
  font-family: system-ui, sans-serif;
  font-size: clamp(1rem, .96rem + .2vw, 1.125rem);
  line-height: 1.6;
}

.prose { max-inline-size: 68ch; }

h1, h2, h3 {
  line-height: 1.15;
  text-wrap: balance;
}

Do not disable user zoom. Avoid text baked into images. Reserve enough fallback space for web fonts and choose fallback metrics carefully to reduce layout shift. Font loading is a performance and resilience decision; content should remain usable if a web font fails.

All-caps text, very light weights and long centered paragraphs reduce readability. Visual fashion is not worth comprehension.

53. “Why does it matter to understand images, aspect ratio and object fit?”

Reserve image geometry to reduce layout shift:

<img src="course.webp" width="800" height="450" alt="A learner writing notes beside a laptop">

.thumbnail {
  inline-size: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

object-fit: cover crops; ensure important content remains visible or use art direction with . Informative images need useful alternative text; decorative images use alt="". Do not repeat nearby caption text mechanically.

54. “How should I think about accessibility is a quality of use?”

Accessibility means people with different abilities and contexts can perceive, understand, navigate and operate the interface. Disability may be permanent, temporary or situational: blindness, a broken arm, glare on a screen, hearing loss, cognitive fatigue or holding a baby can change interaction needs.

WCAG groups guidance under four principles:

• Perceivable: information can be sensed in available ways.
• Operable: controls and navigation can be used.
• Understandable: language and behavior are clear and predictable.
• Robust: content works with current and future user agents and assistive technologies.

Conformance is useful, but the human goal is usable journeys. A page can pass automated rules and still be exhausting or confusing.

55. “Can you explain semantic HTML creates free capability?”

Compare:

<div class="button" onclick="save()">Save</div>

with:

<button type="button" onclick="save()">Save</button>

The native button provides focusability, keyboard activation, an accessibility role, form behavior, disabled semantics and platform familiarity. The div provides none automatically.

Choose elements by meaning:

• links navigate to resources;
• buttons perform actions;
• headings name sections;
• lists group related items;
• tables express tabular relationships;
• labels name form controls;
• landmarks identify page regions.

Semantic HTML is not only for screen readers. It improves keyboard use, browser features, search, automation, resilience and maintainability.

56. “What should I understand about document language, title and landmarks?”

<!doctype html>
<html lang="en-GB">
<head>
  <title>JavaScript course – StudyDesk</title>
</head>
<body>
  <header>...</header>
  <nav aria-label="Primary">...</nav>
  <main id="main-content">...</main>
  <footer>...</footer>
</body>
</html>

The language helps pronunciation and language-aware processing. A unique descriptive title identifies the page or state. Landmarks let users jump among regions.

Avoid adding a landmark role to every wrapper. Multiple navigation regions need distinguishing names such as “Primary,” “Course” and “Footer.” Do not include the word “navigation” in aria-label="Primary navigation" if the role already announces it unless that repetition helps your tested experience.

57. “Can we unpack headings are an outline, not font sizes?”

<main>
  <h1>JavaScript foundations</h1>
  <section>
    <h2>Course progress</h2>
    <h3>Completed lessons</h3>
  </section>
  <section>
    <h2>Next lesson</h2>
  </section>
</main>

Choose level from document hierarchy, then style it. Do not select

because its browser default is visually small. Avoid empty headings and heading-like bold paragraphs.

Reusable components need context. Accept a heading level or let the parent supply the heading element rather than hard-coding invalid hierarchy everywhere.

58. “Why does it matter to understand the accessibility tree?”

The browser derives an accessibility representation from DOM semantics, attributes, styles and ARIA. Assistive technologies query roles, names, descriptions, values, states and relationships.

For a button, the important data might be:

Role: button
Name: Save course
State: disabled = false

Inspect this in browser accessibility tools. The DOM tree, CSS boxes and accessibility tree overlap but are not identical.

display: none, hidden and visibility: hidden generally remove content from the accessibility tree. aria-hidden="true" hides content from accessibility APIs but does not hide or disable it visually. Never apply it to a focusable element or an ancestor containing focusable controls.

59. “How should I think about accessible names and descriptions?”

Visible text is the simplest name:

<button>Save course</button>

An icon-only button needs a programmatic name:

<button type="button" aria-label="Close course details">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Prefer a visible label when space permits. Speech-input users often say visible words; WCAG's Label in Name principle means the accessible name should contain the visible label.

Descriptions provide extra help:

<label for="password">Password</label>
<input id="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Do not put all instructions in a very long accessible name. Keep name concise and attach supporting description.

60. “Can you explain keyboard navigation fundamentals?”

Typical browser conventions:

• Tab/Shift+Tab move among focusable elements.
• Enter activates links and buttons.
• Space activates buttons and toggles controls.
• Arrow keys operate some native and composite widgets.
• Escape commonly closes dismissible popups/dialogs.

Do not add click behavior to noninteractive elements. If you truly build a custom widget, you own its complete keyboard, focus and state model.

Test from the address bar with no mouse:

1. Can every action be reached?
2. Is focus always visible?
3. Does order match the content?
4. Can every component be exited?
5. Does focus move intentionally after major changes?
6. Is hidden content skipped?

61. “What should I understand about tabindex without traps?”

• Native interactive elements join the tab order naturally.
• tabindex="0" adds an element in DOM order, usually for a custom composite's active item.
• tabindex="-1" allows programmatic focus but removes it from sequential tab order.
• Positive values create a separate fragile order; avoid them.

<main id="main" tabindex="-1">...</main>

After client-side navigation, focusing the main heading or container can orient keyboard and screen-reader users:

main.focus({ preventScroll: true });
main.scrollIntoView({ block: "start" });

Use focus movement sparingly and predictably. Do not steal focus during ordinary rerenders.

62. “Can we unpack focus styling and obscured focus?”

:focus-visible {
  outline: 3px solid var(--focus-ring);
  outline-offset: 3px;
}

:focus-visible lets browsers apply heuristics so keyboard focus receives a strong indicator without necessarily drawing it for every pointer click.

Never use outline: none without a visible replacement. Check focus against all component backgrounds and in forced-colour mode.

Sticky headers, cookie banners and overlays must not obscure the focused control. Provide scroll padding:

html { scroll-padding-block-start: 5rem; }
:target { scroll-margin-block-start: 5rem; }

WCAG 2.2 adds criteria related to focus not being obscured and target size. Test the actual journey, not only isolated components.

63. “Why does it matter to understand skip links?”

<a class="skip-link" href="#main-content">Skip to main content</a>

.skip-link {
  position: fixed;
  inset-block-start: .5rem;
  inset-inline-start: .5rem;
  transform: translateY(-200%);
}

.skip-link:focus {
  transform: translateY(0);
  z-index: 100;
}

A skip link lets keyboard users bypass repeated navigation. Its target should exist and receive useful focus/navigation behavior. Make the link visible when focused; do not hide it with display: none.

64. “How should I think about forms begin with labels?”

<div class="field">
  <label for="course-title">Course title</label>
  <input id="course-title" name="title" required
         autocomplete="off" aria-describedby="title-help">
  <p id="title-help">Use a clear title of up to 120 characters.</p>
</div>

Placeholder is not a label: it disappears, may have low contrast and often shows an example rather than the field's identity.

Use appropriate type, inputmode and autocomplete to help input:

<label for="email">Email address</label>
<input id="email" name="email" type="email"
       inputmode="email" autocomplete="email">

Do not disable paste in passwords or verification codes. It blocks password managers and assistive workflows.

65. “Can you explain groups, choices and instructions?”

<fieldset>
  <legend>Course visibility</legend>
  <label><input type="radio" name="visibility" value="private"> Private</label>
  <label><input type="radio" name="visibility" value="organisation"> Organisation</label>
  <label><input type="radio" name="visibility" value="public"> Public</label>
</fieldset>

fieldset and legend communicate group context. Use native checkbox/radio controls and style them carefully with accent-color where suitable.

Give format expectations before submission. Identify required fields in text and programmatically. Do not use an unexplained asterisk alone.

66. “What should I understand about validation and error recovery?”

On failure:

• preserve entered values;
• explain the problem in plain language;
• associate each error with its control;
• set aria-invalid="true" on invalid fields;
• provide an error summary linked to fields;
• focus the summary when submission fails, when appropriate;
• validate again on the server.

<div class="error-summary" role="alert" tabindex="-1">
  <h2>There are two problems</h2>
  <ul>
    <li><a href="#course-title">Enter a course title</a></li>
  </ul>
</div>

<input id="course-title" aria-invalid="true" aria-describedby="title-error">
<p id="title-error">Enter a title between 1 and 120 characters.</p>

Do not clear an error on every keystroke before the new value is validated. Avoid announcing validation continuously while a person is still typing.

67. “Can we unpack live regions with restraint?”

Dynamic status messages can be announced:

<p id="save-status" role="status" aria-live="polite"></p>

saveStatus.textContent = "Course saved.";

role="status" is appropriate for polite non-urgent updates. role="alert" is assertive and should be reserved for important time-sensitive errors.

Create the live-region container before updating it when possible. Replacing a whole region repeatedly or announcing loading percentages every instant overwhelms users. A message should communicate an actionable state change.

68. “Why does it matter to understand buttons, links and disabled states?”

A link navigates; a button acts.

<a href="/courses/42">View course</a>
<button type="button">Archive course</button>

A native disabled button is unavailable and normally skipped in tab order. Sometimes keeping a control discoverable with an explanation is better:

<button type="button" aria-disabled="true" aria-describedby="publish-help">
  Publish course
</button>
<p id="publish-help">Add at least one lesson before publishing.</p>

aria-disabled communicates state but does not prevent activation. JavaScript must block the action, and visual styling must not rely on color alone.

69. “How should I think about disclosure and accordion workshop?”

For a simple disclosure, a native button controls a region:

<h2>
  <button type="button" aria-expanded="false" aria-controls="panel-html">
    HTML foundations
  </button>
</h2>
<div id="panel-html" hidden>
  <p>Lesson content...</p>
</div>

button.addEventListener("click", () => {
  const expanded = button.getAttribute("aria-expanded") === "true";
  button.setAttribute("aria-expanded", String(!expanded));
  panel.hidden = expanded;
});

Enter and Space work because the trigger is a button. Do not move focus when expanding ordinary content. For an accordion, each header contains a button and heading level follows page hierarchy. Optional arrow-key behavior should follow the documented pattern consistently.

70. “Can you explain dialog workshop?”

<button id="delete-trigger">Delete course</button>

<dialog id="delete-dialog" aria-labelledby="delete-title">
  <h2 id="delete-title">Delete this course?</h2>
  <p>This action cannot be undone.</p>
  <form method="dialog">
    <button value="cancel">Cancel</button>
    <button value="confirm">Delete course</button>
  </form>
</dialog>

const trigger = document.querySelector("#delete-trigger");
const dialog = document.querySelector("#delete-dialog");

trigger.addEventListener("click", () => dialog.showModal());
dialog.addEventListener("close", () => trigger.focus());

Test:

• the dialog has an accessible name;
• initial focus is sensible (often the least destructive action for confirmation);
• Tab remains within a modal interaction;
• Escape closes when cancellation is allowed;
• background is inert;
• focus returns to the trigger or a logical successor;
• opening/closing does not lose unsaved work.

The native

helps but product behavior still requires testing. Avoid nesting complex modals.

71. “What should I understand about tabs are not navigation links in disguise?”

A tab interface represents layered panels within one context. It has tablist, tab, and tabpanel relationships and arrow-key navigation.

<div role="tablist" aria-label="Course details">
  <button role="tab" id="tab-outline" aria-selected="true"
          aria-controls="panel-outline">Outline</button>
  <button role="tab" id="tab-reviews" aria-selected="false"
          aria-controls="panel-reviews" tabindex="-1">Reviews</button>
</div>
<section role="tabpanel" id="panel-outline" aria-labelledby="tab-outline">...</section>
<section role="tabpanel" id="panel-reviews" aria-labelledby="tab-reviews" hidden>...</section>

Only the active tab is in the Tab sequence; arrow keys move among tabs. Decide automatic versus manual activation based on whether panel display is immediate. If clicking labels navigates to distinct URLs/pages, ordinary links may be more appropriate.

72. “Can we unpack menus are not ordinary site navigation?”

ARIA menu patterns imitate application menus with managed focus and arrow keys. A website header containing page links is usually a semantic