Accessibility Interview Questions for 3 Years Experience

Accessibility interview questions for 3 years experience are about the layer of work a mid-level developer ships every week: the button, the form, the image, the page title. You are no longer asked what accessibility is. You are asked whether you can find the bug in a small piece of markup, name the WCAG success criterion behind it, and fix it without reaching for ARIA first. This guide works through 12 such questions, each with the markup, the fix and the criterion it maps to. Advanced widget work, such as live regions and complex ARIA patterns, belongs to a senior-level round and is deliberately left out.

What accessibility interview questions for 3 years experience actually test

An interviewer at this level is checking three habits. The first is whether you reach for the native element before anything else. W3C's Using ARIA guide opens with that rule: if you can use a native HTML element or attribute that already has the semantics and behavior you need, use it instead of repurposing an element and adding ARIA. The second is whether you can tie a defect to a criterion and its level, because "this fails WCAG" is weaker than "this fails 2.4.7 Focus Visible, Level AA". The third is whether you can separate what the standard requires from what is merely good practice. Each question below is built to exercise one of those habits.

Question 1: A teammate built a Save control as <div onclick="save()">. It works with a mouse. What does a keyboard user get?

How to approach it

Nothing, and the reason is the point of the question. A div is not focusable, so a keyboard user cannot reach it, and it has no button role, so a screen reader does not announce it as one. Two criteria map directly to this: 2.1.1 Keyboard, Level A, which says all functionality must be operable through a keyboard interface, and 4.1.2 Name, Role, Value, Level A, which says the name and role of user interface components must be programmatically determinable.

The tempting patch is role="button". MDN's button role page says that attribute does not add click or keyboard handling. On a non-focusable element you would also need tabindex and handlers for both Enter and Space, because buttons trigger on either key. Native buttons "provide keyboard and focus requirements by default", so the right fix is the element:

<button type="button" id="save">Save draft</button>

The type attribute matters. MDN's button element page says the default for a button associated with a form is submit, so a button inside a form that is not meant to submit should say type="button". A missing type on a "Cancel" or "Add row" button inside a form is how a form gets submitted by accident.

MDN also notes that a disabled button cannot be pressed or focused. That has a consequence worth mentioning: a disabled button drops out of the tab order, so a keyboard user may not discover it exists, and anything that explains why it is disabled needs to be available another way.

The mid-level answer states the rule, shows the one-line fix, and mentions the type trap. It also explains that the work to make a div behave is exactly the work the browser already does for a button.

Question 2: The signup form uses placeholders as labels and a red border to show errors. What is wrong?

How to approach it

There are two separate failures. A placeholder is not a label, and a colour change is not an error message.

The relevant criteria are 3.3.2 Labels or Instructions, Level A, which requires labels or instructions for user inputs, and 3.3.1 Error Identification, Level A, which requires automatically detected errors to be identified and described in text. Criterion 1.3.1 Info and Relationships, Level A, also applies when label relationships are not programmatically available.

W3C's forms tutorial on instructions says placeholder text is not a replacement for labels. It disappears when the user starts typing, and assistive technology does not treat it as a label. The tutorial's guidance on labeling controls is to use the label element, with the for attribute matching the control's id, because explicit labels are better supported by assistive technology than implicit ones. The label can be hidden visually, but it must stay in the markup, and the tutorial says not to hide it with display: none or visibility: hidden.

For errors, 3.3.1 Error Identification, Level A, requires that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. A red border alone does not meet that. The W3C notifications tutorial shows associating the message with the field using aria-describedby:

<label for="email">Email</label>
<input id="email" name="email" type="email"
       aria-describedby="email-hint email-err" aria-invalid="true" required>
<p id="email-hint">We only use it for receipts.</p>
<p id="email-err">Enter an address like name@example.com.</p>

Per MDN's aria-invalid page, set it from script as a result of validation, and do not mark an empty required field invalid until after a submit attempt. Setting aria-invalid="true" alone does not satisfy 3.3.1, because the error still has to be described in text.

