@gunkin/uiify 0.0.16-alpha → 0.0.19-alpha

package/skills/uiify/references/elements/cookie-banner.md

@@ -0,0 +1,51 @@
+# cookie-banner
+
+Binding: gap
+
+Explain cookie choices and provide consent actions.
+
+## Use when
+
+A product needs to explain its cookie/storage choices and provide a clear route to the detailed policy and preference controls.
+
+## Avoid when
+
+Do not obscure the primary task with a full-screen interruption when a compact notice works. Do not imply that a button choice is legally sufficient in every jurisdiction; match the product's actual consent policy.
+
+## Structure
+
+This is an app-level composition, not a UIify component. State what optional storage is used for, link to the policy, and present distinct choices with similarly clear labels.
+
+## Responsive
+
+Keep the notice readable at mobile widths and zoom; allow the page to remain usable and make every choice reachable without horizontal scrolling.
+
+## States
+
+Represent the actual consent state: undecided, accepted/rejected as supported by policy, and preference editing. Persist only the choice the person made, and provide a way to revisit preferences.
+
+## Verify
+
+Check keyboard operation, policy link, clear action labels, focus order, narrow layout, persistence behavior, and that the choices match the implementation and applicable policy.
+
+## Common mistake
+
+Do not hide rejection behind multiple steps while acceptance is a single prominent button.
+
+## Custom implementation
+
+```html
+<aside aria-labelledby="cookie-title">
+  <h2 id="cookie-title">Cookie choices</h2>
+  <p>Choose whether to allow optional cookies.</p>
+  <button type="button">Allow optional cookies</button>
+  <button type="button">Reject optional cookies</button>
+</aside>
+```
+
+This is an app-level composition; UIify does not currently ship this component.
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) (verified 2026-10-16)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) (verified 2026-10-16)

package/skills/uiify/references/elements/date-picker.md

@@ -0,0 +1,43 @@
+# date-picker
+
+Binding: gap
+
+Collect one calendar date using the browser’s native date control.
+
+## Use when
+
+Collect one calendar date without a time, such as a start or due date.
+
+## Avoid when
+
+Use a date-time control when time matters. Avoid replacing the native picker with a custom calendar unless the task requires behavior that has been tested for keyboard and assistive technology.
+
+## Structure
+
+Use a visible label with a native input of type date. Add min and max only when the constraints are real, explain them before entry, and associate error feedback with the field.
+
+## Responsive
+
+Allow the browser’s date UI to use the platform layout; keep the field within the available width and do not assume every browser displays the same picker.
+
+## States
+
+Distinguish an empty value, a valid date, and a date outside the allowed range. The submitted date value is a calendar date normalized as yyyy-mm-dd.
+
+## Verify
+
+Test keyboard entry and picker operation in target browsers, date bounds, visible format guidance, validation text, and narrow-screen behavior.
+
+## Common mistake
+
+Treating a date-only value as a timestamp with a time zone.
+
+## Custom implementation
+
+Use a labelled native input with type date. This app-level pattern does not add a UIify date-picker component.
+
+## Sources
+
+- [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/labels/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/instructions/) (verified 2026-10-17)

package/skills/uiify/references/elements/divider.md

@@ -0,0 +1,46 @@
+# divider
+
+Binding: gap
+
+Separate adjacent thematic sections when a heading is not appropriate.
+
+## Use when
+
+Adjacent sections change topic and a thematic break helps people understand the transition.
+
+## Avoid when
+
+Do not add a divider between every repeated item or use it in place of spacing. Decorative lines that convey no grouping should remain outside the accessibility tree.
+
+## Structure
+
+This is an app-level composition, not a UIify component. Use the native hr element for a thematic break; use CSS border for a purely decorative rule.
+
+## Responsive
+
+Use logical sizing and preserve separation as content wraps or stacks. Avoid rules that become ambiguous in vertical writing or dense layouts.
+
+## States
+
+A thematic break is static. If a separator labels a widget such as a menu, use that widget's separator semantics instead of hr.
+
+## Verify
+
+Check whether the line marks a real topic change, reading flow around it, and narrow layout.
+
+## Common mistake
+
+A visual border between every card is not automatically a thematic break.
+
+## Custom implementation
+
+```html
+<hr />
+```
+
+This is an app-level composition; UIify does not currently ship this component.
+
+## Sources
+
+- [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hr) (verified 2026-10-16)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) (verified 2026-10-16)

