DEV Community: A11Y Practice

Test Your Tabs: One Tab Stop, Arrow Keys, a Focusable Panel and No Up/Down

A11Y Practice — Wed, 04 Nov 2026 08:12:10 +0000

A tab list can look perfect and still hide a tab from the keyboard. In the Full Tabs Pattern lab on wasexamprep.com, one broken case hard-codes tabIndex={-1} on the second tab. A mouse can click it. Tab skips it. The arrow keys do nothing. That is a WCAG 2.1.1 Keyboard failure.

The other broken case puts every tab in the Tab order. That is clumsy and it is not the WAI-ARIA APG Tabs pattern, but every tab is still reachable and operable, so it passes 2.1.1. It is a best-practice deviation. The full write-up with the 2.1.1 reasoning, the tree evidence and the VoiceOver captures is on the blog. This post is about locking the behavior in with tests, and about the mistakes those tests catch.

One more thing makes this a good test case: the lab's fixed example changed this week. The panels got tabindex="0", and the handler stopped listening for ArrowUp and ArrowDown. Against the new component, the old test suite failed only once (the next Tab no longer left the widget, it landed on the panel). Nothing in it checked Up/Down, the panel's focus ring or Shift+Tab through the panel. The tests below fail on the old component and pass on the new one.

The contract

For a horizontal tab list with automatic activation:

Tab into the tab list lands on the selected tab. It is the only tab with tabindex="0"; every other tab has -1.
Left and Right Arrow move focus and selection to the previous and next tab, and wrap at the ends.
Home and End go to the first and last tab.
ArrowUp and ArrowDown are not handled, so they keep scrolling the page (APG: a horizontal tab list does not listen for them).
The next Tab moves out of the tab list onto the visible panel, because the panel has no focusable content and has tabindex="0". It needs a visible focus ring (2.4.7).
Shift+Tab walks back: panel, then the selected tab - not the first tab.

The lab's handler, from fixed-example.tsx:

function handleTabListKeyDown(event: React.KeyboardEvent<HTMLDivElement>) {
    const order = tabs.map((tab) => tab.id);
    const index = order.indexOf(activeTab);
    let nextIndex = index;

    switch (event.key) {
        case "ArrowRight":
            nextIndex = (index + 1) % order.length;
            break;
        case "ArrowLeft":
            nextIndex = (index - 1 + order.length) % order.length;
            break;
        case "Home":
            nextIndex = 0;
            break;
        case "End":
            nextIndex = order.length - 1;
            break;
        default:
            return;
    }

    event.preventDefault();
    selectTab(order[nextIndex]);
}

Each tab gets tabIndex={activeTab === tab.id ? 0 : -1} and aria-selected={activeTab === tab.id}, and each panel gets role="tabpanel", tabIndex={0}, aria-labelledby and hidden={activeTab !== tab.id}. selectTab sets the state and calls focus() on the new tab.

Testing Library + user-event

user.tab() follows the real Tab order, including tabindex and hidden, so it catches a wrong roving index or a missing panel stop. Put a button before and after the widget so you can prove exactly where focus goes.

function setup() {
    const user = userEvent.setup();
    render(
        <>
            <button type="button">Before</button>
            <FixedExample />
            <button type="button">After</button>
        </>,
    );
    const tablist = screen.getByRole("tablist", { name: "Settings" });
    const tab = (name: string) => within(tablist).getByRole("tab", { name });
    const panel = (name: string) => screen.getByRole("tabpanel", { name });
    return { user, tab, panel };
}

function expectActive(tab: HTMLElement) {
    expect(tab).toHaveFocus();
    expect(tab).toHaveAttribute("aria-selected", "true");
    expect(tab).toHaveAttribute("tabindex", "0");
}

it("has one Tab stop in the tablist, then the panel, then out", async () => {
    const { user, tab, panel } = setup();
    await user.tab(); // "Before"
    await user.tab();
    expectActive(tab("Account"));
    expect(tab("Notifications")).toHaveAttribute("tabindex", "-1");
    expect(tab("Security")).toHaveAttribute("tabindex", "-1");
    await user.tab(); // into the panel (no focusable content, so tabindex="0")
    expect(panel("Account")).toHaveFocus();
    await user.tab();
    expect(screen.getByRole("button", { name: "After" })).toHaveFocus();
});

it("ArrowUp and ArrowDown are not handled on a horizontal tablist", async () => {
    const { user, tab } = setup();
    await user.click(tab("Notifications"));
    const down = new KeyboardEvent("keydown", { key: "ArrowDown", bubbles: true, cancelable: true });
    tab("Notifications").dispatchEvent(down);
    expect(down.defaultPrevented).toBe(false); // the page can still scroll
    await user.keyboard("{ArrowDown}{ArrowUp}");
    expectActive(tab("Notifications"));
});