One more criterion belongs in a mid-level answer. 1.3.5 Identify Input Purpose, Level AA, says the purpose of fields that collect information about the user can be programmatically determined, and the HTML autocomplete attribute is the mechanism. Understanding names tokens such as name, given-name, family-name and username. Adding the right autocomplete value to name and address fields is a small change that also helps users with motor or cognitive difficulties, and it is easy to miss in review.

Question 3: How do you decide the alt text for a logo, a chart, a decorative banner and an icon-only button?

How to approach it

Use the W3C alt decision tree, which turns the choice into questions about purpose. The criterion behind it is 1.1.1 Non-text Content, Level A: non-text content needs a text alternative that serves an equivalent purpose, controls need a name that describes their purpose, and pure decoration must be implemented so assistive technology can ignore it.

Applied to the four cases:

• A logo that is the only content of a link to the home page. The image is functional, so the alt text describes the destination. The W3C functional images tutorial uses "W3C home" as its example. If the logo sits inside a link whose text already names the destination, the alt text is empty, so the link is not announced twice.
• A decorative banner. Use a null alt, alt="". The decorative images tutorial says role="presentation" is not as widely supported as a null alt. A missing alt attribute is not the same as an empty one, and an image with no alt can be announced by its file name.
• A chart. Give a short alt and put the full information elsewhere on the page. The complex images tutorial notes that aria-describedby only suits text-only descriptions, because assistive technology reads it as one continuous paragraph without structure.
• An icon-only button. The icon has no text, so the button has no accessible name. MDN's button page recommends text inside the button, visually hidden with CSS that keeps it available to assistive technology if the design requires it, and adds that visible text can help people who do not recognize the icon.

<button type="button">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>
  <span class="visually-hidden">Search</span>
</button>

For an inline SVG that carries meaning, MDN's img role page says to set role="img" on the outer svg element and give it a label. The aria-hidden on the inner icon in the example is a common pairing with visible or visually hidden text, not a rule taken from those pages.

The misconception to correct is "every image needs descriptive alt text". Redundant and decorative images should have an empty one.

Question 4: The design has light-grey text on white and a pale input border. What contrast do you need, and where?

How to approach it

There are three separate requirements, and mixing them is the common mistake.

1.4.3 Contrast (Minimum), Level AA, requires a ratio of at least 4.5:1 for text and images of text, and at least 3:1 for large-scale text. Understanding defines large text as 18 point, or 14 point bold. MDN's button page gives the CSS equivalents as 24 pixels, or 18.66 pixels and bold. So "3:1 for anything over 18px" is wrong: 18 points is 24 CSS pixels. The criterion exempts text in inactive interface components, pure decoration, text that is not visible to anyone, and logo or brand-name text.

1.4.11 Non-text Contrast, Level AA, requires at least 3:1 against adjacent colors for visual information needed to identify interface components and their states, and for parts of graphics needed to understand the content. This is the criterion behind the pale input border: if the border is the only thing that shows where the field is, it needs 3:1. It excludes inactive components and cases where the browser determines the appearance and the author does not change it.

1.4.1 Use of Color, Level A, is a different question. Color must not be the only visual means of conveying information, indicating an action, prompting a response or distinguishing a visual element. A red-only error state fails it. Links distinguished from surrounding text only by color can also fail, but W3C Technique G183 allows a contrast ratio of at least 3:1 between the link text and surrounding text as a sufficient technique for meeting this criterion. Differences in visited and unvisited link colors are a separate exception.

Two practical points. The W3C forms tutorial on instructions notes that browsers' default placeholder color often fails the minimum contrast requirement, which is one more reason not to rely on placeholders. And check contrast with a tool on the real rendered colors, including hover, focus and disabled-adjacent states, instead of reading ratios by eye. This guide gives no ratio for a specific grey, because a stated ratio should come from a checker, not from memory.

The mid-level answer names all three criteria and says which one applies to text, which to the input border, and which to the error indication.

Question 5: A designer asks you to remove the focus outline because it looks ugly. What do you do?

How to approach it