package/skills/uiify/references/elements/drawer.md

@@ -0,0 +1,38 @@
+# drawer
+
+Binding: drawer
+
+A focused secondary task or navigation surface should enter from an edge and temporarily cover or accompany the page
+
+## Use when
+
+A focused secondary task or navigation surface should enter from an edge and temporarily cover or accompany the page. Choose it when the task benefits from a sheet-like spatial relationship.
+
+## Avoid when
+
+Do not use a drawer for content that should remain visible beside the page, or for a compact anchored choice list. Avoid turning primary navigation into a blocking task without a clear need.
+
+## Structure
+
+Use `Drawer` with a specific title, optional description, focused content, visible close control, and optional footer. Select side and size to fit the task; use snap points only when the client interaction is needed.
+
+## Responsive
+
+Use a bottom sheet on narrow screens when the task reads naturally as a sheet; keep its content scrollable and close action reachable. Respect safe areas and test the selected side at mobile widths.
+
+## States
+
+The native Tier 0 shell opens a dialog. Choose 'dismiss' deliberately: 'any' permits backdrop/Escape, 'closerequest' allows close requests, and 'none' requires an explicit close. The compound client API adds controlled state and optional snap-point dragging.
+
+## Verify
+
+Check visible title, focus entry/containment/return, close control, configured dismissal, scrolling, and narrow viewport. If using drag, test the handle with touch and pointer and ensure an explicit close remains available.
+
+## Common mistake
+
+Do not rely on dragging as the only way to close or resize the drawer.
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) (verified 2026-10-17)
+- [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog) (verified 2026-10-17)

package/skills/uiify/references/elements/dropdown-menu.md

@@ -0,0 +1,38 @@
+# dropdown-menu
+
+Binding: dropdown-menu
+
+A button reveals a compact set of actions or settings for that button
+
+## Use when
+
+A button reveals a compact set of actions or settings for that button. Use menu items for commands, checkbox items for independent toggles, and radio items for one choice within a group.
+
+## Avoid when
+
+Do not use a menu for site navigation; use ordinary links and navigation landmarks. Do not use menu roles for a form or a list of links that should remain in the page's normal Tab sequence.
+
+## Structure
+
+Compose `DropdownMenu` Root, Trigger, Content, and named items. Give the trigger an action-oriented accessible name; group related actions with labels and separators, and use checkbox/radio items only for their matching state model.
+
+## Responsive
+
+Keep the menu within the viewport and ensure labels remain readable at zoom. Provide a touch-sized trigger and avoid making hover the only way to open it.
+
+## States
+
+The trigger opens the menu; keyboard interaction moves focus among items and Escape closes and returns focus. Selection closes by default. 'openOnHover' is optional enhancement; preserve the normal click and keyboard route.
+
+## Verify
+
+Test trigger by keyboard and pointer, arrow-key item navigation, Home/End where supported, Escape and focus return, disabled items, selection, and checked/radio state announcements. Check placement near viewport edges.
+
+## Common mistake
+
+A row of destination links is navigation, even if it visually resembles a dropdown menu.
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/) (verified 2026-10-17)

package/skills/uiify/references/elements/empty-state.md

@@ -0,0 +1,50 @@
+# empty-state
+
+Binding: gap
+
+Explain why a collection has no items and offer a relevant next step.
+
+## Use when
+
+A collection has no items and the person needs to understand what is empty and what useful step is available next.
+
+## Avoid when
+
+Do not show an empty state for loading, filtered no-results, access denial, and a genuinely new collection as though they were the same cause. Name the actual state.
+
+## Structure
+
+This is an app-level composition, not a UIify component. Give the section a heading that names the collection and one relevant next step; use a link for navigation or a button for an in-place action.
+
+## Responsive
+
+Keep the message and action close in reading order, use a concise line length, and do not center long explanatory copy in an unnecessarily narrow area.
+
+## States
+
+Distinguish first-use empty, filtered no-results, unavailable/error, and loading states. Explain a recovery action for filters and avoid suggesting creation when the person lacks permission.
+
+## Verify
+
+Check the heading and action name, real destination/behavior, keyboard access, state-specific copy, and narrow/zoom layout.
+
+## Common mistake
+
+“No results” should offer a way to clear or change filters, not a create action unrelated to the search.
+
+## Custom implementation
+
+```html
+<section aria-labelledby="empty-title">
+  <h2 id="empty-title">No invoices yet</h2>
+  <p>Create an invoice to see it listed here.</p>
+  <a href="/invoices/new">Create invoice</a>
+</section>
+```
+
+This is an app-level composition; UIify does not currently ship this component.
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html) (verified 2026-10-16)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) (verified 2026-10-16)

