Semantic HTML and Accessibility Questions

Covers writing semantic HTML using appropriate elements such as header, nav, main, article, section, aside, footer, form, input, and button to create meaningful document structure and improve machine and assistive technology interpretation. Includes implementing Accessible Rich Internet Applications attributes where necessary, providing descriptive alt text for images, labeling form controls, and ensuring correct landmark and role usage. Emphasizes keyboard operability, focus management, logical tab order, and screen reader compatibility for dynamic and interactive components. Tests knowledge of the Web Content Accessibility Guidelines version 2.1 principles including perceivable, operable, understandable, and robust, and concrete requirements such as color contrast ratios, readable font sizes, and accessible error handling. Covers inclusive design practices, accessibility testing and validation strategies, developer and design collaboration to bake accessibility in from the start, and remediation approaches for common accessibility issues at both component and application levels.

HardTechnical

46 practiced

You must persuade executive stakeholders to allocate engineering and design resources to remediate high-severity accessibility debt across the product. Prepare a concise pitch: identify business and legal risks, quantify user impact and estimated costs, propose phased remediation with timelines and KPIs, and suggest governance to prevent regression.

EasyTechnical

39 practiced

You have the following images on a product page: a company logo in the header, a decorative SVG divider, a product photo showing multiple items, an infographic chart, and an icon-only button. For each image describe the appropriate alt text (or why it should be empty) and where a long description belongs for complex images like charts. Explain trade-offs between concise and verbose alt text.

MediumTechnical

38 practiced

You inherit a codebase where many interactive controls are implemented as <div role='button'> with onclick handlers, no keyboard handlers, and no focus styles. Describe the accessibility problems present and outline a prioritized remediation plan that includes quick wins and long-term fixes.

Sample Answer

**Accessibility problems (summary)**- Non-semantic elements: divs with role="button" confuse AT/assistive tech and lack native behaviors.- Keyboard inaccesibility: no keyboard handlers or tabindex means users can't focus or activate via Enter/Space.- No focus styles: keyboard users can't see focus target.- Missing ARIA/state: no aria-pressed/aria-expanded where toggle/state needed.- Potential screen reader inconsistencies and contrast/announce gaps.

**Prioritized remediation plan**

1) Quick wins (hours per control)- Replace div with native <button> where possible (best semantics, built-in keyboard/focus).

html

<button class="btn">Save</button>

- If replacement not feasible, add required attributes and handlers:

html

<div role="button" tabindex="0" aria-pressed="false"
     onclick="onClick()" onkeydown="if (event.key==='Enter' || event.key===' ') { event.preventDefault(); onClick(); }">
  Save
</div>

- Add visible focus style in CSS:

css

:focus { outline: 3px solid #005fcc; outline-offset: 2px; }

2) Medium-term (days)- Audit all interactive elements, create lint rule/ESLint plugin to flag role/button on non-button.- Add unit/axe accessibility tests and keyboard-only test cases.

3) Long-term (weeks)- Refactor complex controls into accessible components (toggle, dropdown) with correct ARIA patterns (WAI-ARIA Authoring Practices).- Train team, add PR checklist and CI gates to prevent regressions.

**Why this order**- Native elements fix most issues quickly and require less JS. Auditing and automated tests prevent recurrence; full refactor ensures robust, maintainable accessibility.

MediumTechnical

41 practiced

Design an accessible accordion component (single panel open at a time). The toggles should be buttons that manage aria-expanded and aria-controls, headings should be semantic, and keyboard interactions must allow Tab to move between toggles and Enter/Space to toggle. Provide markup examples and explain how you handle focus and state.

Sample Answer

**Approach (brief)** I build a semantic, keyboard-accessible accordion where only one panel is open. Each toggle is a button inside a heading; buttons manage aria-expanded and aria-controls. Tab moves focus between buttons; Enter/Space activates. State is kept in JS; when opening one panel I close others and move focus only when appropriate.

**Markup example**

html