Do not remove it without replacing it. 2.4.7 Focus Visible, Level AA, says any keyboard-operable interface has a mode of operation where the keyboard focus indicator is visible. MDN's :focus-visible page says that removing focus styles makes keyboard navigation inaccessible for sighted users, and the button page advises that if you override the default focus ring, the replacement needs enough contrast.

The compromise that usually satisfies the designer is :focus-visible. MDN explains that :focus always matches a focused element, while :focus-visible matches when the browser's heuristics determine that focus should be made evident. That is how mouse users avoid seeing a ring on click while keyboard users still get one. MDN's baseline note says it has been widely available across browsers since March 2022.

:focus-visible {
  outline: 3px solid #1a56db;
  outline-offset: 2px;
}

The color and width are examples; choose values that meet the contrast needs from Question 4 against the real background.

WCAG 2.2 added a second focus criterion that catches a different bug. 2.4.11 Focus Not Obscured (Minimum), Level AA, says that when a component receives keyboard focus it must not be entirely hidden by author-created content. A sticky header or cookie banner that covers the focused control fails it. Understanding names two ways to pass: avoid the overlap, or use scroll-padding so the browser scrolls the focused element clear of the sticky region:

html { scroll-padding-top: 5rem; } /* roughly the sticky header's height */

Note the wording: "entirely hidden". A partly covered component does not fail 2.4.11, though a fully obscured focus indicator would likely fail 2.4.7. The answer an interviewer wants is: keep a visible indicator, use :focus-visible for the design compromise, and test with the Tab key through the real page including sticky elements.

Question 6: What makes a page navigable by headings and landmarks, and what is a skip link for?

How to approach it

Start with the criterion, then separate rules from advice. 2.4.1 Bypass Blocks, Level A, requires a mechanism to bypass blocks of content that repeat across pages. A "Skip to main content" link at the top is the classic technique, and Understanding lists landmarks and headings as others.

<a class="skip" href="#main">Skip to main content</a>
<header>...</header>
<nav aria-label="Primary">...</nav>
<main id="main"><h1>Page topic</h1>...</main>
<footer>...</footer>

For landmarks, the ARIA Authoring Practices landmark regions guide says each page should have one main landmark, that a landmark role used more than once should have a unique label, and that the label should not repeat the role word ("Primary", not "Primary navigation", for a nav). It also covers when native elements become landmarks: header and footer map to banner and contentinfo only in the context of the body element, a section becomes a region only with an accessible name, and a form is a landmark only when it has one. Too many landmarks add noise, which MDN's form role page also notes.

For headings, be precise about what WCAG says. 1.3.1 Info and Relationships, Level A, requires that structure conveyed visually is available programmatically, so a visual heading should be marked as a heading. 2.4.6 Headings and Labels, Level AA, requires that headings and labels describe their topic or purpose. It does not require that headings exist.

The widely repeated rules "exactly one h1" and "never skip a level" are not stated in the Understanding documents I read. W3C's headings tutorial says skipping heading ranks can be confusing and should be avoided where possible, with an h2 followed directly by an h4 as its example, and it allows skipping when closing a subsection. Present these as good practice, not as conformance rules. That distinction is exactly what this question is testing.

Question 7: Build a FAQ accordion. Do you use native <details> or a button with aria-expanded?

How to approach it

Either is correct, and the answer is the trade-off.

The native route is <details> with a required <summary>. Per MDN's details page, it creates a disclosure widget, can be opened by clicking or by focusing the summary and pressing the space bar, and exposes an open attribute for programmatic control. The name attribute groups details elements so only one is open at a time, which gives an accordion with no script:

<details name="faq"><summary>What is the refund policy?</summary><p>...</p></details>

MDN warns about one trap: open="false" still opens the element, because open is a Boolean attribute and its presence means true.

The custom route follows the ARIA Authoring Practices disclosure pattern: a button that controls a content section, with Enter and Space toggling visibility, and aria-expanded set to true when the content is visible and false when hidden. The pattern lists aria-controls, pointing at the controlled element, as optional. The page I read does not discuss how well assistive technologies support it, so do not claim it as a guarantee.

