@olives/devos 2.1.0

package/.agents/skills/modern-web-guidance/guides/accessibility/accessibility.md

@@ -0,0 +1,463 @@
+# Accessibility Coding Guidelines
+
+This guide provides actionable DOs and DON'Ts for AI coding agents to ensure web applications are accessible to all users, including those using assistive technologies.
+
+Keep these principles in mind throughout:
+
+- **Accessibility is the minimum, not the ceiling.** Conformance to standards is the floor; aim for genuine usability.
+- **Patterns are use-case specific.** No checklist replaces real testing — including testing with disabled users — to confirm a given implementation is actually accessible in context.
+
+## 1. Content Navigability and Structure
+
+### Actionable Guidelines
+
+#### DOs
+- **Place all content within landmarks**: Wrap each relevant part of the page in `<header>`, `<nav>`, `<main>`, `<aside>`, and `<footer>` elements so assistive-tech users can jump between regions.
+- **Structure main content with headings**: Use `<h1>`–`<h6>` sequentially (no jumping `<h1>` → `<h4>`) so screen-reader users get a navigable outline.
+- **Use lists for repeated, contiguous content**: `<ul>`/`<ol>` give assistive tech a count up front and let users skip the entire group.
+- **Provide skip links** prior to repeated content like site headers with navigation or long/infinite lists, so that keyboard users can easily bypass them. Make sure the target is focusable (e.g. `<main id="content" tabindex="-1">`).
+- **Semantic Tables**: Use `<caption>` and `<th scope="col">` (or `<th scope="row">`) for data tables.
+
+#### DON'Ts
+- **Don't use fake headings**: Never style `<div>` or `<span>` to look like headings without standard `<h1>`–`<h6>` tags.
+- **Don't place headings inside `<summary>`, and avoid relying on headings inside `<details>` content**: Headings inside `<summary>` may be hidden from screen-reader heading lists and heading-navigation shortcuts entirely; headings inside `<details>` content are only reachable via heading navigation when the disclosure is open.
+  - **Caveat**: If a heading must act as a disclosure trigger, use a more robust alternative to `<details>`/`<summary>` instead, e.g. an accordion or a disclosure implemented with ARIA where the heading wraps the button.
+- **Don't use tables for layout**: Use CSS Grid/Flexbox for visual layouts.
+- **Don't overuse landmarks**: Too many landmarks dilute their value. In particular, avoid labeling a `<section>` (which turns it into a `region` landmark) — `region` should be a last resort when no other landmark fits.
+
+### Code Examples
+
+```html
+<!-- Good: Semantic landmarks, heading hierarchy, skip link -->
+<header>
+  <a href="#content" class="skip-link visually-hidden">Skip to content</a>
+  <nav aria-label="Primary">
+    <ul>
+      <li><a href="/">Home</a></li>
+    </ul>
+  </nav>
+</header>
+<main id="content" tabindex="-1">
+  <h1>Platform Dashboard</h1>
+  <section>
+    <h2>User Statistics</h2>
+    <table>
+      <caption>Monthly active users</caption>
+      <tr>
+        <th scope="col">Month</th>
+        <th scope="col">Users</th>
+      </tr>
+      <tr>
+        <td>January</td>
+        <td>12,000</td>
+      </tr>
+    </table>
+  </section>
+</main>
+```
+
+## 2. Semantic HTML and ARIA
+
+### Actionable Guidelines
+
+#### DOs
+- **Prefer HTML elements and attributes to ARIA**: A native element comes with the right role and behavior. `<button>` already implies `role="button"`; `required` already implies `aria-required`.
+- **Match ARIA implementations to actual behavior**: If you set `role="tab"`, the element must behave like a tab — including keyboard interactions. Many ARIA patterns can't be implemented in CSS alone and need JavaScript.
+- **Be deliberate about `disabled` vs `aria-disabled`**: `disabled` removes the element from the focus order entirely (and `tabindex="0"` won't bring it back), which is often wrong for toolbar buttons or links. `aria-disabled="true"` keeps the element focusable so users can land on it and learn it's disabled.
+
+#### DON'Ts
+- **Don't use ARIA when native HTML exists**: Avoid `<div role="button">` or `<a role="button">` if `<button>` works.
+- **Don't add redundant ARIA roles or properties**: Avoid `<ul role="list">`, `<nav role="navigation">`, or `<input required aria-required="true">`.
+  - **Caveat**: Safari removes list semantics from `<ul>`/`<ol>` outside `<nav>` when `list-style: none` or `display: flex`/`grid` is applied. In that case `role="list"` is required to restore them.
+- **Don't assume custom elements have no ARIA**: Custom elements can attach ARIA via `ElementInternals`, which some automated test tools can't see — so the absence of `role`/`aria-*` attributes in markup doesn't prove the element has no semantics. Verify with the browser's accessibility-tree inspector.
+
+## 3. Accessible Names and Descriptions
+
+Every interactive element and some landmarks need an accessible name, and many benefit from an accessible description. Names are short and identify the element; descriptions add context.
+
+### Actionable Guidelines
+
+#### DOs
+- **Prefer native naming mechanisms**: `<label>` for form controls, `<caption>` for `<table>`, `<legend>` for `<fieldset>`, `<figcaption>` for `<figure>`.
+- **Explicitly associate `<label>` with its control via `for`/`id`**, even when nesting the input inside the label — explicit association improves assistive-tech support.
+- **Prefer `aria-labelledby` over `aria-label` when a visible label exists**: avoids duplication, improves maintainability, and translates better.
+- **Prefer to reuse the same accessible name for hyperlinks that share an `href`.**
+- **Use visually hidden text to disambiguate controls** that look identical visually but do different things (e.g. multiple "Edit" buttons in a list).
+
+#### DON'Ts
+- **Don't put `aria-label`/`aria-labelledby` on elements that shouldn't be named** — e.g. plain `<div>`, `<span>`, or custom elements without a role. Custom elements may have an implicit role set via `ElementInternals`, so the absence of a `role` attribute isn't conclusive.
+- **Don't reuse an accessible name across controls with different effects in the same view** (close buttons for two different open dialogs are fine because only one is reachable at a time; multiple “Edit” buttons for different content is not).
+- **Don't reuse an accessible name across hyperlinks pointing to different `href`s.**
+- **Don't pack descriptions, error messages, or instructions into the label.**
+- **Don't repeat state already exposed via ARIA** (`aria-expanded`, `aria-checked`, `aria-selected`, `aria-pressed`) inside the accessible name — it creates redundancy and ambiguity.
+- **Don't include the role name in the label**: `<nav aria-label="Primary navigation">` reads as "Primary navigation navigation."
+- **Don't use `title` or `placeholder` as a naming mechanism.**
+- **Don't include interactive elements in an `aria-describedby` target** unless their text content reads sensibly as a description on its own (e.g. if a link’s text is the same as how it’s labelled elsewhere, it can be included within a description).
+
+### Code Example: Visually Hidden Utility
+
+A `.visually-hidden` utility lets you provide text for screen readers without rendering it visually. It's commonly used for skip links, additional context on icon-only buttons, and supplementary labels.
+
+```css
+/* Hides content visually but keeps it in the accessibility tree.
+   :focus-within / :active opt elements out — useful for skip links and
+   any focusable content wrapped in this class. */
+.visually-hidden:where(:not(:focus-within, :active)) {
+  position: absolute !important;
+  clip-path: inset(50%) !important;
+  overflow: hidden !important;
+  width: 1px !important;
+  height: 1px !important;
+  margin: -1px !important;
+  padding: 0 !important;
+  border: 0 !important;
+  white-space: nowrap !important;
+}
+```
+
+When the hidden content is focusable (skip links, focus-receiving wrappers), the `:focus-within`/`:active` exception lets it become visible. Style the visible state per situation, e.g. a skip link to the main content typically wants fixed positioning at the top-left of the viewport so the rest of the page doesn't shift.
+
+## 4. Document Metadata and Language
+
+### Actionable Guidelines
+
+#### DOs
+- **Declare Visual Language**: Always set `<html lang="en">` (or appropriate code).
+- **Unique Page Titles**: Front-load unique context in `<title>` (e.g., `Page Topic | Site Name`).
+- **Inline Language Switches**: Use `lang="..."` for block quotes or text in different languages.
+- **IFrame Titles**: Always provide a descriptive `title="..."` for `<iframe>` elements.
+- **Update document title on Page Transitions in SPAs**: Shift focus to updated titles.
+
+#### DON'Ts
+- **Don't Disable iframe Scrolling**: Avoid `scrolling="no"` (deprecated) or `overflow: hidden` on iframes. Users who zoom in or enlarge text need to scroll to reach content that overflows.
+
+### Code Examples
+
+```html
+<!-- Good: Distinct title and language declaration -->
+<html lang="en">
+<head>
+  <title>Analytics Reports | Guidance Platform</title>
+</head>
+<body>
+  <p>The motto is <span lang="la">"Carpe diem"</span>.</p>
+  <iframe title="Interactive Sales Chart" src="/chart"></iframe>
+</body>
+</html>
+```
+
+## 5. Keyboard and Focus Management
+
+### Actionable Guidelines
+
+#### DOs
+- **Logical Tab Order**: Ensure tab order matches visual layouts (top-to-bottom).
+- **Visible Focus Indicators**: Always style `:focus-visible` states explicitly. If disabling defaults, provide overrides with sufficient contrast.
+- **Custom Trigger Keyboards**: Attach Enter/Space handlers for custom simulated interactive elements. When implementing a custom keyboard handler for button-like elements, `Enter` should be a `keydown` handler and `Space` should be a `keyup` handler (matching native `<button>` behavior where `Enter` repeats and `Space` triggers on release).
+- **Use `tabindex` deliberately**: Anything focusable — by keyboard or programmatically — should have an implicit or explicit ARIA role, so don't make every element focusable. When focus is needed, choose `tabindex="0"` to add the element to the tab order or `tabindex="-1"` to make it programmatically focusable only (e.g., a skip-link target).
+- **Manage Toggle States**: Utilize `aria-expanded` and `aria-pressed` to communicate toggle states for custom controls.
+
+#### DON'Ts
+- **Don't disable outlines without replacements**: Avoid `outline: none` without styling alternatives.
+- **Don't use Positive Tabindex values**: Never use `tabindex="1"` or greater.
+- **Don't hide interactive elements from screen readers**: Avoid `aria-hidden="true"` or `role="presentation"` on elements that can receive focus.
+
+### Code Examples
+
+```css
+/* Good: High contrast focus border */
+:where(a:any-link, button):focus-visible {
+  outline: 3px solid #ff0055;
+  outline-offset: 3px;
+}
+```
+
+```html
+<!-- Good: Skip to main content -->
+<a href="#content" class="skip-link">Skip to main content</a>
+<main id="content" tabindex="-1">...</main>
+```
+
+```javascript
+// Good: Keyboard handlers for complex custom widgets (e.g., Tree items, tabs).
+// NOTE: This pattern applies ONLY to non-standard UI where no native HTML tag exists.
+// Always prioritize native <button> or <input> elements for standard interactions.
+// Elements MUST have the appropriate ARIA role (e.g., role="treeitem" or role="tab").
+customWidget.addEventListener('keydown', (e) => {
+  if (e.key === 'Enter') {
+    toggleWidgetState();
+  }
+  if (e.key === ' ') {
+    e.preventDefault(); // Prevent page scrolling on Spacebar keydown
+  }
+});
+
+customWidget.addEventListener('keyup', (e) => {
+  if (e.key === ' ') {
+    toggleWidgetState();
+  }
+});
+
+function toggleWidgetState() {
+  // E.g., Manage toggle/expanded states for custom controls
+  const isExpanded = customWidget.getAttribute('aria-expanded') === 'true';
+  customWidget.setAttribute('aria-expanded', !isExpanded);
+}
+```
+
+## 6. Alternate Text and Media
+
+### Actionable Guidelines
+
+#### DOs
+- **Informative Visual Descriptions**: Describe the purpose of the image (e.g., "Search", not "Magnifying glass").
+- **Empty Alt properties for decorative visuals**: Use `alt=""` to remove decorative images from the accessibility tree so they aren't announced.
+- **Synchronous Captions for videos**: Supply WebVTT captions for video tracks.
+- **Transcripts for audio**: Provide text transcripts for purely audio podcasts.
+- **Informative View Descriptions for inline SVGs**: Apply `role="img"` and a nested `<title>` tag for informative visuals.
+- **Decorative SVGs removal**: Apply `aria-hidden="true"` to remove decorative SVGs from reading flows.
+- **Long descriptions for complex images**: Use `<figure>`/`<figcaption>` or `aria-describedby` for charts and infographics.
+- **Provide data tables as alternatives**: Consider providing semantic data tables as accessible alternatives for charts and other complex data visualizations.
+
+#### DON'Ts
+- **Don't use clichéd prefixes**: Avoid "Image of..." or "Picture of...".
+- **Don't use underscores in filenames**: Use dashes if the filename might be announced as fallback.
+
+### Code Examples
+
+```html
+<!-- Decorative -->
+<img src="divider.png" alt="">
+
+<!-- Inline Decorative SVG (remove from tab flow) -->
+<svg aria-hidden="true" viewBox="0 0 24 24">
+  <path d="M10 20v-6h4v6h5v-8h3L12 3 2 12h3v8z"/>
+</svg>
+
+<!-- Informative (Functional) -->
+<a href="/search">
+  <img src="glass.png" alt="Search the platform">
+</a>
+
+<!-- Video with Captions tracks -->
+<video controls>
+  <source src="intro.mp4" type="video/mp4">
+  <track src="caps.vtt" kind="captions" srclang="en" label="English">
+</video>
+
+<!-- Complex graph with figcaption -->
+<figure>
+  <img src="chart.png" alt="Sales growth graph 2024.">
+  <figcaption>Sales grew 20% in Q3 due to new platform launch.</figcaption>
+</figure>
+
+<!-- Audio with expandable transcript details -->
+<audio controls src="podcast.mp3" aria-details="podcast-transcript"></audio>
+<details id="podcast-transcript">
+  <summary>View Transcript</summary>
+  <div class="transcript-content">
+    Welcome to the show...
+  </div>
+</details>
+```
+
+### Content Visibility Decision Matrix
+
+| Intent | Visual | Screen Reader | Focusable | Structural Pattern |
+| :--- | :--- | :--- | :--- | :--- |
+| **Visible to all** | Yes | Yes | Yes | Standard rendering |
+| **Screen Reader only** | No | Yes | Yes (if interactive) | Visually hidden utility (e.g. `.visually-hidden`) |
+| **Visual only** | Yes | No | No | `aria-hidden="true"` / `role="presentation"` |
+| **Hidden for all** | No | No | No | `hidden` attribute / `display: none` |
+
+**Heuristic Rule**: If an element can receive keyboard focus, it must not be hidden via `aria-hidden="true"`.
+
+## 7. Forms and Input Controls
+
+### Actionable Guidelines
+
+#### DOs
+- **Connect Labels Programmatically**: Use `<label for="id">` linked to `<input id="id">`.
+- **Use Autocomplete**: Set valid standard `autocomplete` options (e.g., `"email"` or `"given-name"`) for user profiles.
+- **Link hints to inputs via `aria-describedby`**: Associate help text with inputs, and place the hint above the input so autocomplete popovers don't cover it during editing.
+- **Announce dynamic errors via live regions**: Use `aria-live` or shift focus to error lists.
+- **Provide form validation constraints**: Use `required` (or `aria-required="true"` only when `required` isn't applicable) to signal mandatory inputs.
+
+#### DON'Ts
+- **Don't use placeholders as labels**: Placeholders are not persistent labels.
+- **Don't trigger context shifts on focus changes**: Avoid auto-submitting forms or jumping pages on focus change events alone.
+
+### Code Examples
+
+```html
+<!-- Good: Semantic forms with hints for passwords -->
+<form>
+  <label for="pwd">Password:</label>
+  <span id="pwd-hint">Must contain at least 8 characters.</span>
+  <input id="pwd" type="password" aria-describedby="pwd-hint" autocomplete="current-password" required>
+</form>
+```
+
+## 8. Live Regions
+
+Live regions let assistive tech announce content updates that aren't tied to navigation or focus changes. They're easy to misuse — too many regions, or noisy ones, quickly become spam for screen-reader users.
+
+### Live Region Urgency Table
+
+| Urgency | Visual Analogue | `aria-live` Value | Behavioral Impact | Example |
+| :--- | :--- | :--- | :--- | :--- |
+| **Critical** | Modal / Alert | `assertive` (or `role="alert"`) | Interrupts immediately, clears speech queue | Session timeout, API failure |
+| **Standard**| Toast / Banner | `polite` | Announces at next graceful break | Search results, "Saved" status |
+| **Passive**  | Silent text | `off` | Only if user navigates to it | Live character count |
+
+**Heuristic Rule**: Use `assertive` only for critical, time-sensitive updates that require immediate attention or prevent safe continuation (e.g., data loss, session timeouts, or network drops).
+
+### Actionable Guidelines
+
+#### DOs
+- **Centralize live regions for non-visible announcements**: A single `polite` region and a single `assertive` region per page (with whatever `aria-atomic` configuration you need) keeps announcements consistent and easier to maintain. Many frameworks ship their own announcer abstraction — use it.
+- **Debounce frequently-changing regions**: If a region can update many times per second (e.g. a combobox's result count as the user types), debounce so users aren't spammed.
+- **Delay slightly when other announcements may collide**: When the user is typing or focus is being managed, a small delay before announcing keeps live-region updates from overlapping other speech.
+
+#### DON'Ts
+- **Don't use live regions for interstitial states** like "Loading…" or "Updating…" unless they're meaningfully informative — they usually just create noise.
+- **Don't add live-region updates to inert DOM**: When dialogs open or sections become `inert`, queued or debounced messages can end up unannounced — or announced from DOM the user can't reach. Coordinate live-region updates with dialog/inert state changes.
+
+### Code Example
+
+```html
+<!-- Session Timeout Warning with controls -->
+<div role="alert" class="timeout-warning">
+  Your session will expire in 2 minutes. 
+  <button type="button" onclick="extendSession()">Extend Session</button>
+</div>
+```
+
+## 9. Color, Contrast, and Typography
+
+### Actionable Guidelines
+
+#### DOs
+- **Minimum contrast standards**: Maintain 4.5:1 for normal text and 3:1 for large text or icons.
+- **Ensure non-text contrast standards**: Maintain a minimum contrast ratio of 3:1 for user interface component boundaries and states.
+  - This includes visual elements (borders, backgrounds, box-shadows, underlines) that form the boundary or indicate the presence of a UI component (e.g., input field borders).
+  - This also includes visual elements indicating active states within a component (e.g., checkbox checkmarks or switch thumbs).
+  - **Caveat**: Meeting 3:1 non-text contrast can challenge minimalistic designs. Soft gradients or subtle inset/outset shadows can soften visual boundaries while satisfying accessibility requirements.
+- **Use multiple state indicators**: Do not denote success/errors ONLY with color. Use icons or text.
+- **Relative font size units**: Use `rem` or `em` for font sizes instead of `px`.
+- **Consistent or Start alignment**: Avoid `justify` alignment as it can be more difficult to read.
+- **Avoid long lines of text**: Cap paragraph blocks to a maximum of 80 characters width.
+- **Support user zoom preferences**: Allow users to resize text up to 200% without loss of content or functionality.
+- **Support light and dark color schemes**: Honor `@media (prefers-color-scheme: dark)` and pair it with the `color-scheme` CSS property so form controls, scrollbars, and other UA-rendered surfaces match.
+- **Use `prefers-contrast` only when warranted**: Reach for `@media (prefers-contrast: more)` when the design uses low-contrast accents (e.g., subtle borders, muted secondary text) that need to be reinforced; most sites that already meet baseline contrast won't need it.
+
+#### DON'Ts
+- **Don't use color alone to indicate the presence of a user interface component or its state**: Use iconography and/or shape to help differentiate.
+- **Don't use Justified Text Alignment**: Avoid `text-align: justify`.
+- **Don't use Ornate fonts**: Omit cursive typefaces for main reading content.
+- **Don't rely on all-caps for emphasis**: Prefer bolding for visual emphasis, and use `<em>`/`<strong>` when the emphasis is semantic.
+- **Limit emphasis overall**: Emphasis loses meaning when it's everywhere — apply it only where it changes how the content should be read.
+
+### Code Examples
+
+```css
+/* Good: Relative sizing and line caps */
+body {
+  line-height: 1.5;
+  text-align: start; /* Supports LTR and RTL */
+}
+article {
+  max-width: 80ch; /* Caps line length to ~80 characters for readability */
+}
+```
+
+```html
+<!-- Good: Denotes state without colors alone -->
+<div class="error-msg">
+  <span aria-hidden="true">❌</span>
+  <span>The password entered was invalid.</span>
+</div>
+```
+
+```css
+/* Dark Mode support variables */
+:root {
+  --bg-color: #ffffff;
+  --text-color: #212529;
+}
+@media (prefers-color-scheme: dark) {
+  :root {
+    --bg-color: #121212;
+    --text-color: #f8f9fa;
+  }
+}
+```
+
+## 10. Motions and Preferences
+
+### Actionable Guidelines
+
+#### DOs
+- **Support Reduced Motion media queries**: Support `@media (prefers-reduced-motion: reduce)` media queries.
+- **Provide Pause mechanism**: Allow users to stop auto-running carousels banners or other persistent animations.
+- **Default to static views**: Consider defaulting to static states and allowing users to opt-in to motion.
+
+#### DON'Ts
+- **Don't exceed flash limits (three per second)**: Never include rapid light-to-dark flashing. Such effects can cause seizures.
+
+### Code Examples
+
+```css
+/* Good: Dampen spin states for reduced motion queries */
+@media (prefers-reduced-motion: reduce) {
+  .spinner {
+    animation: none;
+    opacity: 0.5;
+  }
+}
+```
+
+## 11. Modals and Native Dialogs
+
+Modern browsers provide native solutions for creating modal dialogs which avoid the need for focus traps, managing the accessibility of outside content, ensuring the content is on top, and dimming the background content — all of which can be error prone and require heavy JavaScript event tracking to maintain.
+
+### Actionable Guidelines
+
+#### DOs
+- **Use the Native `<dialog>` Element**: Invoke the dialog using the `.showModal()` method to open it in a modal state. When in a modal state, the browser sets outside content as inert (i.e. the outside content is hidden from the accessibility tree and cannot be interacted with nor be focused).
+- **Use the `inert` Attribute for Custom Overlays**: When `<dialog>` cannot be used (e.g., some non-modal overlays, framework constraints, or layouts where `<dialog>`'s top-layer/positioning behavior conflicts with the design), apply `inert` to outside content to ensure it cannot be interacted with by keyboard, pointer, or assistive technology. This requires structuring elements in such a way that the custom overlay is not a descendant of the element with `inert` set on it.
+
+#### DON'Ts
+- **Don't implement focus traps for native modal dialogs**: When a `<dialog>` element is opened in a modal state, browsers set outside content as inert which is sufficient for ensuring only the dialog’s content can be focused.
+
+### Code Examples
+
+**HTML & JS: Native `<dialog>` with standard close events**
+```html
+<!-- Dialog opens natively with showModal() and locks focus -->
+<button id="open-btn">Open Dialog</button>
+
+<dialog id="accessible-modal" aria-labelledby="title-id">
+  <h2 id="title-id">Account Settings</h2>
+  <p>Update your details here.</p>
+  <button onclick="this.closest('dialog').close()">Close Dialog</button>
+</dialog>
+
+<script>
+  document.getElementById('open-btn').addEventListener('click', () => {
+    document.getElementById('accessible-modal').showModal();
+  });
+</script>
+```
+
+## 12. Testing Validations
+
+### Actionable Guidelines
+
+#### DOs
+- **Run Automated checks via axe-core or Lighthouse audits**: Catch missing alt texts or low contrasts (e.g., via Lighthouse in Chrome DevTools MCP).
+- **Validate Sequential Navigations using keyboards alone**: Using only keyboard shortcuts, such as Tab/Shift+Tab, arrow keys, Enter, Space, and Esc, confirm every interactive element is reachable and operable, and that focus never gets stuck.
+- **Test on Screen Readers with calibrated browsers**: Rely on standard bindings (e.g., JAWS with Chrome, NVDA with Firefox, Narrator with Edge, VoiceOver with Safari on macOS and iOS, TalkBack with Chrome for Android).
+
+#### DON'Ts
+- **Don't rely purely on scores**: A 100% score does not guarantee real usability.

package/.agents/skills/modern-web-guidance/guides/accessibility/accessible-error-announcement.md

@@ -0,0 +1,207 @@
+# Accessible Error Announcement
+
+## The Problem
+Standard HTML5 validation provides visual feedback (via `:invalid` or `:user-invalid`), but it doesn't automatically synchronize with accessibility attributes like `aria-invalid`. 
+
+If you use standard `:invalid` styling, screen readers might announce "Invalid entry" the moment a user tabs into a required field that is currently empty. This creates a disruptive experience for users using assistive technologies, as the error is announced before interaction has occurred.
+
+## The Solution
+We want the *programmatic* state (`aria-invalid="true"`) to be applied **at the exact same moment** the *visual* state (`:user-invalid`) applies. Since `:user-invalid` relies on the browser's internal "user-interacted" flag, we can use JavaScript to check that this selector matches during standard interaction events.
+
+See [MDN aria-invalid](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-invalid) for more details.
+
+### Implementation Strategy
+
+1.  **Visual Layer**: Use CSS `:user-invalid` to show borders/icons.
+2.  **Accessibility Layer**: Use `aria-invalid` and `aria-errormessage` to communicate state to Assistive Technology (AT).
+3.  **Bridge Visual & Accessibility Layer**: Create a lightweight JavaScript utility that listens for `blur` and `input` events, checks if the element matches `:user-invalid`, and updates the ARIA attributes accordingly.
+
+## Implementation Guide
+
+### 1. HTML Structure
+Link your input to its error message using `aria-errormessage` (or `aria-describedby` for broader support).
+
+```html
+<form>
+  <div class="field">
+    <label for="email">Email</label>
+    <input 
+      type="email" 
+      id="email" 
+      required 
+      aria-errormessage="email-error"
+    >
+    <span id="email-error" class="error-msg">
+      Please enter a valid email address.
+    </span>
+  </div>
+</form>
+```
+
+### 2. CSS
+Control the visibility of the error message using the native pseudo-class `:user-invalid`.
+
+```css
+.error-msg {
+  display: none;
+  color: #d93025;
+}
+
+/* Show error message when input is user-invalid */
+input:user-invalid ~ .error-msg {
+  display: block;
+}
+
+/* Optional: Visual cues on the input itself */
+input:user-invalid {
+  border-color: #d93025;
+}
+```
+
+### 3. JavaScript
+Since there is no "UserInvalidChanged" event, hook into standard form events to check the state.
+
+```javascript
+const updateAriaState = (event) => {
+  const input = event.target;
+  if (!input.matches?.('input, textarea, select')) return;
+
+  // Check if the browser currently considers this input "user-invalid"
+  const isUserInvalid = input.matches(':user-invalid');
+  
+  if (isUserInvalid) {
+    input.setAttribute('aria-invalid', 'true');
+  } else {
+    input.removeAttribute('aria-invalid');
+  }
+};
+
+// Listen on the document to handle dynamically added fields.
+// 'blur' and 'focus' do not bubble, so we must use the capture phase (true).
+document.addEventListener('blur', updateAriaState, true);
+document.addEventListener('focus', updateAriaState, true);
+
+// Also update on input if we've already shown the error, 
+// so the error clears immediately when fixed.
+document.addEventListener('input', (event) => {
+  const input = event.target;
+  if (!input.matches?.('input, textarea, select')) return;
+
+  const hasAriaInvalid = input.hasAttribute('aria-invalid');
+  const ariaInvalid = input.getAttribute('aria-invalid');
+  if (hasAriaInvalid && ariaInvalid === 'true') {
+    updateAriaState(event);
+  }
+});
+```
+
+## Fallbacking & Browser Support
+
+The `:user-invalid` pseudo-class is widely supported (Baseline 2023), but older browsers need a fallback.
+
+### Feature Detection
+You can check for support in CSS and JavaScript.
+
+**JavaScript Check:**
+```javascript
+if (!CSS.supports('selector(:user-invalid)')) {
+  // Fallback logic here
+}
+```
+
+### CSS for Fallback
+To ensure your fallback logic is visually indistinguishable from the native behavior, you must apply your error styles to both the pseudo-class and your fallback class.
+
+```css
+/* Apply error styles to both native selector and fallback class */
+input:user-invalid,
+input.user-invalid-fallback {
+  border-color: #d93025;
+  background-color: #fce8e6;
+}
+
+/* Show error message for both cases */
+input:user-invalid ~ .error-msg,
+input.user-invalid-fallback ~ .error-msg {
+  display: block;
+}
+```
+
+### Fallback Logic
+If `:user-invalid` is missing manually track the interaction state using a `WeakMap`.
+
+```javascript
+const UserInvalidFallback = (() => {
+  const dirtyState = new WeakMap();
+
+  const updateState = (input) => {
+    const isValid = input.checkValidity();
+
+    // Update both visual and ARIA state
+    input.classList.toggle('user-invalid-fallback', !isValid);
+    input.classList.toggle('user-valid-fallback', isValid);
+
+    if (!isValid) {
+      input.setAttribute('aria-invalid', 'true');
+    } else {
+      input.removeAttribute('aria-invalid');
+    }
+  };
+
+  const handleEvent = (event) => {
+    const input = event.target;
+
+    if (event.type === 'reset' && input.matches?.('form')) {
+      const controls = input.elements || [];
+      for (const control of controls) {
+        dirtyState.delete(control);
+        control.classList.remove('user-invalid-fallback');
+        control.classList.remove('user-valid-fallback');
+        control.removeAttribute('aria-invalid');
+      }
+      return;
+    }
+
+    if (!input.matches?.('input, textarea, select')) return;
+
+    if (event.type === 'input' || event.type === 'change') {
+      const state = dirtyState.get(input) || { hasInteracted: false, hasBlurred: false };
+      state.hasInteracted = true;
+      dirtyState.set(input, state);
+      if (state.hasBlurred) {
+        updateState(input);
+      }
+    } else if (event.type === 'blur') {
+      const state = dirtyState.get(input) || { hasInteracted: false, hasBlurred: false };
+      state.hasBlurred = true;
+      dirtyState.set(input, state);
+      if (state.hasInteracted) {
+        updateState(input);
+      }
+    }
+  };
+
+  const init = () => {
+    if (CSS.supports('selector(:user-invalid)')) return;
+
+    document.addEventListener('blur', handleEvent, true); // Capture phase required
+    document.addEventListener('input', handleEvent, true);
+    document.addEventListener('change', handleEvent, true);
+    document.addEventListener('reset', handleEvent, true); // Capture resets
+  };
+
+  return { init };
+})();
+
+// Initialize globally
+UserInvalidFallback.init();
+```
+
+## Other Considerations
+
+1.  **`aria-live` vs. `aria-errormessage`**: 
+    *   `aria-errormessage` connects the input to the text, but screen readers might not announce it immediately upon appearance (only when focusing the input).
+    *   If you need *immediate* announcement when the error appears (e.g., on blur), consider adding `role="alert"` or `aria-live="polite"` to the error message container, but test thoroughly to avoid "double announcement" when the user focuses the field to fix it.
+
+2.  **Internationalization**:
+    *   Ensure the text content of your error message (`#email-error`) is translated. The logic remains the same.