package/skills/uiify/references/elements/feature-grid.md

@@ -0,0 +1,54 @@
+# feature-grid
+
+Binding: gap
+
+Present related product capabilities as a coherent set.
+
+## Use when
+
+Several related capabilities have equal importance and repeat the same content shape.
+
+## Avoid when
+
+Do not force unequal priorities or long-form explanations into a uniform grid. Use a comparison table when people must compare values across features.
+
+## Structure
+
+This is an app-level composition, not a UIify component. Render a labeled section containing a list of items; give each item a heading and short explanation. Use the same order and content hierarchy for every item.
+
+## Responsive
+
+Collapse to one column on narrow screens and retain source order. Avoid fixed heights that clip translated or zoomed text.
+
+## States
+
+Keep item actions consistent. If each feature links to detail, link its heading and retain a clear focus indicator.
+
+## Verify
+
+Check section label, heading levels, source order, one-column reflow, link names, and the card spacing at mobile width.
+
+## Common mistake
+
+Do not use three equal cards to imply equal priority when one feature is the primary action.
+
+## Custom implementation
+
+```html
+<section aria-labelledby="features-title">
+  <h2 id="features-title">Built for daily work</h2>
+  <ul>
+    <li><article><h3>Shared workspace</h3><p>Keep team work together.</p></article></li>
+    <li><article><h3>Clear history</h3><p>See what changed and when.</p></article></li>
+  </ul>
+</section>
+```
+
+This is an app-level composition; UIify does not currently ship this component.
+
+Related laws: references/laws/proximity.md, references/laws/readability.md
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) (verified 2026-10-16)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation.html) (verified 2026-10-16)

package/skills/uiify/references/elements/field.md

@@ -0,0 +1,44 @@
+# field
+
+Binding: field
+
+Keep a label and its form control together.
+
+## Use when
+
+Keep a form control, its label, instructions, and any validation message connected. Use visible labels that name the expected information; a placeholder is not a substitute.
+
+## Avoid when
+
+Do not use a field wrapper without a real form control, or hide instructions needed before the person enters a value.
+
+## Structure
+
+Use `Field.Root`, `Field.Label`, `Field.Control`, `Field.Description`, and `Field.Error` with the same `id` on Root and `fieldId` on every part. Put native props such as `name`, `type`, and `autoComplete` on `Field.Control`. Pass `invalid`, `required`, and `disabled` to the parts that need those states; Root does not inject props into them.
+
+## Responsive
+
+Keep labels and help text close to the control at narrow widths. Let long instructions and error messages wrap without clipping.
+
+## States
+
+Native required validation works without JavaScript. For application validation, set `invalid` on Root and Control and render `Field.Error` with the same state after validation. The control's accessible description includes the error while invalid.
+
+## Verify
+
+Click the label and confirm its control receives focus. Inspect the accessibility tree for the control's name and associated description; submit an invalid value and confirm a textual error appears and is announced. Check required, disabled, read-only, and long-message states.
+
+## Common mistake
+
+A label and control with different `fieldId` values disconnect the visible label from the input and its instructions.
+
+Example: `references/examples/field-validation.md`.
+
+Related laws: references/laws/proximity.md, references/laws/accessibility.md
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/grouping/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/labels/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html) (verified 2026-10-17)

package/skills/uiify/references/elements/file-upload.md