<button type="button" aria-expanded="false" aria-controls="faq1">
  What is the refund policy?
</button>
<div id="faq1" hidden>...</div>

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

When to choose which: prefer the native element when its behavior and styling fit, because it brings keyboard and state handling for free. Choose the button pattern when you need animation control, content loaded on demand, or a design the native element cannot be styled into. Whichever you choose, the control must be a real button or summary, the state must be exposed, and the open and closed states must be testable with the keyboard alone. If an interviewer asks about the first rule of ARIA, this question is a natural place to cite it.

Question 8: QA zooms to 200% and then 400% and the layout breaks. What do the criteria require?

How to approach it

Three criteria are involved, and they are not the same test.

1.4.4 Resize Text, Level AA, requires that text can be resized without assistive technology up to 200 percent without loss of content or functionality, except for captions and images of text. Listed failures include clipping or truncation at 200 percent and text-based form controls that do not resize.

1.4.10 Reflow, Level AA, requires that vertically scrolling content works at a width equivalent to 320 CSS pixels, and horizontally scrolling content at a height equivalent to 256 CSS pixels, without loss of information or functionality and without scrolling in two dimensions. Parts that need a two-dimensional layout for usage or meaning, such as some data tables, are excepted. A note on the page explains that 320 CSS pixels is a 1280 CSS pixel viewport at 400 percent zoom, which is where the "400 percent" figure comes from. So "WCAG requires 400 percent zoom" is a shorthand for a reflow requirement, not the wording of the criterion.

1.4.12 Text Spacing, Level AA, requires no loss of content or functionality when a user sets line height to at least 1.5 times the font size, spacing after paragraphs to at least 2 times, letter spacing to at least 0.12 times and word spacing to at least 0.16 times. It is about content surviving user overrides, such as fixed-height containers that clip text when spacing grows.

Typical causes and fixes: fixed height on text containers (use min-height or let content size), px font sizes inside rigid layouts, and wide fixed-width components that force horizontal scrolling. Use relative units and layouts that wrap.

One more cause deserves a mention. A viewport meta tag that blocks zooming works against all of this. MDN's viewport page says disabling zoom with user-scalable=no prevents people with low vision from reading content and notes WCAG requires scaling to at least 2 times. The W3C ACT rule Meta viewport allows for zoom expects no maximum-scale value below 2. I did not find a numbered failure technique for this, so cite the ACT rule and MDN rather than a technique number.

<meta name="viewport" content="width=device-width, initial-scale=1">

Question 9: When is something a link and when a button, and what about links that open a new tab?

How to approach it

The working rule is that a link navigates and a button performs an action. That rule is a convention taught in accessibility guidance, not a quotation from WCAG, but the keyboard behavior behind it is documented: MDN's button role page says buttons trigger on Space or Enter, while links trigger on Enter only. A link styled as a button therefore needs extra handling for Space, which is one reason to use a real button for actions.

For links, 2.4.4 Link Purpose (In Context), Level A, requires that the purpose of each link can be determined from the link text alone or from the text together with its programmatically determined context. So "click here" is not automatically a failure when context is programmatic, but it is poor practice, because screen reader users often browse a list of links out of context. The stricter 2.4.9 Link Purpose (Link Only) is Level AAA, so it is not part of an AA target.

New tabs are a common review comment. The W3C technique G201 is to give advance warning for links and buttons that open a new window or tab. It is listed as advisory, and the related criterion, 3.2.5 Change on Request, is Level AAA. Warning users before opening a new tab is good practice, but it is not explicitly required at any WCAG conformance level. W3C lists advance warning as an advisory technique, including for the Level AAA criterion 3.2.5 Change on Request.

<a href="https://example.com" target="_blank" rel="noopener">
  Docs <span class="visually-hidden">(opens in a new tab)</span>
</a>

The rel="noopener" in that snippet is a common security habit that the sources above do not cover.