it("Tab returns to the last selected tab, not the first one", async () => {
    const { user, tab } = setup();
    await user.click(tab("Account"));
    await user.keyboard("{ArrowRight}");
    await user.tab(); // panel
    await user.tab(); // leave the widget
    await user.tab({ shift: true }); // panel
    await user.tab({ shift: true }); // tab
    expectActive(tab("Notifications"));
});

The full file also covers Right with wrap, Left with wrap, Home/End, Shift+Tab from the panel and "all three panels stay in the DOM with tabindex="0", only one is exposed". The Up/Down test checks defaultPrevented directly: "focus did not move" alone would also pass for a handler that swallows the key and blocks scrolling.

The broken cases get tests too, written to the 2.1.1 line rather than to the APG:

it("Case 2: Notifications is never a Tab stop (2.1.1 failure)", async () => {
    const { user, tabIn } = setupBroken();
    const account = tabIn("Alert preferences", "Account");
    const notifications = tabIn("Alert preferences", "Notifications");
    await user.click(notifications); // a mouse can select it
    expect(notifications).toHaveAttribute("aria-selected", "true");
    expect(notifications).toHaveAttribute("tabindex", "-1"); // still out of the Tab order
    const visited: Element[] = [];
    screen.getByRole("button", { name: "Before" }).focus();
    for (let i = 0; i < 8; i++) {
        await user.tab();
        visited.push(document.activeElement as Element);
    }
    expect(visited).toContain(account);
    expect(visited).not.toContain(notifications);
});

Its sibling asserts that in Case 1 Tab reaches Notifications and Enter selects it: no arrow keys, but operable.

Run on 2026-11-01 with vitest 2.1.9 and jsdom, against FixedExample and BrokenExample copied from the lab: 10 of 10 pass. Against the pre-fix component, 4 fail: the panel stop, Shift+Tab, the panel tabindex check and Up/Down. Setup notes: toHaveFocus and toBeVisible come from @testing-library/jest-dom (import @testing-library/jest-dom/vitest in a setup file), and you need afterEach(cleanup) or the renders pile up.

Playwright, against a real browser

jsdom has no layout, no :focus-visible and no CSS, so the focus ring can only be checked in a browser. The helper below answers one question: which tabs can a keyboard-only user focus? It tries every arrow, Home, End and plain Tab, and only counts tabs inside the tab list under test.

async function keyboardReachableTabs(page: Page, tablist: Locator, firstTab: Locator) {
    const reached = new Set<string>();
    await firstTab.focus();
    const record = async () => {
        // Only count tabs inside THIS tablist (Tab can wander into the next widget).
        const name = await tablist.evaluate((list) => {
            const el = document.activeElement;
            return el && list.contains(el) && el.getAttribute("role") === "tab" ? el.textContent?.trim() ?? "" : "";
        });
        if (name) reached.add(name);
    };
    await record();
    const count = await tablist.getByRole("tab").count();
    for (const key of ["ArrowRight", "ArrowLeft", "Home", "End"]) {
        for (let i = 0; i < count; i++) {
            await page.keyboard.press(key);
            await record();
        }
    }
    await firstTab.focus();
    for (let i = 0; i < count; i++) {
        await page.keyboard.press("Tab");
        await record();
    }
    return [...reached].sort();
}

The fixed-flow test ends with the panel:

// One Tab press leaves the tablist and lands on the visible panel (tabindex="0").
await page.keyboard.press("Tab");
const panel = page.getByRole("tabpanel", { name: "Security" });
await expect(panel).toBeFocused();
await expect(panel).toHaveAttribute("tabindex", "0");
// The ring is a box-shadow (Tailwind focus-visible:ring-2), not an outline.
expect(await panel.evaluate((el) => el.matches(":focus-visible"))).toBe(true);
expect(await panel.evaluate((el) => getComputedStyle(el).boxShadow)).toMatch(/0px 0px 0px 2px/);

// The next Tab leaves the widget; Shift+Tab walks back panel > selected tab.
await page.keyboard.press("Tab");
await expect(panel).not.toBeFocused();
await page.keyboard.press("Shift+Tab");
await expect(panel).toBeFocused();
await page.keyboard.press("Shift+Tab");
await expect(tab("Security")).toBeFocused();

And Case 2 is documented as a known bug, so the build stays green while the bug is visible:

test("broken Case 2: Notifications is unreachable (2.1.1)", async ({ page }) => {
    test.fail(); // documents the bug: this assertion is expected to fail
    const tablist = page.getByRole("tablist", { name: "Alert preferences", exact: true });
    const reached = await keyboardReachableTabs(page, tablist, tablist.getByRole("tab", { name: "Account" }));
    expect(reached).toEqual(["Account", "Notifications"]);
});

Run against production on 2026-11-01 (Playwright 1.64.1, headless Chromium): 5 of 5 as expected. The reachability test maps to 2.1.1; the fixed-flow test checks the APG convention. Keep them separate so a failing build tells you which one broke.

Common mistakes

Static tabindex. 0 on the first tab, -1 on the rest, never updated. After a click, the unselected first tab keeps the Tab stop, and with no arrow handler the other tabs are mouse-only. Derive tabIndex from the same state as aria-selected.
Two sources of truth. aria-selected from one variable, tabIndex or the active style from another. One activeTab, everything derived from it.
State without focus. Only calling setActiveTab gives the new tab tabindex="0" while focus stays on the old tab, which now has -1. Call focus().
No wrap. Math.min(index + 1, last) stops at the end. Use (index + 1) % length and (index - 1 + length) % length.
preventDefault on every key. Without default: return, you swallow Tab and trap the user in the widget.
Handling Up/Down on a horizontal tab list. It takes the page's scroll keys away. Leave them alone, or make the list vertical with aria-orientation="vertical" and use Up/Down instead. Not a 2.1.1 failure, but not the pattern.
A text-only panel with no Tab stop. Without tabindex="0", Tab jumps from the tab straight past the content. And if you add the stop, add a visible focus ring with it.
Manual activation with the automatic handler. order.indexOf(activeTab) is correct only when focus and selection always match. With manual activation (arrows move focus, Enter or Space selects), compute the index from document.activeElement and move focus only.
Trusting focusable: true. Chrome's accessibility tree reports it for a tabindex="-1" tab. Focusable from script is not reachable with Tab. Press the keys.
Substring names in Playwright. getByRole("tablist", { name: "Settings" }) also matched "Account settings" in the lab. Use exact: true. Testing Library's string name is exact by default.
Calling Case 1 a 2.1.1 failure. Tab on every tab is reachable and operable. Report it as a best-practice deviation; save 2.1.1 for the tab nobody can reach.

VoiceOver, from real captures only

From the lab's VoiceOver capture docs (VoiceOver on macOS, captured 2026-06-12, before the panel fix; the tabs did not change). Broken Case 2, the only tab in the Tab order:

Account, selected, tab, 1 of 2, Alert preferences, tab group

Fixed, Tab in, then Right Arrow twice:

Account, selected, tab, 1 of 3, Settings, tab group

Notifications, selected, tab, 2 of 3

Security, selected, tab, 3 of 3

The wrap, Left Arrow, Home, End and the Tab into the panel were captured on 2026-11-01 on the live lab after the panel fix, with VoiceOver on Mac (macOS 26.6.2, VoiceOver 10, Chrome 156.0.8078.79). These are keyboard-focus announcements, not VoiceOver-cursor reading:

Right Arrow from Security (wraps): "Account selected tab, 1 of 3"
Left Arrow from Account (wraps): "Security selected tab, 3 of 3"
Home: "Account selected tab, 1 of 3"
End: "Security selected tab, 3 of 3"
Tab from the Notifications tab into its panel: "âœ… Fixed Example region Notifications tab panel"

Keep practicing

Try both broken cases yourself in the Full Tabs Pattern lab on wasexamprep.com, then read the full write-up.

Watch the full walkthrough and subscribe to the A11Y in Practice YouTube channel for more hands-on accessibility episodes.

A11Y in Practice and wasexamprep.com are independent educational resources. They are not affiliated with or endorsed by IAAP (International Association of Accessibility Professionals).

aria-selected on tabs: the selected tab that lies (WCAG 4.1.2)

A11Y Practice — Wed, 28 Oct 2026 08:25:18 +0000

The Notifications tab is open. Its panel is on screen: "Choose which email and push alerts you receive." Then VoiceOver lands on the other tab and says Account, selected, tab, 1 of 2, Alert preferences, tab group. On Notifications, the tab you are looking at, it says Notifications, tab, 2 of 2. No selected. The tab you see is not the tab the code says.

WCAG 4.1.2 Name, Role, Value has three parts. In E07 (A Custom Div Is Not a Checkbox), a custom control never told VoiceOver it was a checkbox - that was the role. This breakdown is the value. The name and the role are already right here (Account, tab, 1 of 2); the state is wrong.