@@ -0,0 +1,40 @@
+# file-upload
+
+Binding: file-upload
+
+Let people select and manage files for a form or task.
+
+## Use when
+
+Let people attach one or more files to a form or task.
+
+## Avoid when
+
+Do not require drag and drop as the only way to choose files. Avoid asking for files unrelated to the task.
+
+## Structure
+
+Use FileUpload.Root with a labelled HiddenInput and an optional Trigger or Dropzone. Explain allowed formats, size limits, and maximum file count before selection; show selected filenames and provide a named remove action for each file.
+
+## Responsive
+
+Keep the browse control and selected-file list usable at narrow widths. Do not rely on a large drop target that pushes the file picker off screen.
+
+## States
+
+Report rejected files with the reason, including type, size, or count limits. Keep the accepted files and let people remove them. Treat accept as a picker hint; validate file type and size on the server.
+
+## Verify
+
+Test keyboard file selection, the accessible input name, multiple-file selection, dropzone as an optional path, rejected-file feedback, removal, and server-side validation.
+
+## Common mistake
+
+Treating the accept attribute as security validation or failing silently when a file is rejected.
+
+## Sources
+
+- [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file) (verified 2026-10-17)
+- [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/accept) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/labels/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/instructions/) (verified 2026-10-17)

package/skills/uiify/references/elements/footer.md

@@ -0,0 +1,45 @@
+# footer
+
+Binding: gap
+
+Offer secondary navigation and supporting information at the end of a page.
+
+## Use when
+
+Collect site-wide destinations, contact details, and supporting information after the main content.
+
+## Avoid when
+
+Do not use the footer to repeat every page section or create a landmark for a small local card footer.
+
+## Structure
+
+Use a page-level footer landmark and group related destinations into labelled navigation lists. Keep repeated link order consistent across pages.
+
+## Responsive
+
+Allow link groups to wrap or stack while preserving their source order. Avoid clipped columns and tiny tap targets.
+
+## States
+
+Keep destinations available at every viewport; do not hide essential links behind hover-only behavior.
+
+## Verify
+
+Check the landmark structure, labels for multiple navigation regions, keyboard access, and reflow at narrow widths and zoom.
+
+## Common mistake
+
+Using a page-level footer inside a card and unintentionally creating a landmark.
+
+## Custom implementation
+
+Use a semantic footer with headings and navigation lists. This app-level pattern does not add a UIify component.
+
+Related laws: references/laws/readability.md, references/laws/accessibility.md
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) (verified 2026-10-17)

package/skills/uiify/references/elements/form.md

@@ -0,0 +1,41 @@
+# form
+
+Binding: form
+
+Collect the information needed to complete one task.
+
+## Use when
+
+Collect the information needed to complete one task, such as signing in, registering, or purchasing. Ask only for information the task needs.
+
+## Avoid when
+
+Do not make a form for a collection of unrelated actions or for navigation alone.
+
+## Structure
+
+`Form` renders a native `<form>` and uses browser validation by default. Label every control; group related choices with `fieldset` and `legend`. Put one clearly named submit action after the fields. `validationBehavior="aria"` sets `noValidate`, so the page must provide its own accessible validation.
+
+## Responsive
+
+A single column is a useful default on narrow screens. Keep each label, control, and its instructions together when the layout changes; UIify `Form` does not impose visual layout.
+
+## States
+
+Support invalid submission, pending submission, success, and server error. Show detected errors in text, identify each affected field, and keep entered values after failure so the person can correct them.
+
+## Verify
+
+Submit empty and malformed values. Confirm browser validation or the page's own validation is active, errors identify the affected controls in text, values remain available after failure, and success and server-error messages are clear.
+
+## Common mistake
+
+Disabling submit before explaining validation can leave people stuck. Let the form explain what needs correction.
+
+Related laws: references/laws/proximity.md, references/laws/accessibility.md
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/grouping/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/forms/labels/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) (verified 2026-10-17)

package/skills/uiify/references/elements/header.md

@@ -0,0 +1,42 @@
+# header
+
+Binding: header
+
+Orient visitors with stable top-level navigation.
+
+## Use when
+
+Orient people with site identity and primary navigation that stays in a consistent place and order across pages.
+
+## Avoid when
+
+Do not turn the header into a second page body or hide all navigation behind a menu on wide screens.
+
+## Structure
+
+`Header.Root` renders a semantic `<header>`. Place a home link for the site identity, a named `<nav>` with primary links, and at most one prominent action. Mark the current page link with `aria-current="page"`. Give repeated navigation landmarks distinct names when their link sets differ.
+
+## Responsive
+
+Keep the logo and one useful action visible on narrow screens. Move secondary navigation behind a clearly named button that opens a `Modal`; leave the full navigation visible on wide screens.
+
+## States
+
+Keep navigation order consistent between pages. The `Header` component itself is static; use `@gunkin/uiify/components/header/client` only when scroll hide/reveal is requested.
+
+## Verify
+
+Inspect the accessibility tree for the banner and named navigation landmarks. Tab through the logo, links, and action in reading order; on narrow screens open and close the menu with the keyboard and check its focus and accessible name.
+
+## Common mistake
+
+Hiding the entire navigation behind a hamburger on desktop makes common destinations harder to scan.
+
+Related laws: references/laws/readability.md, references/laws/accessibility.md
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/) (verified 2026-10-17)