WCAG 2.2 added a size criterion that interviewers now ask about. 2.5.8 Target Size (Minimum), Level AA, requires pointer targets to be at least 24 by 24 CSS pixels, with exceptions: undersized targets can pass when spaced so that a 24 pixel circle centered on each does not intersect another target, when an equivalent control on the page meets the size, when the target is inline in a sentence, when its size is set by the browser, or when a particular presentation is essential. MDN's button page recommends 44 by 44 CSS pixels as a minimum interactive size, which is a recommendation and not the AA number.

Question 10: How do you mark up a data table so a screen reader user can navigate it?

How to approach it

Mark the structure, not just the look. W3C's tables tutorial says header cells must be marked with th and data cells with td, and that without structural markup the relationships cannot be determined programmatically. That is 1.3.1 Info and Relationships, Level A, applied to tables.

<table>
  <caption>Opening hours</caption>
  <thead>
    <tr><td></td><th scope="col">Open</th><th scope="col">Close</th></tr>
  </thead>
  <tbody>
    <tr><th scope="row">Monday</th><td>9:00</td><td>17:00</td></tr>
  </tbody>
</table>

The pieces, with their sources:

• caption. The caption and summary tutorial says a caption functions like a heading for the table, most screen readers announce it, and it is the main way to identify a table when browsing in tables mode. It goes directly inside the table element.
• scope. The two-headers tutorial uses scope="col" and scope="row" to define header direction for tables with headers in the top row and first column.
• id and headers. For tables where column headers change part-way, or three or more header cells apply to one data cell, the multi-level tutorial uses id on each th and headers on each td, and also suggests splitting such tables into simpler ones.
• Not summary. MDN's table accessibility guide says the summary attribute is deprecated and invisible to sighted users, and recommends a caption.

Real world tables break these rules in predictable ways: headers built from td cells styled bold, a visual caption in a div above the table, and merged cells with no association markup. A fix is to test by navigating the table with a screen reader, which announces the row and column headers for each cell if the markup is right.

I did not find a statement in the pages I read about not using tables for layout, so this guide does not attribute that rule to a source. If asked, say that tables are for tabular data and layout belongs to CSS, and that you would not cite the standard for it.

Question 11: The home page has an auto-rotating carousel. What must it provide?

How to approach it

The criterion is 2.2.2 Pause, Stop, Hide, Level A. For moving, blinking or scrolling content that starts automatically, lasts more than five seconds and is presented in parallel with other content, there must be a mechanism to pause, stop or hide it, unless it is part of an essential activity. For auto-updating content that starts automatically and is presented alongside other content, the mechanism can also be control over the update frequency, and the five-second condition does not apply. A common misconception is that any auto-playing carousel fails; the requirement is the control.

The related criterion is 2.2.1 Timing Adjustable, Level A, which applies to time limits the content sets. It requires at least one of turning the limit off, adjusting it over a range at least ten times the default, or extending it after a warning with at least 20 seconds to respond, with exceptions for real-time events, essential limits and limits longer than 20 hours.

Beyond the WCAG requirements above, the ARIA Authoring Practices carousel pattern recommends the following behaviors and accessibility features:

• Previous and next slide buttons, and optionally slide picker controls.
• For automatic rotation, a button that stops and restarts it, with rotation also stopping while keyboard focus is inside the carousel and while the mouse hovers.
• The rotation control as the first stop in the Tab order within the carousel, so a keyboard user finds it before the moving content.
• A rotation button whose label changes between "Stop slide rotation" and "Start slide rotation", so the pattern says not to use aria-pressed on it.
• The container with the region or group role and aria-roledescription="carousel", and each slide as a group with a label.
• Native button elements for the controls, which the pattern recommends.

<button type="button" id="rotate">Stop slide rotation</button>

The pattern also describes aria-live behavior on the slide container. That detail overlaps with live-region questions, so treat it as a follow-up topic rather than part of the core answer.

The best answer also questions the carousel itself: ask whether it needs to auto-rotate at all, since removing the automatic movement removes the requirement.

Question 12: What do lang and <title> do, and why do they matter?

How to approach it

Both are one-line changes with real effect, and both are Level A criteria that automated tools check cheaply.