This breakdown uses the Selected State lab (E10): Case 1 (no aria-selected at all) and Case 2 (aria-selected hard-coded). The evidence comes from real accessibility-tree and VoiceOver captures.

The problem

Case 1 - `role="tab"` with no `aria-selected`

The tab list is real: role="tablist" with an aria-label, and two buttons with role="tab". The active tab only gets a different background class. Nothing in the markup says which tab is selected:

<div role="tablist" aria-label="Account settings" class="tab-bar">
  <button type="button" role="tab" id="selected-state-broken-case1-account-tab">
    Account
  </button>
  <button
    type="button"
    role="tab"
    id="selected-state-broken-case1-notifications-tab"
  >
    Notifications
  </button>
</div>

The selection lives in a CSS class. Assistive technology cannot read a class name.

What VoiceOver announced (broken, Case 1)

On first load, with Account visually active:

Account, selected, tab, 1 of 2, Account settings, tab group

You are currently on a selected tab, 1 of 2.

That sounds right, but there is no aria-selected in the markup. The capture notes say VoiceOver may announce selected here without a matching programmatic value in the tree. Do not build on it.

After activating Notifications, with the Notifications panel visible:

Notifications, tab, 2 of 2

You are currently on a tab, 2 of 2. To select this option, press Control-Option-Space.

It is asking you to select the tab you just selected.

What the accessibility tree showed (broken, Case 1)

Captured after activating Notifications:

tablist "Account settings", multiselectable: false
tab "Account" - focusable: true, selected: false
tab "Notifications" - focusable: true, selected: false

Two tabs. Neither one is selected. The screen shows an open tab; the code exposes none. Without aria-selected, the tree's selected state does not track the visual active tab.

Case 2 - `aria-selected` hard-coded

This is the partial fix. Someone read "add aria-selected" and added it - as literal values:

<button
  type="button"
  role="tab"
  aria-selected={true}
  onClick={() => setCase2Active("account")}
  className={...}
>
  Account
</button>
<button
  type="button"
  role="tab"
  aria-selected={false}
  onClick={() => setCase2Active("notifications")}
  className={...}
>
  Notifications
</button>

The click updates case2Active, which switches the styling and the panel. aria-selected never reads it. On first load that even looks correct, because Account is the starting tab. The bug only shows up when you switch.

What VoiceOver announced (broken, Case 2)

With Notifications focused and its panel visible:

Notifications, tab, 2 of 2

And on Account, which is no longer the open tab:

Account, selected, tab, 1 of 2, Alert preferences, tab group

What the accessibility tree showed (broken, Case 2)

tablist "Alert preferences", multiselectable: false
tab "Account" - focusable: true, selected: true
tab "Notifications" - focusable: true, focused: true, selected: false

The tree agrees with VoiceOver, and both disagree with the screen. Focus moved. Selection didn't.

Why this fails exam-style

4.1.2 Name, Role, Value (Level A) requires that the name and role of user interface components can be programmatically determined, that states the user can set can be programmatically set, and that changes to these items are available to assistive technologies. Which tab is selected is a state the user sets by clicking a tab. If the code never updates it, assistive technology is told the wrong thing.
The WAS rule for this (Custom Widgets, "Bound ARIA States"): "States such as aria-expanded, aria-selected, aria-checked, and aria-pressed MUST update when the UI changes - stale values mislead screen reader users."
Case 1 exposes no selected tab: both tabs are selected: false in the tree while one is visibly open.
Case 2 exposes the wrong selected tab. The attribute is present and its values are valid, so a quick check for the attribute finds it - but the value is stale.
Exam signal for missing state: a tab list where no tab has selected: true while one panel is visible. Exam signal for stale state: selected: true on a tab that is not the open one, often next to focused: true on the tab that is. In both cases, test after switching, and check both tabs - not only the first one.
Name and role problems (a control that does not expose what it is) are the E07 side of 4.1.2. role="tabpanel" / aria-controls and arrow-key navigation are separate topics (Panel Association and Full Tabs Pattern labs).

The fix

Bind aria-selected to the same state that drives the active styling and the panel: true on the active tab, false on every other tab. The same fix repairs both cases. In React:

<button
  type="button"
  role="tab"
  id="selected-state-fixed-case1-account-tab"
  aria-selected={case1Active === "account"}
  onClick={() => setCase1Active("account")}
  className={...}
>
  Account
</button>
<button
  type="button"
  role="tab"
  id="selected-state-fixed-case1-notifications-tab"
  aria-selected={case1Active === "notifications"}
  onClick={() => setCase1Active("notifications")}
  className={...}
>
  Notifications
