--- A00 Change Request Specification - Page 9 Accessibility And Semantic Edge Cases --- Create one standalone HTML demo page named `page-09-accessibility-and-semantic-edge-cases.html`. The page must be a self-contained HTML file. Put all HTML, CSS, and JavaScript inside this one file. Do not use React. Do not use TypeScript. Do not use a build step. Do not load external CSS, external JavaScript, external fonts, external images, external icon sets, external accessibility libraries, external data, or external APIs. The page must work by opening the `.html` file directly in a browser. This page is a testing surface for a content extraction tool. The page must focus on accessibility and semantic edge cases: accessible names, ARIA labels, visually hidden text, `aria-describedby`, `aria-labelledby`, fieldsets, legends, custom controls, role-based widgets, tab panels, accordions, dialogs, listboxes, comboboxes, tree views, live regions, status messages, error summaries, landmark regions, icon-only buttons, duplicated visible and accessible labels, semantic tables, non-semantic visual layouts, hidden text, disabled controls, readonly values, and mixed good and bad semantics that appear on real web pages. The page must contain exactly 25 separate examples. Each example must have a visible heading, a visible explanatory paragraph, and the actual accessibility or semantic edge case UI. Each example must be visually separated from the next example. Each example must be realistic enough to test extraction of visible values, accessible names, hidden descriptive text, field group context, state, selected options, expanded or collapsed panels, active tab state, live status text, error messages, semantic table relationships, and widget relationships. Do not make the examples into small isolated accessibility snippets only. Each example should look like a believable product surface. The examples should include surrounding context, related fields, repeated labels, and multiple extractable values. The purpose is to test whether the extraction tool can use semantic hints without losing visible context, and can use visible grouping without being misled by incomplete or unusual semantics. --- B00 Page-Level Purpose --- The purpose of this page is to test whether an extraction tool can identify, select, and format structured information from web content where accessibility semantics strongly affect meaning. The extraction tool should be able to handle visible labels, accessible labels, hidden labels, duplicated labels, descriptions, error text, invalid states, required states, disabled states, readonly states, expanded states, selected states, active descendant relationships, aria-owned or aria-controlled popups, tab panels, accordions, dialogs, live regions, landmarks, fieldsets, semantic tables, ARIA grids, custom widgets, and intentionally imperfect real-world markup. This page should not be a pure accessibility best-practices showcase. It should include realistic edge cases. Some examples should be well-structured and semantic. Some examples should be messy but still understandable. Some examples should intentionally contain imperfect semantics that often occur in production, such as a visible label that differs from an `aria-label`, a button with only an accessible name, a card that looks selected but lacks `aria-selected`, a tooltip used as a description, or a custom combobox with a portaled listbox. The page should not require a screen reader, accessibility testing extension, browser dev tools, or network access. All relevant values must be present in the DOM. Some values may be visually hidden, but the page must still expose enough visible content for manual testing. --- C00 Required Page Structure --- The page must start with a top-level header. Use this visible title: `Page 9 - Accessibility And Semantic Edge Cases` Under the title, include a short introduction paragraph explaining that the page contains realistic accessibility and semantic edge cases for testing extraction of accessible names, visible labels, descriptions, states, grouped fields, custom widgets, landmarks, live messages, semantic tables, and ARIA relationships. After the introduction, render 25 example sections. Each example section must follow this pattern: ```html

Example 01

Checkout Form With Accessible Descriptions And Error Summary

This example imitates...

``` The exact class names may vary, but the structure must remain clear. Each section must have a unique `id`, from `example-01` through `example-25`. Each example heading must be visible. Each description must be visible. The actual UI surface must appear below the description. Do not include large expected extraction output blocks under every example. The page should primarily be the application-under-test surface, not a documentation page. The visible descriptions should explain the purpose and caveat of each example. --- D00 Visual Design Requirements --- Use inline CSS in a ` ``` The coding agent may adjust the CSS, but it must keep the page readable, scrollable, and visually divided into 25 separate examples. --- E00 JavaScript Requirements --- Use inline JavaScript in a ` ``` The coding agent may extend this code for specific examples, but the final file must remain simple and portable. --- F00 Accessibility And Semantic Edge Case Rules --- Use accessible semantics deliberately. Each example must include at least one explicit accessibility or semantic feature, such as `aria-label`, `aria-labelledby`, `aria-describedby`, `aria-expanded`, `aria-controls`, `aria-selected`, `aria-current`, `aria-invalid`, `aria-live`, `role`, `fieldset`, `legend`, `caption`, `scope`, `headers`, `dialog`, `tablist`, `tree`, `grid`, `combobox`, `listbox`, `menu`, `switch`, or visually hidden text. Do not make every example perfectly semantic. Include realistic edge cases. Some examples should have visible text that differs from the accessible name. Some should have hidden text that adds context. Some should have labels that are far from controls. Some should use ARIA roles for custom controls. Some should intentionally include a warning in the description that the markup is a realistic imperfect pattern. Do not intentionally create harmful or completely unusable accessibility failures. The page should be testable. The point is edge cases, not broken pages. All values needed for extraction should be present in visible text, accessible text, or ordinary DOM text. Do not store important values only inside JavaScript variables, comments, CSS pseudo-elements, or data attributes. When using visually hidden text, use the `.sr-only` class. Do not hide critical values only with CSS unless the example is explicitly about hidden accessible names or descriptions. When using ARIA states, make the visual state and ARIA state match unless the example is explicitly about a mismatch. If a mismatch is intentional, state that in the visible example description. When using native HTML semantics, use them correctly: `fieldset` with `legend`, tables with `caption` and headers, buttons for buttons, anchors for navigation, and labels for inputs. --- G00 Extraction Behavior To Support --- The page must make these extraction tasks possible: Extract visible labels and values. Extract accessible names from `aria-label`, `aria-labelledby`, visible labels, and visually hidden text. Extract descriptions from `aria-describedby`, help text, tooltip text, error text, and warning text. Extract invalid, required, disabled, readonly, selected, checked, expanded, current, active, and hidden states. Extract grouped form values from fieldsets and legends. Extract selected options from native and custom widgets. Extract active tab state and currently visible tab panel content. Extract expanded accordion content and collapsed accordion summaries. Extract combobox trigger value, selected option, active descendant, listbox options, and backing hidden values. Extract menu item labels and checked menu states while preserving the trigger context. Extract dialog title, description, form fields, and background page summary separately. Extract semantic table headers and row values. Extract ARIA grid rows and cells even when not native tables. Extract treeview hierarchy with expanded and selected nodes. Extract live region messages when visible in the DOM. Extract visually hidden text when it forms part of the accessible name, but avoid duplicating it when it repeats visible text. Extract duplicate labels by using group names and semantic context. Extract landmark regions and nested section headings. Extract mismatch cases without blindly trusting either visible or accessible text only. --- H00 Data And Naming Rules --- Use realistic but fictional data. Do not use real personal information. Use fictional companies, fictional patients, fictional students, fictional accounts, fictional tickets, fictional order numbers, fictional users, fictional IDs, and example-domain email addresses. Use `href="#"` or `href="/demo/..."` for links. Do not link to real third-party pages. Use consistent example-specific IDs. Prefix IDs with the example number, such as `ex01-email`, `ex07-tab-billing`, or `ex21-calendar-grid`. Use plausible values. Avoid placeholder-only examples. Every example should contain enough populated data to be useful for extraction testing. Use a mixture of native semantics and ARIA semantics. Do not overuse ARIA when a native control is sufficient unless the example is specifically about custom widgets. Do not use external images. If an image-like region is needed, use a text placeholder and make the accessible name explicit. Do not make all examples look the same. Use product-like surfaces, admin-like surfaces, patient portal surfaces, ecommerce surfaces, data tables, mobile panels, nested widgets, and document-like layouts. --- I00 Required Examples Overview --- The page must contain exactly these 25 examples: Example 01: Checkout Form With Accessible Descriptions And Error Summary. Example 02: Icon-Only Actions With Hidden Accessible Names. Example 03: Portaled Combobox With Active Descendant. Example 04: Radio Card Group With Mixed Native And ARIA State. Example 05: Tabbed Account Settings With Duplicate Panel Labels. Example 06: Accordion Details With Collapsed Summaries. Example 07: Error Summary Linking To Invalid Fields. Example 08: Live Region Notifications And Status Updates. Example 09: Semantic Data Table With Multi-Level Headers. Example 10: Landmark Layout With Repeated Navigation Names. Example 11: Modal Dialog With Background Context. Example 12: Tree View File Browser With Expanded Nodes. Example 13: Menu Button With Checked Menu Items. Example 14: Range Slider And Meter With Accessible Value Text. Example 15: Checkout Stepper With Current Step And Completed Steps. Example 16: Sortable List With Accessible Drag Handles. Example 17: Tokenized Multi-Select With Hidden Input Values. Example 18: Visually Hidden Text In Search Results. Example 19: Tooltip And Description Relationship Edge Cases. Example 20: Data Visualization With Text Equivalent. Example 21: Calendar Date Picker Grid With Availability Semantics. Example 22: Permission Matrix With Headers And Group Labels. Example 23: Fieldset And Legend Grouping In Complex Forms. Example 24: Search Result Cards With Accessible Name Mismatches. Example 25: Mixed Semantic Anti-Pattern Gallery. Each example below is mandatory. --- J00 Example 01 - Checkout Form With Accessible Descriptions And Error Summary --- Create a checkout contact and delivery form that uses native labels, `aria-describedby`, required fields, invalid states, helper text, and a visible error summary. The form should look like a real checkout step. Visible heading: `Checkout Form With Accessible Descriptions And Error Summary` Visible description: `This example imitates a checkout form where accessible descriptions, visible helper text, and error messages provide important extraction context. It tests extraction of labels, values, required state, invalid state, error text, and field group context.` Form header: `Checkout step`: `Delivery details`. `Cart ID`: `CART-2026-44018`. `Step status`: badge `Needs attention`. Error summary panel: Use `role="alert"` or `aria-live="assertive"`. Visible title: `There are 2 problems with your delivery details`. Error links: `Delivery phone number must include an area code`, links to `Delivery phone`. `Delivery instructions are too long`, links to `Delivery instructions`. Contact field group using `fieldset` and `legend`: Legend: `Contact information`. Fields: `Full name`: input value `Jordan Ellis`, required. `Email address`: input value `jordan.ellis@example.test`, required, `aria-describedby` pointing to helper text `We will send your receipt and delivery updates here.` `Delivery phone`: input value `555-0184`, required, `aria-invalid="true"`, `aria-describedby` pointing to both helper text and error text. Delivery field group: Legend: `Delivery address`. Fields: `Street address`: input value `120 King Street`. `Dock or suite`: input value `Dock B`. `City`: input value `San Francisco`. `State`: select selected `CA`. `ZIP code`: input value `94107`. `Delivery instructions`: textarea value `Use freight entrance on King Street. Please call before unloading. Leave packages with dock supervisor if I am away. This note is intentionally long for validation testing.`, `aria-invalid="true"`, `aria-describedby` pointing to error text. Order summary sidebar: `Items`: `4`. `Delivery method`: `Standard ground`. `Estimated delivery`: `June 6-9, 2026`. `Delivery status`: badge `Blocked by form errors`. Extraction caveat: the extraction tool should include both the field value and its validation context. It should not extract the error summary as unrelated links only. It should preserve that the phone and delivery instructions fields are invalid. Implementation guidance: ```html

Delivery details

Contact information

We will send your receipt and delivery updates here.

Use a phone number where the driver can reach you.

Delivery phone number must include an area code.

``` --- K00 Example 02 - Icon-Only Actions With Hidden Accessible Names --- Create a compact account toolbar and card list with icon-only buttons. Use visible symbols or single-letter glyphs, but provide full accessible names with `aria-label` and `.sr-only` text. Visible heading: `Icon-Only Actions With Hidden Accessible Names` Visible description: `This example imitates a dense admin toolbar that uses icon-only action buttons. It tests extraction of action meanings from accessible names without treating the visible symbols as the only labels.` Account header: `Account`: `Atlas Product Studio`. `Workspace ID`: `ws_9A41Q`. `Plan`: `Business annual`. `Status`: badge `Active`. Toolbar icon buttons: Button visible text: `+`, `aria-label`: `Add new workspace member`. Button visible text: `↓`, `aria-label`: `Download billing report`. Button visible text: `?`, `aria-label`: `Open help for workspace settings`. Button visible text: `...`, `aria-label`: `Open workspace actions menu`. Three member cards: Member 1: `Name`: `Maya Chen`. `Email`: `maya.chen@example.test`. `Role`: `Admin`. `Status`: badge `Active`. Icon-only row actions: Visible `✎`, `aria-label`: `Edit Maya Chen`. Visible `×`, `aria-label`: `Remove Maya Chen from workspace`. Member 2: `Name`: `Rafael Ortiz`. `Email`: `rafael.ortiz@example.test`. `Role`: `Editor`. `Status`: badge `Active`. Icon-only row actions: Visible `✎`, `aria-label`: `Edit Rafael Ortiz`. Visible `×`, `aria-label`: `Remove Rafael Ortiz from workspace`. Member 3: `Name`: `Lina Romero`. `Email`: `lina.romero@example.test`. `Role`: `Viewer`. `Status`: badge `Invited`. Icon-only row actions: Visible `✎`, `aria-label`: `Edit Lina Romero`. Visible `↻`, `aria-label`: `Resend invite to Lina Romero`. Extraction caveat: the extraction tool should capture the accessible button names as action labels. It should not output only `+`, `↓`, `?`, `...`, `✎`, `×`, or `↻` as meaningless actions. Implementation guidance: use actual button elements and set `aria-label` on each icon button. It is acceptable to include `.sr-only` text inside buttons as an additional test, but do not duplicate both in extraction unless needed. --- L00 Example 03 - Portaled Combobox With Active Descendant --- Create a custom destination search combobox that visually appears in a travel form while its listbox appears later in the DOM, imitating a portaled popup. Use `aria-controls`, `aria-expanded`, `aria-activedescendant`, and `role="listbox"`. Visible heading: `Portaled Combobox With Active Descendant` Visible description: `This example imitates a custom travel destination combobox whose popup listbox is rendered outside the form container. It tests extraction of the combobox label, typed value, active descendant, selected option, hidden submitted value, and portaled option list.` Travel form panel: `Search type`: `Hotel destination`. `Destination label`: visible label `Destination city or hotel`. Combobox trigger input: `Visible typed value`: `Monterey`. `role`: `combobox`. `aria-expanded`: `true`. `aria-controls`: points to the portaled listbox. `aria-activedescendant`: points to option `Monterey, CA`. Hidden backing input: `name`: `destinationId`. `value`: `city_monterey_ca`. Other fields in the travel form: `Check-in`: `2026-08-14`. `Check-out`: `2026-08-18`. `Guests`: `2 adults, 1 child`. Portaled listbox panel placed after the form, visually aligned but in a separate DOM area: Option 1: `Visible text`: `Monterey, CA`. `Supporting text`: `City - 31 stays`. `Value ID`: `city_monterey_ca`. `aria-selected`: `true`. Option 2: `Visible text`: `Monterey Bay Aquarium Area`. `Supporting text`: `Neighborhood - 12 stays`. `Value ID`: `area_monterey_aquarium`. `aria-selected`: `false`. Option 3: `Visible text`: `Harbor View Suites`. `Supporting text`: `Hotel - Monterey waterfront`. `Value ID`: `hotel_harbor_view_suites`. `aria-selected`: `false`. Option 4: `Visible text`: `Pacific Grove, CA`. `Supporting text`: `Nearby city - 18 stays`. `Value ID`: `city_pacific_grove_ca`. `aria-selected`: `false`. Search summary sidebar: `Selected destination`: `Monterey, CA`. `Submitted destination ID`: `city_monterey_ca`. `Available stays`: `31`. Extraction caveat: the extraction tool should connect the combobox input to the portaled listbox using ARIA relationships and visible context. It should not treat the listbox as an unrelated list just because it appears outside the form DOM subtree. Implementation guidance: place the listbox outside the immediate form panel. Use IDs that clearly link `aria-controls` and `aria-activedescendant`. --- M00 Example 04 - Radio Card Group With Mixed Native And ARIA State --- Create a shipping option selector using large visual cards. Include hidden native radio inputs for some cards and ARIA radio roles for others to test mixed implementation patterns. Visible heading: `Radio Card Group With Mixed Native And ARIA State` Visible description: `This example imitates a shipping option selector built from large selectable cards. It tests extraction of selected option, visible card text, native checked state, ARIA checked state, disabled option state, price, delivery date, and policy notes.` Group heading: `Choose a delivery method`. Group accessible name should use a visible heading or `fieldset` and `legend`. Card 1: `Option`: `Standard ground`. `Delivery estimate`: `June 6-9, 2026`. `Price`: `$8.95`. `Status`: `Available`. `Implementation`: native radio input checked. `Selected`: yes. Card 2: `Option`: `Expedited`. `Delivery estimate`: `June 4-5, 2026`. `Price`: `$22.00`. `Status`: `Available`. `Implementation`: native radio input unchecked. `Selected`: no. Card 3: `Option`: `Freight dock delivery`. `Delivery estimate`: `June 7-10, 2026`. `Price`: `$48.00`. `Status`: `Requires dock access`. `Implementation`: custom `role="radio"` and `aria-checked="false"`. `Selected`: no. Card 4: `Option`: `Same day courier`. `Delivery estimate`: `Today by 8:00 PM`. `Price`: `$62.00`. `Status`: `Unavailable for this address`. `Implementation`: custom `role="radio"`, `aria-checked="false"`, `aria-disabled="true"`. `Selected`: no. Order sidebar: `Selected method`: `Standard ground`. `Selected price`: `$8.95`. `Delivery status`: badge `Ready`. Extraction caveat: the extraction tool should identify the selected card even though the group mixes native and ARIA radio implementations. It should not treat unavailable same-day courier as selected. Implementation guidance: make cards look visually similar even though their implementations differ. This is intentional. --- N00 Example 05 - Tabbed Account Settings With Duplicate Panel Labels --- Create a tabbed account settings interface with three tabs. Each tab panel must contain repeated labels such as `Status`, `Owner`, `Last updated`, and `Notes`. Visible heading: `Tabbed Account Settings With Duplicate Panel Labels` Visible description: `This example imitates account settings with ARIA tabs and repeated labels inside each tab panel. It tests extraction of active tab state and visible tab panel content while preserving panel context.` Account header: `Workspace`: `Northwind Analytics`. `Workspace ID`: `ws_9A41Q`. `Settings status`: badge `Changes unsaved`. Tab list: Tab 1: `Visible label`: `Billing`. `role`: `tab`. `aria-selected`: `true`. `aria-controls`: billing panel. Tab 2: `Visible label`: `Security`. `aria-selected`: `false`. Tab 3: `Visible label`: `Notifications`. `aria-selected`: `false`. Billing panel visible by default: `Panel heading`: `Billing settings`. `Status`: badge `Configured`. `Owner`: `Renee Coleman`. `Last updated`: `May 30, 2026, 4:12 PM`. `Invoice recipients`: `billing@example.test`, `finance@example.test`. `Notes`: `Purchase order required for renewals over $5,000.` Security panel hidden by default: `Panel heading`: `Security settings`. `Status`: badge `Enforced`. `Owner`: `Anika Sharma`. `Last updated`: `May 28, 2026, 1:20 PM`. `MFA requirement`: `Required for admins`. `Notes`: `SCIM and SAML are enabled.` Notifications panel hidden by default: `Panel heading`: `Notification settings`. `Status`: badge `Partially configured`. `Owner`: `Grace Miller`. `Last updated`: `May 22, 2026, 9:18 AM`. `Digest frequency`: `Daily`. `Notes`: `Slack alerts are not configured.` Extraction caveat: the extraction tool should capture the active tab and visible panel content by default. If the tester activates another tab, extraction should preserve which tab panel the repeated labels belong to. Implementation guidance: implement tabs with `role="tablist"`, `role="tab"`, and `role="tabpanel"`. Use JavaScript to switch visible panels. --- O00 Example 06 - Accordion Details With Collapsed Summaries --- Create an accordion-based subscription settings page. Some sections should be expanded and some collapsed. Collapsed sections should still show a visible summary row. Visible heading: `Accordion Details With Collapsed Summaries` Visible description: `This example imitates a settings page with accordion sections. It tests extraction of expanded content, collapsed summaries, aria-expanded state, and repeated labels inside each section.` Page header: `Account`: `Atlas Product Studio`. `Plan`: `Business annual`. `Settings status`: badge `Review recommended`. Accordion sections: Section 1 expanded by default: Button text: `Billing contacts`. `aria-expanded`: `true`. Visible expanded content: `Status`: badge `Configured`. `Primary contact`: `Renee Coleman`. `Invoice email`: `billing@example.test`. `Backup email`: `finance@example.test`. `Last updated`: `May 30, 2026`. Section 2 collapsed by default: Button text: `Payment method`. `aria-expanded`: `false`. Collapsed summary visible: `Summary`: `Visa ending in 4242, expires 08/2028`. Hidden expanded content: `Status`: badge `Active`. `Cardholder`: `Jordan Ellis`. `Billing ZIP`: `94103`. `Last verified`: `May 18, 2026`. Section 3 expanded by default: Button text: `Renewal settings`. `aria-expanded`: `true`. Visible expanded content: `Status`: badge `Auto-renew enabled`. `Renewal date`: `January 18, 2027`. `Renewal amount`: `$5,760.00`. `Purchase order required`: `Yes`. Section 4 collapsed by default: Button text: `Cancellation terms`. `aria-expanded`: `false`. Collapsed summary visible: `Summary`: `Notice required 30 days before renewal`. Hidden expanded content: `Notice deadline`: `December 19, 2026`. `Early cancellation`: `Not available for annual plan`. `Notes`: `Contact billing support for exceptions.` Extraction caveat: the extraction tool should extract visible collapsed summaries but should not extract hidden details unless the tester expands the accordion before selection. Implementation guidance: use buttons with `aria-controls` and `aria-expanded`. Hidden panels should use the `hidden` attribute. --- P00 Example 07 - Error Summary Linking To Invalid Fields --- Create a multi-section profile form with an error summary at the top. The invalid fields should be in different visual groups, and the error summary should link to them. Visible heading: `Error Summary Linking To Invalid Fields` Visible description: `This example imitates a profile update form with validation errors spread across multiple sections. It tests extraction of error summary items, invalid fields, field values, aria-invalid state, and error-to-field relationships.` Header: `Profile`: `Contractor onboarding`. `User`: `Samira Haddad`. `Form status`: badge `Cannot submit`. Error summary: Use `role="alert"` and visible heading `Fix 3 fields before continuing`. Errors: `Legal name is required`. `Start date must be after today`. `Emergency contact phone must include country code`. Section `Identity`. Fields: `Legal name`: empty input, required, `aria-invalid="true"`, error `Legal name is required`. `Preferred name`: input value `Samira`. `Email`: readonly input value `samira.haddad@example.test`. Section `Contract`. Fields: `Role`: input value `Accessibility reviewer`. `Start date`: input type date value `2026-05-15`, `aria-invalid="true"`, error `Start date must be after today`. `End date`: input type date value `2026-08-15`. Section `Emergency Contact`. Fields: `Contact name`: input value `Leila Haddad`. `Relationship`: select selected `Sibling`. `Emergency contact phone`: input value `415-555-0180`, `aria-invalid="true"`, error `Emergency contact phone must include country code`. Side summary: `Required fields completed`: `6 of 9`. `Validation status`: badge `3 errors`. Extraction caveat: the extraction tool should preserve error summary links and field-level error messages without duplicating them as unrelated notes. Implementation guidance: each error summary link should point to the invalid field ID. Each invalid field should use `aria-describedby` to include the error text ID. --- Q00 Example 08 - Live Region Notifications And Status Updates --- Create a notification center with live regions that update status messages. Include visible current status and a live region area. Visible heading: `Live Region Notifications And Status Updates` Visible description: `This example imitates an admin page that uses live regions for save, sync, and export status messages. It tests extraction of current visible status, live region text, notification records, and action-triggered updates.` Header: `Workspace`: `Northstar Research Lab`. `Page`: `Export jobs`. `Overall status`: badge `2 jobs running`. Live status region: Use `role="status"` or `aria-live="polite"`. Initial visible text: `Last update: Export job EXP-2026-1842 is running. 42 percent complete.` Action buttons: `Refresh status`, with `data-live-message`: `Status refreshed. Export job EXP-2026-1842 is 58 percent complete.` `Start CSV export`, with `data-live-message`: `CSV export started for invoice line items.` `Cancel export`, with `data-live-message`: `Export cancellation requested for EXP-2026-1842.` Notification list: Notification 1: `Type`: `Export`. `Job ID`: `EXP-2026-1842`. `Status`: badge `Running`. `Progress`: `42 percent`. `Started`: `May 31, 2026, 11:40 AM`. Notification 2: `Type`: `Webhook`. `Job ID`: `WEB-2026-7710`. `Status`: badge `Failed`. `Progress`: `Stopped`. `Started`: `May 31, 2026, 10:52 AM`. `Error`: `Endpoint returned 503`. Notification 3: `Type`: `Report`. `Job ID`: `RPT-2026-1190`. `Status`: badge `Complete`. `Progress`: `100 percent`. `Started`: `May 31, 2026, 9:00 AM`. `Completed`: `May 31, 2026, 9:04 AM`. Extraction caveat: the extraction tool should capture visible live region content when selected. It should not assume button labels are the current status. If a tester clicks a live update button, the live region text should change in the DOM. Implementation guidance: connect `data-live-target` buttons to a visible live region. --- R00 Example 09 - Semantic Data Table With Multi-Level Headers --- Create a financial comparison table with multi-level column headers. Use semantic table structure with `caption`, column groups, row headers, and scoped headers. Visible heading: `Semantic Data Table With Multi-Level Headers` Visible description: `This example imitates a finance comparison table with grouped headers. It tests extraction of table captions, row headers, column group headers, nested column headers, currency values, percentages, and summary rows.` Table caption: `Quarterly billing performance by product line`. Column groups: Group `Q1 2026` with columns `Revenue`, `Refunds`, `Net`. Group `Q2 2026` with columns `Revenue`, `Refunds`, `Net`. Final column `Change`. Rows: Row 1: `Product line`: `Business platform seats`. `Q1 Revenue`: `$128,400`. `Q1 Refunds`: `$4,220`. `Q1 Net`: `$124,180`. `Q2 Revenue`: `$142,880`. `Q2 Refunds`: `$3,918`. `Q2 Net`: `$138,962`. `Change`: `+11.9 percent`. Row 2: `Product line`: `Audit log retention`. `Q1 Revenue`: `$42,100`. `Q1 Refunds`: `$820`. `Q1 Net`: `$41,280`. `Q2 Revenue`: `$48,900`. `Q2 Refunds`: `$640`. `Q2 Net`: `$48,260`. `Change`: `+16.9 percent`. Row 3: `Product line`: `Priority support`. `Q1 Revenue`: `$68,400`. `Q1 Refunds`: `$3,200`. `Q1 Net`: `$65,200`. `Q2 Revenue`: `$74,500`. `Q2 Refunds`: `$2,980`. `Q2 Net`: `$71,520`. `Change`: `+9.7 percent`. Summary row: `Product line`: `Total`. `Q1 Revenue`: `$238,900`. `Q1 Refunds`: `$8,240`. `Q1 Net`: `$230,660`. `Q2 Revenue`: `$266,280`. `Q2 Refunds`: `$7,538`. `Q2 Net`: `$258,742`. `Change`: `+12.2 percent`. Extraction caveat: the extraction tool should preserve multi-level header context, such as `Q2 2026 Net`, instead of returning generic `Net` values without quarter context. Implementation guidance: use ``, ``, two header rows, `scope="colgroup"`, `scope="col"`, and row header cells with `scope="row"`. --- S00 Example 10 - Landmark Layout With Repeated Navigation Names --- Create a page layout with multiple landmark regions and repeated navigation labels. Include a main navigation, account navigation, and footer navigation. Visible heading: `Landmark Layout With Repeated Navigation Names` Visible description: `This example imitates a complex application shell with multiple navigation landmarks. It tests extraction of landmark context, repeated link labels, and region-specific navigation names.` App shell header: `Application`: `Northwind Admin`. `Signed in as`: `Anika Sharma`. `Workspace`: `Northwind Analytics`. Landmark region 1: `role`: native `nav`. `aria-label`: `Primary navigation`. Links: `Dashboard`. `Search`. `Reports`. `Settings`. Landmark region 2: `nav`. `aria-label`: `Account settings navigation`. Links: `Profile`. `Billing`. `Security`. `Settings`. Main landmark: `main`. Page title: `Workspace settings overview`. Summary cards: `Billing status`: `Configured`. `Security status`: `Enforced`. `Notification status`: `Partially configured`. `Integration status`: `Healthy`. Aside landmark: `aria-label`: `Related settings`. Links: `Settings`. `Billing contacts`. `Audit log`. `API keys`. Footer navigation: `aria-label`: `Footer navigation`. Links: `Help`. `Settings`. `Privacy`. `Terms`. Extraction caveat: the extraction tool should preserve which navigation region each repeated `Settings` link belongs to. It should not output a flat link list without landmark context. Implementation guidance: use semantic `
`, `