diff --git a/AGENTS.md b/AGENTS.md index 31937c3..73f73fe 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -143,6 +143,7 @@ When the user mentions these keywords, load the corresponding skill: | "technology-radar", "technology radar" | [technology-radar](technology-radar/SKILL.md) | | "strategy", "strategic planning", "OKRs", "strategic narrative", "Five Forces", "Blue Ocean", "competitive positioning", "moat", "Ansoff", "Three Horizons", "market entry", "capital allocation", "M&A evaluation", "BCG Matrix", "portfolio management" | [strategy-frameworks](strategy-frameworks/SKILL.md) | | "verification-methodology", "verification methodology" | [verification-methodology](verification-methodology/SKILL.md) | +| "accessibility", "a11y", "WCAG", "ARIA", "accessible name", "screen reader", "keyboard navigation", "focus management", "focus trap", "dialog", "modal", "combobox", "listbox", "accessible form", "form validation", "error recovery", "accessible authentication", "color contrast", "reduced motion", "target size", "accessibility testing" | [web-accessibility](web-accessibility/SKILL.md) | | "seo-audit", "seo audit" | [seo-audit](seo-audit/SKILL.md) | ## Use-When Sections diff --git a/README.md b/README.md index 683867d..a42273c 100644 --- a/README.md +++ b/README.md @@ -283,6 +283,10 @@ Transistor.fm podcast hosting from the terminal. Manage shows and episodes, view Replace completion claims with a disciplined evidence trail that shows what was checked, what passed, and what remains uncertain. +### [web-accessibility](web-accessibility/SKILL.md) + +Design, build, and review accessible web interfaces through native semantics, keyboard and focus contracts, error recovery, adaptive UI, assistive-technology testing, and WCAG 2.2-informed evidence without mistaking automated scans for conformance. + ### [woodpecker-ci](woodpecker-ci/SKILL.md) Operate self-hosted Woodpecker CI from installation through production troubleshooting. Covers Forgejo/Gitea integration, server and agent setup, Docker and Kubernetes backends, workflow syntax, secrets, plugins, matrices, CLI/local execution, upgrades, security, and incident response. diff --git a/web-accessibility/README.md b/web-accessibility/README.md new file mode 100644 index 0000000..7197df8 --- /dev/null +++ b/web-accessibility/README.md @@ -0,0 +1,42 @@ +# Web Accessibility + +Build web interfaces people can operate, understand, and recover from across keyboard, pointer, zoom, motion, and assistive technologies. + +## Why Install This Skill + +Visually polished interfaces can still strand people in a modal, hide focus behind sticky UI, make errors impossible to fix, or announce the wrong thing to a screen reader. This skill helps turn a feature's user flow into explicit accessibility requirements before code is written. + +It gives your agent a framework-neutral way to choose native controls, define custom-widget contracts only when needed, and collect evidence from automated checks and real manual tasks. It treats passing a scanner as useful but limited evidence, not a promise of accessibility or WCAG conformance. + +## What You Get + +| Path | What it provides | +|---|---| +| `SKILL.md` | Workflow, decision rules, routing, and reference guide. | +| `references/source-index.md` | Primary sources with status, version, URL, and decision use. | +| `references/` | Focused guidance for semantics, focus, forms, widgets, adaptive UI, testing, routing, and outcome probes. | +| `assets/` | Reusable acceptance-criteria, design-review, implementation-review, and release-evidence templates. | + +## Quick Start + +Ask your agent to turn a feature flow into accessibility acceptance criteria before implementation. For example: + +```text +Design an accessible profile editor modal. Define keyboard, focus, form recovery, +and browser/AT verification requirements before writing code. +``` + +No API key, package, or framework is required. + +## Triggers + +- Accessibility, a11y, WCAG, ARIA, accessible name, screen reader, or assistive technology. +- Keyboard navigation, focus order, focus trap, focus restoration, dialog, modal, disclosure, or responsive navigation. +- Form labels, validation, errors, accessible authentication, live regions, or recovery. +- Comboboxes, tabs, listboxes, menus, grids, target size, drag alternatives, zoom, reflow, contrast, or reduced motion. +- Accessibility testing, axe, manual testing, accessibility review, or release evidence. + +## Requirements + +- Access to the interface and its supported browser/AT environment for meaningful verification. +- Optional automated testing tools may provide bounded rule-level evidence; manual keyboard, accessibility-tree, and selected screen-reader testing remain required for interaction risk. diff --git a/web-accessibility/SKILL.md b/web-accessibility/SKILL.md new file mode 100644 index 0000000..f49d240 --- /dev/null +++ b/web-accessibility/SKILL.md @@ -0,0 +1,62 @@ +--- +name: web-accessibility +description: >- + Design, build, and review accessible web interfaces with native semantics, + keyboard and focus behavior, forms and recovery, responsive input, motion, + assistive-technology testing, and WCAG 2.2-informed evidence. Use for a11y, + WCAG, ARIA, screen-reader, keyboard, focus, dialog, form, widget, or + accessibility review work across frameworks. +license: MIT +compatibility: Works with any agent framework supporting the Agent Skills format; no runtime dependency. +metadata: + wcag-status: "W3C Recommendation 2023-10-05" + aria-version: "WAI-ARIA 1.2" +--- + +# Web Accessibility + +Accessibility is successful task completion and recovery for disabled people, not a tool score. Define observable requirements before implementation, prefer native platform behavior where it fits, and gather bounded evidence in the supported browser and assistive-technology (AT) environment. + +## Workflow + +1. Define the task, users, supported browsers/AT, input methods, and failure recovery. Start with `assets/acceptance-criteria-template.md`. +2. Choose native HTML first. Load `references/semantics-and-names.md` for structure, native controls, accessible names, descriptions, and dynamic updates. +3. Specify every interactive state: trigger, role/name/state/value, keyboard commands, focus entry/exit/return, pointer alternative, errors, and visible feedback. Load the focused pattern reference. +4. Design for visual and input adaptation using `references/visual-input-and-motion.md`; distinguish WCAG requirements from product goals and exceptions. +5. Implement only after the contract is defined. For custom composite widgets, first evaluate a proven native or maintained component in the chosen stack; APG examples are informative guidance, not production proof. +6. Verify with `references/testing-and-evidence.md` and the design, implementation, and release templates. Record tool, version, scope, manual tasks, actual browser/AT combinations, failures, and blocked or not-applicable items. +7. Do not issue a WCAG conformance or general accessibility verdict from an automated scan. A conformance claim needs a complete, scoped evaluation outside this skill's automatic verdict. + +## Load On Demand + +| Need | Load | +|---|---| +| Standards status, source authority, or exact links | `references/source-index.md` | +| Native semantics, labels, accessible names, landmarks, live updates | `references/semantics-and-names.md` | +| Tab order, focus visibility, traps, restoration, route changes | `references/keyboard-focus-and-routing.md` | +| Labels, validation, recoverable errors, authentication | `references/forms-errors-authentication.md` | +| Modal dialogs, disclosure, responsive navigation | `references/dialogs-disclosures-navigation.md` | +| Tabs, comboboxes, listboxes, grids, menus, other composites | `references/composite-widgets.md` | +| Contrast, reflow, zoom, targets, drag, motion, media | `references/visual-input-and-motion.md` | +| Automated checks, manual protocols, AT matrix, evidence | `references/testing-and-evidence.md` | +| Framework or skill boundary | `references/routing.md` | +| Validate common outcomes without claiming conformance | `references/outcome-probes.md` | + +## Decision Rules + +- Treat WCAG 2.2 success criteria, HTML/ARIA specifications, and informative tutorials/patterns as separate layers. See `references/source-index.md`. +- Use WAI-ARIA 1.2 only when native host-language semantics do not provide the required behavior. ARIA changes semantics; it does not create keyboard behavior or visual presentation. +- Use the Accessible Name and Description Computation 1.2 algorithm for edge cases. Do not substitute a priority mnemonic; inspect the computed accessibility tree and name. +- For a modal, prefer `.showModal()` when it supports the target environment. Keep background content unavailable/inert, choose initial focus for the content and task, provide a visible close path, and return focus logically. Do not hide a backdrop with `aria-hidden` or hide an ancestor of the dialog. +- Treat ordinary responsive navigation as a disclosure over ordinary links, not an ARIA menu. Use menu semantics only with the application-menu keyboard contract. +- Target Size (Minimum) is 24 by 24 CSS pixels at WCAG 2.2 AA, subject to its spacing, equivalent, inline, user-agent, and essential exceptions. A larger target may be a product goal. + +## Completion + +Stop when each acceptance criterion has direct evidence or a recorded failed, blocked, or not-applicable result. Report residual risk and the exact evidence boundary; do not turn absent testing into a pass. + +## When Not To Use + +- For Hugo template architecture, theme-wide layout, or CMS rendering concerns, use [hugo-theme](../hugo-theme/SKILL.md) and its [design/accessibility reference](../hugo-theme/references/design-accessibility.md). +- For product workflow, discovery, or requirements outside accessibility, use [product-methodology](../product-methodology/SKILL.md). Keep this skill responsible for the accessibility interaction contract. +- For framework or library APIs, consult the current official documentation after defining this skill's semantic and interaction contract. diff --git a/web-accessibility/assets/acceptance-criteria-template.md b/web-accessibility/assets/acceptance-criteria-template.md new file mode 100644 index 0000000..5e95cb2 --- /dev/null +++ b/web-accessibility/assets/acceptance-criteria-template.md @@ -0,0 +1,23 @@ +# Accessibility Acceptance Criteria + +## Flow + +- User goal: +- Start state and trigger: +- Supported browsers, AT, input methods, and relevant audience data: +- Success state, failure states, and recovery: + +## Criteria + +- [ ] Native semantic structure and visible labels communicate purpose; computed role/name/state/value are recorded for custom or high-risk controls. +- [ ] Keyboard-only users can start, complete, reverse, cancel, and recover from the task with visible, unobscured focus. +- [ ] Pointer-only actions have an appropriate alternative, including drag where relevant. +- [ ] Errors are identifiable, specific, associated, discoverable, and recoverable without losing entered data. +- [ ] Dynamic changes, status, route changes, motion, media, zoom/reflow, contrast, and target size are addressed when applicable. +- [ ] Composite widgets document their complete interaction contract and target browser/AT test plan. + +## Evidence Plan + +| Criterion | Method | Environment | Pass/fail/blocked/not applicable | Evidence link or note | +|---|---|---|---|---| +| | | | | | diff --git a/web-accessibility/assets/review-checklist-design.md b/web-accessibility/assets/review-checklist-design.md new file mode 100644 index 0000000..04bb8e8 --- /dev/null +++ b/web-accessibility/assets/review-checklist-design.md @@ -0,0 +1,10 @@ +# Accessibility Design Review + +- [ ] User tasks, recovery, input methods, and support environment are known. +- [ ] Information is not conveyed by color, position, or motion alone. +- [ ] Text, controls, focus states, targets, responsive states, and overlays have been designed for contrast, zoom, reflow, and text spacing. +- [ ] Focus is visible and cannot be hidden by sticky or modal UI. +- [ ] Dialog initial focus, close behavior, and post-close destination are intentional. +- [ ] Forms show labels, instructions, error recovery, preserved values, and success states. +- [ ] Motion, flashing, media, drag, and autoplay have applicable alternatives or controls. +- [ ] Custom widgets have a documented reason instead of a native or maintained alternative. diff --git a/web-accessibility/assets/review-checklist-implementation.md b/web-accessibility/assets/review-checklist-implementation.md new file mode 100644 index 0000000..07c7a42 --- /dev/null +++ b/web-accessibility/assets/review-checklist-implementation.md @@ -0,0 +1,10 @@ +# Accessibility Implementation Review + +- [ ] Native HTML provides the primary semantics; ARIA is used only where necessary and does not duplicate or contradict it. +- [ ] Controls have intended computed role, name, state, value, and relationships in each key state. +- [ ] Keyboard entry, operation, reverse navigation, exit, escape/cancel, focus visibility, and restoration work. +- [ ] Modal background is unavailable/inert without hiding the dialog's ancestor or applying `aria-hidden` to a backdrop. +- [ ] Forms use visible labels and native semantics where appropriate; error behavior is contextual and recoverable. +- [ ] Responsive navigation remains ordinary links unless an application-menu keyboard contract is implemented. +- [ ] Composite widgets have the full documented contract and no role-pattern mixing. +- [ ] Adaptive layout, motion, media, target exceptions, and drag alternatives are implemented where applicable. diff --git a/web-accessibility/assets/review-checklist-release.md b/web-accessibility/assets/review-checklist-release.md new file mode 100644 index 0000000..726243b --- /dev/null +++ b/web-accessibility/assets/review-checklist-release.md @@ -0,0 +1,27 @@ +# Accessibility Release Evidence + +## Scope + +- Release/version: +- Features and states tested: +- Supported browser/AT/input combinations: +- Known exclusions: + +## Evidence + +| Check | Tool or protocol/version | Scope and result | Evidence | +|---|---|---|---| +| Automated rules | | | | +| Keyboard tasks, including reverse/recovery | | | | +| Accessibility-tree inspection | | | | +| Screen reader tasks | | | | +| Zoom/reflow/text spacing/contrast/motion/target/pointer | | | | +| Disabled-user research, if used | | | | + +## Verdict + +| Acceptance criterion | Pass/fail/blocked/not applicable | Evidence and remaining risk | +|---|---|---| +| | | | + +Automated results are bounded evidence only. This template does not issue a WCAG conformance claim or an automatic accessibility verdict. diff --git a/web-accessibility/references/composite-widgets.md b/web-accessibility/references/composite-widgets.md new file mode 100644 index 0000000..d891f2a --- /dev/null +++ b/web-accessibility/references/composite-widgets.md @@ -0,0 +1,23 @@ +# Composite Widgets + +Custom tabs, comboboxes, listboxes, grids, tree views, toolbars, sliders, radio groups, and application menus have a complete contract: role, name, state/value, relationships, keyboard commands, focus model, pointer behavior, disabled behavior, error/recovery behavior, and announced changes. + +## Decision Path + +1. Can a native element or ordinary disclosure solve the user task? +2. Can a maintained component in the selected stack meet the requirements and support target environments? +3. If custom behavior is necessary, use [APG](https://www.w3.org/WAI/ARIA/apg/) as informative pattern guidance, document the whole contract, and test the audience-relevant browser/AT combinations. + +## Pattern Contracts + +| Pattern | Minimum contract to define and verify | +|---|---| +| Tabs | `tablist`, named `tab` controls, `tabpanel` relationships, one selected tab, roving Tab stop, Left/Right navigation for horizontal tabs, orientation-aware keys, Home/End where supported, and manual versus automatic activation chosen from loading latency and task behavior. | +| Combobox | Named input or button, synchronized expanded state, popup role and relationship, current option/value, editing behavior, filtering, selection, Escape/close behavior, and either DOM focus or `aria-activedescendant` managed consistently. | +| Listbox | Label, options, single/multiple selection model, active option, arrow navigation, type-ahead where useful, selection-follow-focus decision, and entry/exit behavior. Do not use it for ordinary links or checkboxes. | +| Application menu | Named menu button, expanded state, `menu`/`menuitem` structure, arrow-key movement, Home/End, Escape, focus entry/return, and activation. Ordinary site navigation is not this pattern. | +| Grid/tree | Row/item structure, selection versus focus, roving or active-descendant model, directional navigation, editing mode, announcements, and a practical alternative if the interaction is too complex. | + +APG key assignments describe a pattern contract, not a reason to implement it. Account for writing direction and orientation, and do not make every descendant a Tab stop when the adopted composite pattern uses arrow-key navigation. + +Do not mix roles from different patterns or add ARIA roles merely to style an ordinary list. Accessibility-tree inspection and task testing are required because valid attributes alone do not prove usable interaction. diff --git a/web-accessibility/references/dialogs-disclosures-navigation.md b/web-accessibility/references/dialogs-disclosures-navigation.md new file mode 100644 index 0000000..6065bd4 --- /dev/null +++ b/web-accessibility/references/dialogs-disclosures-navigation.md @@ -0,0 +1,15 @@ +# Dialogs, Disclosures, and Navigation + +## Modal Dialogs + +Prefer `` with `showModal()` when it is supported by the target environment; otherwise implement the equivalent behavior deliberately and test it. A modal needs an accessible name, a visible close path, focus inside while open, unavailable/inert background content, and logical focus restoration. + +For native ``, use its modal API rather than merely toggling `open`; define intentional initial focus, closing, cancellation, and return behavior, then verify the supported browser/AT implementations. For a custom modal, supply `dialog` semantics, set `aria-modal="true"` only when the UI is genuinely modal for every user, contain Tab and Shift+Tab, and make the rest of the application unavailable without hiding the dialog. + +Choose initial focus from content structure, viewport, reversibility, and the likely task. It is not always the first control. Return focus to the invoker unless it no longer exists or the workflow makes another target more appropriate. `aria-describedby` is optional and may make rich structural content harder to consume. Close requests, Escape, and light dismiss depend on the adopted pattern and product intent; define and test them. Do not put `aria-hidden` on a backdrop and never hide an ancestor containing the dialog. + +## Disclosures And Navigation + +Use a native `button` to control a disclosure and synchronize `aria-expanded`; connect it to the controlled region when useful. Responsive site navigation normally remains ordinary links within a navigation landmark. It is not an ARIA menu by default. Provide visible focus, logical open/close behavior, `aria-current="page"` for the current page, and target-size review including WCAG exceptions. + +Use `menu`/`menuitem` roles only for application-style menus and implement their full keyboard/focus contract. Outside-click dismissal is a product choice, not a universal requirement. diff --git a/web-accessibility/references/forms-errors-authentication.md b/web-accessibility/references/forms-errors-authentication.md new file mode 100644 index 0000000..962f04f --- /dev/null +++ b/web-accessibility/references/forms-errors-authentication.md @@ -0,0 +1,24 @@ +# Forms, Errors, and Authentication + +Use a native `
` and semantic input types where they fit. Give each control a visible label, explain constraints before submission when useful, group related controls with `fieldset` and `legend`, and preserve entered values after recoverable errors. + +## Error Recovery + +- Identify errors in text and visually without color alone; make them specific enough to correct. Explain required formats and constraints before they cause avoidable failures. +- Associate error and help text with the relevant field when that relationship helps. Set `aria-invalid` when a field is invalid; do not mechanically duplicate native `required` with `aria-required`. +- Decide whether to use native validation, custom validation, or both for the product and environment. Do not universally add `novalidate`. +- Choose an error summary, focus movement, and announcement behavior for the flow, then test with keyboard and target AT. `aria-errormessage` and assertive live regions are optional tools, not defaults. If focus moves to a summary, its links or references must lead to the affected controls. +- Preserve valid and recoverable entries. Give destructive or consequential submissions review, confirmation, correction, or reversal appropriate to the risk. +- Expose successful submission or saved status without interrupting unrelated work. + +## Input Purpose, Repetition, And Help + +Use native input types and autocomplete tokens when they accurately identify common user data. Keep help mechanisms in a consistent relative order when WCAG 3.2.6 applies. Within the same process, reuse or offer previously entered information when WCAG 3.3.7 applies, while respecting its security, essential-purpose, and stale-information exceptions. + +## Authentication + +WCAG 2.2 SC 3.3.8 is Accessible Authentication (Minimum), AA; SC 3.3.7 is Redundant Entry, A. Support password managers and paste. Read the criterion for alternatives and exceptions before evaluating CAPTCHA, biometrics, or cognitive-function tests; do not make categorical claims beyond its text. + +## Evidence Questions + +Can a keyboard and screen-reader user find instructions, submit, understand every error, correct it without re-entering recoverable data, and perceive success? Record the actual tested behavior rather than assumed ARIA output. diff --git a/web-accessibility/references/keyboard-focus-and-routing.md b/web-accessibility/references/keyboard-focus-and-routing.md new file mode 100644 index 0000000..43fc33f --- /dev/null +++ b/web-accessibility/references/keyboard-focus-and-routing.md @@ -0,0 +1,18 @@ +# Keyboard, Focus, and Route Changes + +Keyboard behavior is a user-flow contract, not a `keydown` handler. Document how focus enters, operates within, exits, and recovers from every interactive state. + +## Baseline + +- Preserve logical DOM order; avoid positive `tabindex`. Make all functionality available without a pointer. +- Ensure a visible focus indicator with sufficient contrast, including after themes, zoom, and sticky overlays are active. +- Test forward and reverse navigation. Verify that focus is not obscured by sticky headers, footers, drawers, or virtual keyboard behavior. WCAG 2.4.11 is AA; 2.4.12 and 2.4.13 are AAA. +- A focus trap is appropriate only for an actual modal. It needs a usable exit and logical restoration, not just cycling Tab. + +## Route And State Changes + +Before changing focus, answer: what changed, where can the user continue, and will the move lose work or context? For routes, preserve browser history behavior, expose the new page purpose, and test back/forward, validation failures, and deep links. Choose a main heading, main region, status, or retained control only when the flow supports it. + +## Manual Protocol + +Complete each task with keyboard alone: Tab, Shift+Tab, Enter, Space, Escape, and pattern-specific arrows/Home/End where applicable. Record order, visible focus, unexpected traps, restoration, and recovery from each failure state. diff --git a/web-accessibility/references/outcome-probes.md b/web-accessibility/references/outcome-probes.md new file mode 100644 index 0000000..9574696 --- /dev/null +++ b/web-accessibility/references/outcome-probes.md @@ -0,0 +1,23 @@ +# Outcome Probes + +Use these probes to check whether a proposed design or implementation follows this skill. They are review prompts, not automated conformance tests. + +## A. Modal Profile Editor + +Verify an accessible dialog name, context-appropriate initial focus, inert/unavailable background, custom-modal Tab containment where relevant, visible close path, logical focus restoration, native form semantics/error recovery, and recorded browser/AT evidence. Reject backdrop `aria-hidden` and mandatory `aria-describedby` assumptions. + +## B. Contact Form Recovery + +Verify visible labels, native semantics, clear instructions, identified and associated errors, preserved values, context-tested summary/focus/announcement behavior, exposed success, and keyboard/screen-reader task completion. Reject universal `novalidate`, `aria-required`, `aria-errormessage`, or `role="alert"` requirements. + +## C. Responsive Navigation + +Verify a native button, state synchronized through `aria-expanded`, useful control relationship, ordinary navigation links, visible focus, logical close/focus behavior, current-page state, and 24 by 24 CSS-pixel target criterion with documented exceptions. Reject application-menu semantics by default. + +## D. Custom Combobox + +Require a documented role/state/keyboard/focus/name contract, accessibility-tree inspection, target browser/AT testing, and consideration of a proven native or maintained component before custom code. + +## E. Release Verdict + +Require bounded automated evidence, manual protocols, actual tested combinations, and recorded blocked/not-applicable criteria. Reject WCAG conformance or accessibility claims based on an automated scan alone. diff --git a/web-accessibility/references/routing.md b/web-accessibility/references/routing.md new file mode 100644 index 0000000..a4fc1eb --- /dev/null +++ b/web-accessibility/references/routing.md @@ -0,0 +1,13 @@ +# Routing + +Keep the semantic and interaction contract framework-agnostic first. Then use the current official documentation for the chosen framework or component library to implement it; do not assume a universal framework or library. + +| Situation | Route | +|---|---| +| Hugo template architecture, theme-wide layout, or CMS rendering | [hugo-theme](../../hugo-theme/SKILL.md) and its [design/accessibility reference](../../hugo-theme/references/design-accessibility.md) | +| Product workflow, discovery, or requirements outside accessibility | [product-methodology](../../product-methodology/SKILL.md); keep the accessibility contract here | +| Browser platform behavior | WHATWG HTML in `source-index.md` | +| ARIA roles/pattern contracts | WAI-ARIA 1.2 and APG in `source-index.md` | +| Framework-specific component API | Current official documentation after requirements are defined | + +Do not route to a library merely because it advertises accessibility. Confirm its behavior against the user task and target browser/AT support. diff --git a/web-accessibility/references/semantics-and-names.md b/web-accessibility/references/semantics-and-names.md new file mode 100644 index 0000000..19cb4a4 --- /dev/null +++ b/web-accessibility/references/semantics-and-names.md @@ -0,0 +1,22 @@ +# Semantics, Names, and Dynamic Updates + +Start with HTML that represents the content and action: headings for headings, lists for lists, links for navigation, buttons for actions, and native inputs with labels. Native controls reduce interaction code, but test their actual browser/AT behavior in the supported environment. + +## Structure And Names + +- Use meaningful heading hierarchy and landmarks to expose page structure. Provide a bypass mechanism where repeated blocks create real keyboard burden. Use headings for sections, not merely for visual sizing, and keep the DOM reading order meaningful when CSS is removed. +- Mark data tables as tables, provide a useful caption when it helps identify purpose, and associate header cells with data cells. `scope` is usually sufficient for simple row or column headers; simplify complex tables or verify any `headers`/`id` mapping. Do not expose layout tables as data tables. +- Give every interactive control a visible, understandable label where practical. Associate `