</button>

Without a framework, update the attribute in the same place you switch the tab:

const accountTab = document.querySelector(
  "#selected-state-fixed-case1-account-tab",
);
const notificationsTab = document.querySelector(
  "#selected-state-fixed-case1-notifications-tab",
);

function setActiveTab(id) {
  accountTab.setAttribute("aria-selected", String(id === "account"));
  notificationsTab.setAttribute("aria-selected", String(id === "notifications"));
}

accountTab.addEventListener("click", () => setActiveTab("account"));
notificationsTab.addEventListener("click", () => setActiveTab("notifications"));

Not a CSS class. Not a hard-coded true.

What changed in the tree (fixed)

With the Notifications panel visible in both cases:

Case 1: tab "Account" - focusable: true, selected: false; tab "Notifications" - focusable: true, selected: true. The Notifications node lists aria-selected: true, the Account node aria-selected: false.
Case 2: tab "Account" - focusable: true, selected: false; tab "Notifications" - focusable: true, focused: true, selected: true.
Contrast broken Case 2, where Account stayed selected: true after Notifications became active.

Exactly one tab is selected, and it is the one on screen. The tree finally matches the page.

What VoiceOver announced (fixed)

Case 2, with Account active:

Account, selected, tab, 1 of 2, Alert preferences, tab group

The hint on the active Account tab (Case 1):

You are currently on a selected tab, 1 of 2.