3.1.1 Language of Page, Level A, requires that the default human language of each page can be programmatically determined, and Understanding says screen readers can then load the correct pronunciation rules. In HTML that is the lang attribute on the root element. MDN's lang page says the attribute holds a single BCP 47 language tag, recommends always specifying a value, and explains that its main purpose is to let assistive technologies such as screen readers use the correct pronunciation. So the common belief that lang only matters for browser translation is incomplete.

3.1.2 Language of Parts, Level AA, covers passages in another language, with exceptions for proper names, technical terms, words of indeterminate language, and words that have become part of the surrounding text's vernacular. Understanding's example is <span lang="es">Español</span> inside a link on an English page. You do not need to mark every borrowed word.

<html lang="en">
  <head><title>Accessibility interview questions | GreatFrontEnd</title></head>
  <body><p>The French word <span lang="fr">bonjour</span> is common.</p></body>
</html>

2.4.2 Page Titled, Level A, requires that each page has a descriptive title, and the stated intent is to help users find content and orient themselves. MDN's title page says titles should be unique to every page, ideally with the primary purpose first and the site name after, and that screen reader users commonly read the title to infer what a page contains.

The mid-level point is single-page applications. A client-side route change does not change the document title by itself, so a router that never updates title leaves every view with the same name in the tab, in history and in the screen reader's announcement. Setting a unique title per route is part of the same fix as lang, and it is worth checking in any SPA you review.

Common mistakes in accessibility interview questions for 3 years experience

• Fixing a div with role="button" and no keyboard handling, when a native button exists.
• Treating a placeholder as a label, or treating a red border as an error message.
• Calling every image decorative or every image descriptive. Purpose decides the alt text.
• Mixing the contrast criteria. Text, interface components and color-only cues are three separate checks.
• Removing outline without a visible replacement, or letting a sticky header cover the focused control.
• Quoting "one h1" or "no skipped levels" as WCAG rules. They are practice, not requirements in the pages cited here.
• Citing AAA criteria as AA, such as 2.4.9 or 3.2.5.
• Forgetting lang and unique page titles in single-page applications.

Frequently asked questions

Do I need to memorize WCAG numbers? Know the ones you use daily: 1.1.1, 1.3.1, 1.4.3, 1.4.11, 2.1.1, 2.4.2, 2.4.7, 3.3.1 and 4.1.2. What matters more is naming the criterion's level and saying what it requires in your own words.

Which conformance level should I target? The sources here describe criteria at A, AA and AAA, and AA is the level most commonly cited in requirements, but a legal or contractual target depends on your employer and jurisdiction, so ask rather than assume.

Is ARIA bad? No. W3C's rule is to use a native element when one fits. ARIA is for cases where HTML has no equivalent, and it adds meaning without adding behavior, as the button example showed.

How do I test all this? Tab through the page without a mouse, zoom to 200 and 400 percent, check contrast with a tool, and try a screen reader on a form and a table. Automated scanners catch some of these issues but not all, so manual passes remain part of the job.

How to prepare

Take one page from a project you know and audit it against the 12 questions in an hour: Tab through it, replace one div button with a button, add real labels and an error message to one form, fix the alt text on five images, check the contrast of body text and an input border, restore a visible focus style, add a skip link, zoom to 400 percent, and read the page title and lang. Writing down what you changed and which criterion it maps to gives you answers built from real work. For HTML fundamentals that support these answers, see GreatFrontEnd's HTML interview questions for 3 years experience, and for the CSS side of focus and zoom, the CSS interview questions guide.

Conclusion

Accessibility interview questions for 3 years experience test whether you can take a small piece of markup and say what is wrong, which criterion and level it maps to, and the smallest correct fix. Native elements come before ARIA, labels and text errors come before color and placeholders, alt text depends on purpose, contrast has three separate checks, focus must be visible and unobscured, structure comes from landmarks and headings with the rules separated from the advice, disclosure and carousels need real controls, zoom and reflow are different tests, tables need header markup, and lang and page titles are cheap and checkable. If you can state the criterion, its level and the fix for each of the 12 questions here, you are answering at the level this round is looking for.