<div class="accordion" id="faq">
  <h3>
    <button aria-expanded="false" aria-controls="panel-1" id="acc-1">What is X?</button>
  </h3>
  <div id="panel-1" role="region" aria-labelledby="acc-1" hidden>Answer 1</div>

  <h3>
    <button aria-expanded="false" aria-controls="panel-2" id="acc-2">How to Y?</button>
  </h3>
  <div id="panel-2" role="region" aria-labelledby="acc-2" hidden>Answer 2</div>
</div>

**Behavior (JS)**

javascript

// simple, framework-agnostic
const accordion = document.getElementById('faq');
accordion.addEventListener('click', (e) => {
  const btn = e.target.closest('button');
  if (!btn) return;
  const expanded = btn.getAttribute('aria-expanded') === 'true';
  // close all
  accordion.querySelectorAll('button').forEach(b => {
    b.setAttribute('aria-expanded', 'false');
    document.getElementById(b.getAttribute('aria-controls')).hidden = true;
  });
  // toggle target
  if (!expanded) {
    btn.setAttribute('aria-expanded', 'true');
    document.getElementById(btn.getAttribute('aria-controls')).hidden = false;
  }
});
accordion.addEventListener('keydown', (e) => {
  const btn = e.target.closest('button');
  if (!btn) return;
  if (e.key === 'Enter' || e.key === ' ') { e.preventDefault(); btn.click(); }
});

**Focus & State handling** - Focus: buttons are native focusable elements; Tab naturally moves between them. No roving tabindex needed. - State: aria-expanded reflects open state; panels use hidden attribute and role="region" with aria-labelledby for screen readers. Only one panel is open at a time; opening sets aria-expanded=true and removes hidden, closing sets aria-expanded=false and hidden=true. - Keyboard: Enter/Space toggles the focused button; Tab moves focus; you can optionally add Arrow Up/Down to move focus between buttons for enhanced UX.

This keeps markup semantic, supports ATs, and is simple to test.

EasyTechnical

34 practiced

List common ARIA landmark roles (navigation, banner, main, complementary, contentinfo) and their HTML5 element equivalents. Explain when adding explicit role attributes is redundant or can be harmful, and provide an example of correct landmark usage for a blog layout.

Sample Answer

**Common ARIA landmark roles and HTML5 equivalents**

- banner → <header> - navigation → <nav> - main → <main> - complementary → <aside> - contentinfo → <footer> - search → <form role="search"> or <search> (semantic intent) - region (aria-roledescription) → <section> with aria-label

**When explicit role attributes are redundant or harmful**

- Redundant: adding role="navigation" to a <nav> or role="main" to <main> duplicates native semantics — screen readers already expose these landmarks. - Harmful: mismatched roles (e.g., role="navigation" on a <div> used purely for presentation) can confuse AT; multiple identical landmarks without labels make navigation ambiguous. Overuse of roles can clutter the accessibility tree and reduce clarity.

**Best practices**- Prefer semantic HTML first; add aria-* only to provide extra semantics (labels, states) not to replace native elements. - If you add a landmark that may repeat (e.g., multiple <nav>), include aria-label or aria-labelledby.

**Example: blog layout (correct landmark usage)**

html

<body>
  <header> <!-- banner -->
    <h1>My Blog</h1>
    <nav aria-label="Primary navigation"> <!-- navigation -->
      <ul>...</ul>
    </nav>
  </header>

  <main> <!-- main -->
    <article>
      <h2>Post title</h2>
      <p>...</p>
    </article>

    <aside aria-label="Related posts"> <!-- complementary -->
      <!-- related links -->
    </aside>
  </main>

  <footer> <!-- contentinfo -->
    <p>© 2026 My Blog</p>
  </footer>
</body>

Use semantic elements and only add ARIA labels when multiple landmarks of the same type exist or when native semantics are absent.

Unlock Full Question Bank

Get access to hundreds of Semantic HTML and Accessibility interview questions and detailed answers.

Join thousands of developers preparing for their dream job.