The capture also records a state-only reading for Case 2 (the lab's evidence caption places it on the active Notifications tab):

selected

To be honest about the evidence: the lab capture does not include a full VoiceOver announcement for the active Notifications tab after the fix, so this post does not quote one. The proof for the fix is the tree above - selected: true on exactly the visible tab. While Account is active, the inactive Notifications tab reads:

Notifications, tab, 2 of 2

You are currently on a tab, 2 of 2. To select this option, press Control-Option-Space.

Behaviors to verify

Exactly one tab in each tab list has aria-selected="true"; every other tab has aria-selected="false".
aria-selected reads the same state that drives the active styling and the visible panel - no literal true or false.
Switch tabs, then check the accessibility tree: selected: true must follow the visible tab. Then move VoiceOver to both tabs, not just the first one, and confirm only the open tab is announced as selected. Do not trust a first-load listen.

Practice it

Video: https://youtu.be/939KZzpMFuk
Short: https://youtube.com/shorts/l2yr49-N8b8
Lab: Selected State lab
Companion write-up: https://www.wasexamprep.com/go/e10-blog-devto

Takeaway: present is not correct. A tab's aria-selected has to follow the tab that is actually open. Switch tabs, and check the tree, not just your ears.

If this was useful, subscribe to A11Y in Practice on YouTube (@a11yinpractice) for more hands-on accessibility episodes, and visit wasexamprep.com for WAS study notes and labs.

Independent study notes - not affiliated with IAAP or W3C.

th scope row vs col: table headers that sound fine but are wrong (WCAG 1.3.1)

A11Y Practice — Wed, 21 Oct 2026 07:51:26 +0000

"Jane Doe" on its own is a word in a box. Is she the instructor, a student, a guest? In a properly built table, VoiceOver says Instructor Jane Doe, column 2 of 3 - the header is what turns the word into a fact. Lose that relationship in the code and the table is just a grid of words, no matter how clear it looks on screen.

This breakdown uses the Table Headers lab (E09): Case 1 (<th> without scope) and Case 2 (scope="row" on column headers). Both use real header cells and both sound fine in VoiceOver. The evidence comes from real accessibility-tree and VoiceOver captures.

The problem

Case 1 - `<th>` without `scope`

The course table has a proper thead with three <th> cells, but none of them says which direction it labels:

<table id="table-headers-broken-case1-course-table">
  <thead>
    <tr>
      <th id="table-headers-broken-case1-course-header">Course</th>
      <th>Instructor</th>
      <th>Room</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Intro to WAS</td>
      <td>Jane Doe</td>
      <td>101</td>
    </tr>
    <!-- ARIA Patterns / Sam Lee / 204, Keyboard Testing / Alex Kim / 115 -->
  </tbody>
</table>

What the accessibility tree showed (broken)

table "" > rowgroup "" > row "" with columnheader "Course", columnheader "Instructor" and columnheader "Room"
Focused columnheader "Course": Role columnheader, Focusable: false - and no Scope property in the Chrome pane, because there is no scope in the HTML
Data rows are row "" nodes with cell children (cell "Intro to WAS", cell "Jane Doe", cell "101")

Chrome inferred the column headers from position in thead.

What VoiceOver announced (broken)

Moving through the table with Control-Option and the arrow keys:

table, 3 columns, 4 rows

Course Course, column 1 of 3

row 2 of 4 Course Intro to WAS, column 1 of 3

Instructor Jane Doe, column 2 of 3

end of table

Inferred, not declared

The guess landed, but it was a guess. The W3C WAI Tables Tutorial accepts top-row <th> without scope only for small tables with clearly distinct columns; scope is needed when data is ambiguous or the table is larger. The WAS rule is simpler: put scope on every <th> whenever you can.

Case 2 - `scope="row"` on column headers

This is the partial fix. Someone read "add scope" and added it - with the wrong value:

<thead>
  <tr>
    <th scope="row" id="table-headers-broken-case2-course-header">Course</th>
    <th scope="row">Instructor</th>
    <th scope="row">Room</th>
  </tr>
</thead>

What the accessibility tree showed (broken, Case 2)

The header row now exposes rowheader "Course", rowheader "Instructor" and rowheader "Room" - not columnheader
Focused rowheader "Course": Role rowheader. Chrome's pane shows no Scope property, so the scope="row" itself is read from the markup.
The data row / cell structure is unchanged

The code now claims each of those cells labels its own row, not the column below it. The page shows one relationship; the code declares another.

What VoiceOver announced (broken, Case 2)

The lab's capture notes record VoiceOver for Case 2 as identical to Case 1, so it was not re-recorded. By ear, nothing changed. The failure only shows up in the tree.

Why this fails exam-style

1.3.1 Info and Relationships (Level A) requires that relationships conveyed visually can be programmatically determined.
Case 2 declares the wrong relationship: the visual table has column headers, the code has row headers.
Case 1 relies on browser inference. It happens to work here, but the association is inferred, not declared - which is why the WAS habit is explicit scope.
Exam signal for a wrong scope: rowheader in the tree, confirmed by scope="row" in the markup. Exam signal for missing versus correct scope on a simple thead table: the HTML, not Chrome's pane.
<caption> and headers / id are separate topics (Table Captions and Complex Relationships labs).

The fix

Give every column header scope="col". One attribute, on each <th> in the header row. The same fix repairs both cases:

<thead>
  <tr>
    <th scope="col" id="table-headers-fixed-case1-course-header">Course</th>
    <th scope="col">Instructor</th>
    <th scope="col">Room</th>
  </tr>
</thead>

In React / JSX the attribute keeps its name. When headers run down the side instead, scope="row" belongs on the first cell of each data row (illustrative, not part of this lab):

<tr>
  <th scope="row">Intro to WAS</th>
  <td>Jane Doe</td>
  <td>101</td>
</tr>

What changed in the tree (fixed)

Both fixed cases expose columnheader "Course", columnheader "Instructor" and columnheader "Room"
Case 2: the three rowheader nodes from the broken version are columnheader again; data rows unchanged
Case 1: the tree is identical to broken Case 1. Chrome shows no Scope property for scope="col" (live capture 2026-06-15). For missing versus correct scope, read the markup.

What VoiceOver announced (fixed)

Case 1:

table, 3 columns, 4 rows

Course, column 1 of 3

Contrast broken Case 1, where the same header read Course Course, column 1 of 3.

Course Intro to WAS, column 1 of 3

You are currently on a selectable text, inside of a cell.

To be honest about the evidence: Instructor Instructor, column 2 of 3 and Room Room, column 3 of 3 still double on the fixed table, so the doubling is not a reliable pass or fail signal.

Case 2:

table, 3 columns, 4 rows

You are currently on a selectable text, inside of a column header.

Behaviors to verify

Every header cell is a <th>, not a styled <td>, and its text describes the data it labels.
Every column header has scope="col"; every row header has scope="row"; no scope="row" sits on column labels in thead.
In the accessibility tree, column labels are columnheader and row labels are rowheader. Then move through a data row with a screen reader and confirm each cell is read with the right header. Do not trust your ears alone.

Practice it

Video: https://youtu.be/cTSw8wnJwcM
Short: https://youtube.com/shorts/y65zZN_R23k
Lab: Table Headers lab
Companion write-up: https://www.wasexamprep.com/blog/table-without-headers-is-a-grid-of-words

Takeaway: a table without declared headers is just a grid of words. Put scope on every th, and check the tree, not just your ears.

If this was useful, subscribe to A11Y in Practice on YouTube (@a11yinpractice) for more hands-on accessibility episodes, and visit wasexamprep.com for WAS study notes and labs.

A11Y in Practice and wasexamprep.com are independent educational resources. They are not affiliated with or endorsed by IAAP (International Association of Accessibility Professionals).

A Skip Link That Doesn't Land Is Not a Bypass: WCAG 2.4.1 in Practice

A11Y Practice — Wed, 14 Oct 2026 11:29:55 +0000

You press Tab on a page and VoiceOver says link, Home, Primary, navigation. Not the content. On a real site that header can hold dozens of links, and keyboard and screen reader users have to tab through it on every page load. Add a skip link and the problem looks solved. But if its href points at an id that doesn't exist, activation goes nowhere.

WCAG 2.4.1 Bypass Blocks (Level A) requires a way to skip blocks of content that repeat across pages. A skip link only counts if it actually moves the user past the repeated block.

Two ways it breaks

No skip link. The first focusable node is link "Home" inside navigation "Primary". You only reach main after every nav link. There's no mechanism at all.
Skip link with a mismatched target. This one looks fixed. The link is first in Tab order and visible on focus, and VoiceOver announces it correctly: visited, link, Skip to main content. But the code looks like this:

<a href="#main">Skip to main content</a>
<header>Study Lab</header>
<nav aria-label="Primary">…</nav>
<main id="skip-to-content-broken-case2-main">…</main>

There's no element with id="main". After activation, focus is still inside the navigation. The problem isn't what the link says. It's where it goes, and you only see that in the accessibility tree, not in the announcement.

Auditors test activation, not presence: press Enter and check where focus goes. Landmarks like nav and main help screen reader users, but sighted keyboard users have no landmark shortcut, so a broken skip link is still a defect.

The fix

Make the skip link the first focusable element, make its href fragment match a real id, and give the target tabindex="-1" so it can take programmatic focus:

<a class="skip-link" href="#main-content">Skip to main content</a>
<header>…</header>
<nav aria-label="Primary">…</nav>
<main id="main-content" tabindex="-1">…</main>

In React/JSX that's tabIndex={-1}. -1 lets main take focus from script or fragment navigation without adding it to the Tab order.

Hide it until it's focused:

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
  z-index: 1000;
}

