Challenge 3: Apply the Methodology to a New Page — Possible Solution
====================================================================

SCENARIO: A SaaS dashboard with a data table, a settings form, and a
notification bell icon.

STEP 1 — AUTOMATED SCAN FIRST
----------------------------------
Run axe/Lighthouse to catch the easy, mechanically-detectable issues
first — likely candidates given this page's content: missing labels on
settings form fields, insufficient contrast on table text or the bell
icon, and a missing accessible name if the bell is icon-only.

STEP 2 — FIX SEMANTIC HTML & ARIA
--------------------------------------
Check that the data table uses real <table>/<th>/<td> markup (not a
div-based grid layout) so column/row relationships are actually
programmatically available — a data table is a strong candidate for
this exact div-vs-semantic-element problem. Check the notification bell
isn't a div with onclick, and if it's icon-only, it needs Chapter 3's
aria-label pattern (e.g. aria-label="Notifications") rather than no
accessible name at all.

STEP 3 — FIX KEYBOARD NAVIGATION
-------------------------------------
A data-heavy dashboard likely has many interactive elements (sortable
column headers, row actions, filters) — verify tab order matches visual
layout (Chapter 4's DOM-order point is especially relevant for a
grid/table layout, which commonly uses CSS positioning that can
decouple visual and source order), and check for any outline: none with
no :focus-visible replacement, a very common oversight in dashboard UI
kits.

STEP 4 — FIX FORMS
-----------------------
The settings form specifically needs Chapter 5's treatment: real
<label> elements for every field (not placeholder-only), fieldset/
legend if any settings are grouped (e.g. a set of related toggle
options), and aria-invalid/aria-describedby wiring for any validation
errors on save.

STEP 5 — FIX VISUAL DESIGN
-------------------------------
Check the data table specifically for color-only status encoding (a
common dashboard pattern — e.g. red/green row highlighting for
pass/fail state) and add a text or icon alternative per Chapter 6;
verify contrast on both the table's data text and any settings-form
labels/inputs.

STEP 6 — FIX SCREEN-READER-SPECIFIC ISSUES
------------------------------------------------
If the notification bell shows a live count that updates dynamically
(e.g. "3 unread"), that update should use aria-live="polite" (Chapter
7) rather than assertive, since a routine notification-count change
isn't urgent enough to justify interrupting whatever the user is
currently doing.

STEP 7 — FIX CUSTOM COMPONENTS
-----------------------------------
If the dashboard has any custom widgets — a dropdown filter menu on
the data table, or a tabbed settings panel — verify each has the FULL
keyboard model from Chapter 8 (roving tabindex for tabs, proper
aria-activedescendant for any custom dropdown/combobox), not just the
ARIA roles alone.

STEP 8 — MANUAL RE-TEST WITH A REAL SCREEN READER
-------------------------------------------------------
Navigate the actual data table, settings form, and notification bell
with VoiceOver or NVDA to confirm reading order through the table makes
sense, the settings form's error handling is genuinely announced
correctly, and the bell's live-region update doesn't feel disruptive in
real, continuous use.

WHY THIS WORKS AS AN ANSWER
------------------------------
The METHODOLOGY itself transfers directly to a completely different
page with completely different specific content — exactly as the
chapter's own concept card describes it: "not specific to this one
page... a repeatable process for auditing any real page." The SPECIFIC
techniques applied at each step differ (table semantics instead of
button semantics, a bell icon's aria-label instead of a wishlist link's
redundant role), but the ORDER and underlying reasoning for that order
stay identical to this capstone's own worked example.