package/skills/uiify/references/elements/hero.md

@@ -0,0 +1,54 @@
+# hero
+
+Binding: gap
+
+Introduce the product and its next action.
+
+## Use when
+
+Use a hero on a page whose goal is to help people decide what to do next, such as a landing, pricing, or campaign page. Do not add one to settings, dashboards, or docs; start with the task's content.
+
+## Avoid when
+
+Do not lead with a generic slogan, a large decorative image, or multiple equally prominent actions.
+
+## Structure
+
+Start with one specific `h1` that states the page's purpose, one supporting sentence, and one main action. Add a secondary action only for a different useful path. Use an image only when it shows the product or subject and supports the page's claim; prefer existing assets from the project, preserve the focal point across responsive crops, and provide suitable alternative text. If no suitable asset exists, keep the layout complete without inventing one.
+
+## Responsive
+
+On narrow screens, order the text, action, then image. Let translated or long headings wrap, and keep the main action visible without horizontal scrolling.
+
+## States
+
+Check a long or translated heading and the layout when no image is available. Keep action labels and focus states clear in both light and dark themes.
+
+## Verify
+
+Confirm there is one `h1`, the main action is visible at 390×844 and 1440×900, and content reflows at 320 CSS px without two-dimensional scrolling. Check image alternative text against its purpose.
+
+## Common mistake
+
+A generic slogan, decorative gradient, and two equal buttons do not explain the page or the next step.
+
+## Custom implementation
+
+Use a named section, semantic heading, supporting copy, and the documented Button. The main action usually opens another page, so render it as a link. Add only static CSS for layout.
+
+```tsx
+<section aria-labelledby="page-title">
+  <h1 id="page-title">Plan releases your whole team can follow</h1>
+  <p>Orbit turns scattered tasks into one shared release timeline.</p>
+  <Button as="a" href="/signup">Start a free trial</Button>
+</section>
+```
+
+Related laws: references/laws/von-restorff.md, references/laws/accessibility.md
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/tutorials/images/) (verified 2026-10-17)

package/skills/uiify/references/elements/hover-card.md

@@ -0,0 +1,38 @@
+# hover-card
+
+Binding: hover-card
+
+A link or control has useful supplementary detail that a person may inspect on hover or keyboard focus without leaving the current page
+
+## Use when
+
+A link or control has useful supplementary detail that a person may inspect on hover or keyboard focus without leaving the current page. Keep it optional and short.
+
+## Avoid when
+
+Do not place essential instructions, required actions, or the only copy of important information in a hover card. Do not use it for a brief label (tooltip) or a menu of actions.
+
+## Structure
+
+Compose `HoverCard` Root, Trigger, and Content. Give the trigger a meaningful name on its own; the card supplements it rather than repairing an ambiguous link label.
+
+## Responsive
+
+The card opens on mouse hover and keyboard focus. Touch users need the same essential information elsewhere in the page and a usable trigger. Keep content narrow enough to fit without obscuring nearby controls.
+
+## States
+
+Focus or mouse hover opens the card; pointer movement into the content keeps it open, and leaving schedules close. Configure open/close delays only when they improve pointer travel without making content feel unresponsive.
+
+## Verify
+
+Test keyboard focus, mouse travel from trigger to card, dismissibility, persistence while moving the pointer, narrow viewports, and that all essential content remains available without hover.
+
+## Common mistake
+
+A hover card that closes while the pointer travels from its trigger to its content fails the hover/focus content requirements.
+
+## Sources
+
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html) (verified 2026-10-17)
+- [www.w3.org](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html) (verified 2026-10-17)