Behaviors to verify

The first Tab on the page reaches the skip link, and it's visible when focused.
Pressing Enter moves focus into the main content, so the next thing read is content, not navigation.
The href fragment matches an id that exists exactly once, and the target has tabindex="-1". Check it in the accessibility tree and with a screen reader before shipping.

Practice it

Video: https://youtu.be/uuevKPHlgDk
Short: https://youtube.com/shorts/gnGrnoXHhCI
Companion write-up: https://www.wasexamprep.com/blog/skip-link-is-not-a-bypass

Takeaway: a skip link that doesn't land is not a bypass. Test activation, not presence.

If this was useful, subscribe to A11Y in Practice on YouTube (@a11yinpractice) for more hands-on accessibility episodes, and visit wasexamprep.com for WAS study notes and labs.

A11Y in Practice and wasexamprep.com are independent educational resources. They are not affiliated with or endorsed by IAAP (International Association of Accessibility Professionals).

A Custom Div Is Not a Checkbox: WCAG 4.1.2 Name, Role, Value

A11Y Practice — Wed, 07 Oct 2026 08:05:22 +0000

You build a toggle that looks like a checkbox. You style two shipping options as buttons. Sighted users get it. Then you open VoiceOver.

On the custom toggle, from a real capture: Email notifications (custom) - and the hint: you are currently on a button, group. No checkbox role. No checked state. Beside it, the native control announces as a checkbox. Same job. Completely different exposure.

WCAG 4.1.2 Name, Role, Value says the role and value must be programmatically determinable. Native checkbox, radio, and fieldset give you that for free. A click-only div or plain buttons that fake selection fail 4.1.2 - missing roles, missing value.

Why this trips people up

Two failure patterns show up a lot:

Custom "checkbox" with no widget role - a clickable div that looks finished. In the accessibility tree you may only get StaticText. Tab can skip it entirely.
Buttons faking a radio group - sibling buttons with no radiogroup parent and no "1 of 2" / "2 of 2". They look like a choice group. VoiceOver hears two independent buttons.

What to do instead

Prefer native checkbox / radio / fieldset when you can
When you must build custom: role="checkbox" + focusability + aria-checked, or role="radiogroup" with role="radio" on each option
Extra ARIA is not the goal - the correct widget roles are. Then verify with a screen reader

Practice it

I published a walkthrough on A11Y in Practice with broken vs fixed paths on the same free lab:

Part of WAS Exam Prep / WAS Lab study notes (independent; not affiliated with IAAP or W3C).

Takeaway: a custom div that looks like a checkbox is not a checkbox until assistive tech gets the role and value - prefer native HTML when you can.

Static Text Is Not a Status Message: WCAG 4.1.3 Live Regions

A11Y Practice — Wed, 30 Sep 2026 17:03:24 +0000

You click Add item. The cart count ticks from zero to one. You click Save. The status flips to Saved. Sighted users see it instantly. On that button with VoiceOver, what do you hear?

Often: still the button hint - and nothing about the cart or Saved. Static text on the page is not a status message.

WCAG 4.1.3 Status Messages is about announcing that kind of update without moving focus.

Why this trips people up

Two failure patterns show up a lot:

No live region at all - the DOM updates, the screen updates, assistive tech stays quiet.
The trap - aria-live (or role="status") is on a wrapper, but the changing text sits outside that node. The live region never sees a relevant update.

What to put on the changing node

aria-live="polite" and/or role="status" on the element whose text content actually changes
Prefer polite for non-urgent cart/status UI; keep assertive for rare urgent cases
Do not assume "I added aria-live somewhere nearby" is enough - verify with a screen reader

Practice it

I published a walkthrough on A11Y in Practice with broken vs fixed paths on the same free lab:

Part of WAS Exam Prep / WAS Lab study notes (independent; not affiliated with IAAP or W3C).

Takeaway: put the live region on the changing text node, not on a silent wrapper.

Focusable Is Not Keyboard-Operable: WCAG 2.1.1 on Custom Controls

A11Y Practice — Thu, 24 Sep 2026 05:20:33 +0000

You Tab to a custom checkbox. The focus ring shows up. You press Space - nothing. Click with the mouse and it toggles.

So is it accessible?

WCAG 2.1.1 Keyboard says the functionality must be available from a keyboard. Landing focus on the control is not enough.

Why tools miss it

In the broken lab case, the accessibility tree still exposes a checkbox with the right name and checked state. VoiceOver can announce it like a normal checkbox. The gap is the missing key handler (onClick only).

Same story for a custom radiogroup where every option has tabIndex={0} and arrow keys do nothing: the tree looks mostly fine; keyboard testing does not.

What to verify manually

Checkbox / switch: Space toggles
Radiogroup: arrows move selection; preferably one tab stop (roving tabindex)
Do not trust "focusable + role" alone

Practice it

I published a walkthrough on A11Y in Practice with broken vs fixed paths on the same free lab:

Part of WAS Exam Prep / WAS Lab study notes (independent; not affiliated with IAAP or W3C).

If this helped, the takeaway I keep repeating: roles name the widget. Keys make it usable.

DEV Community: A11Y Practice

Test Your Tabs: One Tab Stop, Arrow Keys, a Focusable Panel and No Up/Down

The contract

Testing Library + user-event

Playwright, against a real browser

Common mistakes

VoiceOver, from real captures only

Keep practicing

aria-selected on tabs: the selected tab that lies (WCAG 4.1.2)

The problem

Case 1 - role="tab" with no aria-selected

What VoiceOver announced (broken, Case 1)

What the accessibility tree showed (broken, Case 1)

Case 2 - aria-selected hard-coded

What VoiceOver announced (broken, Case 2)

What the accessibility tree showed (broken, Case 2)

Why this fails exam-style

The fix

What changed in the tree (fixed)

What VoiceOver announced (fixed)

Behaviors to verify

Practice it

th scope row vs col: table headers that sound fine but are wrong (WCAG 1.3.1)

The problem

Case 1 - <th> without scope

What the accessibility tree showed (broken)

What VoiceOver announced (broken)

Inferred, not declared

Case 2 - scope="row" on column headers

What the accessibility tree showed (broken, Case 2)

What VoiceOver announced (broken, Case 2)

Why this fails exam-style

The fix

What changed in the tree (fixed)

What VoiceOver announced (fixed)

Behaviors to verify

Practice it

A Skip Link That Doesn't Land Is Not a Bypass: WCAG 2.4.1 in Practice

Two ways it breaks

The fix

Behaviors to verify

Practice it

A Custom Div Is Not a Checkbox: WCAG 4.1.2 Name, Role, Value

Why this trips people up

What to do instead

Practice it

Static Text Is Not a Status Message: WCAG 4.1.3 Live Regions

Why this trips people up

What to put on the changing node

Practice it

Focusable Is Not Keyboard-Operable: WCAG 2.1.1 on Custom Controls

Why tools miss it

What to verify manually

Practice it

Case 1 - `role="tab"` with no `aria-selected`

Case 2 - `aria-selected` hard-coded

Case 1 - `<th>` without `scope`

Case 2 - `scope="row"` on column headers