MCP

https://gemini-design-mcp.com/

https://github.com/mcp

Markdown :

https://markdown-ui.blueprintlab.io/

Turn LLM responses into real UI

Accessibility - Vibe Coding :

https://idea11y.dev/VibeCheck/

Agend.md :

https://www.humanlayer.dev/blog/writing-a-good-claude-md

https://agents.md/

Articles :

How LLMs Actually Work

https://www.0xkato.xyz/how-llms-actually-work/

AI has an accessibility problem

What devs can do about it https://blog.logrocket.com/ai-has-an-accessibility-problem/

Documentation

https://gerireid.com/blog/can-ai-write-accessibility-specs/

Claude Code for writers

https://www.platformer.news/claude-code-for-writers-tips-ideas/

A designer’s framework for better AI prompts

https://www.figma.com/blog/designer-framework-for-better-ai-prompts/

1 - Accessibility Coding Guidelines

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 the page in <header>, <nav>, <main>, <aside>, and <footer> 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

<!-- 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 hrefs.
• 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.

/* 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

<!-- 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

/* Good: High contrast focus border */
:where(a:any-link, button):focus-visible {
  outline: 3px solid #ff0055;
  outline-offset: 3px;
}

<!-- Good: Skip to main content -->
<a href="#content" class="skip-link">Skip to main content</a>
<main id="content" tabindex="-1">...</main>

// 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

<!-- 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

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

<!-- 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

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

<!-- 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

/* 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 */
}

<!-- Good: Denotes state without colors alone -->
<div class="error-msg">
  <span aria-hidden="true">❌</span>
  <span>The password entered was invalid.</span>
</div>

/* 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

/* 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

<!-- 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.

2 - Accessible Error Announcement

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 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).

<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.

.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.

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:

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.

/* 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.

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.

3 - AI Prompts For Web Accessibility Testing

1. Missing Alt Text For Images

Missing alt text is one of the most common accessibility failures and also one of the easiest to fix. With a CSV export of your site’s images, file names, sections and surrounding text, you can ask AI to generate accessible alt text suggestions, which you can then refine and apply. AI Prompt To Use:

“You are a web accessibility reviewer. I will give you images with file name, section, and surrounding text. Write descriptive alt text under 120 characters that reflects the image’s purpose in context. Do not use phrases like “image of” or “picture of.” If decorative, return an empty alt. If a logo, include the brand name followed by “logo.” If the image has important text, include that text in the alt. Output each in plain text as: [file name] → [alt text]. Here is the list of images: [insert list].”

2. Insufficient Color Contrast

Muted tones, overlays and stylish grays often fail WCAG SC 1.4.3 (minimum contrast), which requires at least 4.5:1 contrast for normal text and 3:1 for large text. Proper contrast helps users with low vision or color blindness read web content more easily. AI Prompt To Use:

“Act like an expert in inclusive design and accessibility. I will provide foreground and background color pairs. For each pair, calculate the contrast ratio, check if it meets WCAG 2.2 SC 1.4.3 (4.5:1 normal text, 3:1 large text) and, if it fails, suggest one or two close alternative hex codes that meet WCAG. Return results in this format: [foreground] on [background] → Contrast ratio: [X:1] → [Pass/Fail for normal text, Pass/Fail for large text] → [Alternatives if any]. Here are the colors to check: [insert foreground color] on [insert background color]” (insert more color pairs as needed).

3. Poor Heading Structure

Headings are essential for screen reader navigation, so when levels are skipped or misused (like jumping from

to

), webpages become harder to scan, affecting both accessibility and SEO. A simple way to check your webpage’s heading structure is with tools like HeadingsMap or WAVE. AI Prompt To Use:

“Analyze this HTML: [insert HTML or extracted heading structure] and check if the headings follow a logical hierarchy. Flag any skipped or misordered levels and briefly explain why they are problematic. Suggest corrected heading tags that maintain semantic clarity and proper nesting.”

4. Unlabeled Form Fields

Form fields without labels are invisible to screen readers, making them confusing for users with cognitive disabilities and unusable with voice input. They also reduce conversions, because if people can’t complete forms, they can’t fully engage with your site. AI Prompt To Use:

“Act like an accessible front-end developer and review this HTML form: [insert form code]. Check if every input has a properly associated or equivalent ARIA attribute. Verify that required fields and error messages are programmatically associated. Ensure that appropriate autocomplete attributes are used so the form does not fail WCAG 1.3.5. Then rewrite the form code with accessibility fixes applied, keeping the original structure intact. Return only the improved HTML snippet.” 5. Inaccessible Keyboard Navigation

Keyboard users must be able to reach and operate every interactive element with the tab, enter, and space keys. When focus order skips around or elements aren’t reachable, it breaks the user’s experience, hurting usability and conversions. AI Prompt To Use:

“Review this DOM snippet: [paste code]. Return an improved version that’s keyboard accessible: replace clickable non-interactive elements with buttons/links, add hrefs to anchors, remove positive tabindex, ensure logical focus order, add a “Skip to content” link to #main and make focus visible via :focus-visible, and ensure keyboard activation mirrors click. Keep original structure/styles where possible.”

6. Empty Or Nondescriptive Links

Links like “Click Here” or empty anchors give no context to screen reader users and can weaken usability for everyone. AI can rewrite them into clear, action-oriented text if given the links’ URLs, surrounding context and destination descriptions. AI Prompt To Use:

“Review these links and rewrite the visible link text so the purpose/destination is clear from the text itself (no “click here,” “learn more,” or “read more”). Keep it concise (3–7 words), sentence case, and avoid trailing punctuation. If a link downloads a file or opens a new tab, include that in parentheses at the end (e.g., “PDF,” “opens in new tab”). Return only the improved link texts paired with their hrefs in this format: [href] → [new link text]

Links to review:

(i) href: [insert URL] | current text: [insert current text] | surrounding: [insert sentence/heading] | destination description: insert (insert other hrefs in the same format as (i) above).”

7. Complex Tables Without Semantic Structure

Tables without proper headers or attributes are unreadable to screen readers. This is especially problematic in dashboards, pricing grids and other data-heavy layouts where users need to know which data belongs to which header. AI Prompt To Use:

“Review this table HTML: [paste table code]. Rewrite it with correct semantic markup so it is accessible to screen readers. Addelements for headers, use scope=“col” and scope=“row” where appropriate, and ensure multi-level headers are properly nested. Return only the corrected table code.”

Once you generate fixes with these prompts, always review them manually. Accessibility should never be treated as just a compliance checkbox; it should be about creating digital experiences that work for everyone. I have found that, when used thoughtfully, prompts like these can help teams move faster, lower risks and stay ahead of legal and user expectations.

4 - Content Accessibility Checker Prompt for ChatGPT, Gemini & Claude

You are a highly experienced accessibility consultant with expertise in WCAG (Web Content Accessibility Guidelines) and other accessibility standards. You have a deep understanding of the challenges faced by users with disabilities and are skilled at providing practical, actionable recommendations for improving digital content accessibility. You are known for your thoroughness, attention to detail, and ability to communicate complex technical concepts in a clear and concise manner. Your goal is to provide clear, actionable advice to content creators of all skill levels.

Your task is to analyze a piece of content ([Content Type]: [Specify content type, e.g., website page, document, email, social media post]) provided as [Content Format]: [Specify content format, e.g., HTML, DOCX, TXT, etc.]. The content addresses the topic of: [Content Topic]. Based on your analysis, you will provide a detailed accessibility report and actionable recommendations for improvement.

The goal is to make the content conform to WCAG [WCAG Version, e.g., 2.1] Level [WCAG Level, e.g., AA] standards.

The user specifies the content by providing the actual content or a URL to the content. For example, the user might provide the following HTML snippet:

[Example Content]

Output Structure:

The report should be structured into the following sections:

I. Executive Summary: A brief overview of the content's current accessibility status and the key areas for improvement. Highlight the most critical issues first.

II. Detailed Findings: A comprehensive breakdown of accessibility issues, organized by WCAG principle (Perceivable, Operable, Understandable, Robust). For each issue, provide the following information:

A. WCAG Guideline Violated: (e.g., 1.1.1 Non-text Content) B. Description of the Issue: (A clear explanation of the problem and why it matters for users with disabilities.) C. Location in Content: (Specify where the issue occurs, e.g., line number, element ID, etc.) D. Impact on Users: (Explain how the issue affects users with specific disabilities, e.g., screen reader users, keyboard-only users, users with cognitive impairments) E. Recommended Solution: (Provide specific, actionable steps to fix the issue, including code examples where applicable.)

III. Recommendations Prioritized by Severity: A list of the recommendations from Section II, sorted by their severity (Critical, High, Medium, Low). Explain how you determined the level of severity. For example:

A. Critical: Issues that prevent users with disabilities from accessing essential content or functionality. B. High: Issues that significantly impair the user experience for people with disabilities. C. Medium: Issues that cause inconvenience or difficulty for users with disabilities. D. Low: Minor issues that do not significantly impact accessibility but should be addressed for best practices.

IV. Tools Used: A list of accessibility testing tools and techniques you used to evaluate the content (e.g., screen readers, automated accessibility checkers, manual code review).

Tone and Style:

• The tone should be professional, objective, and constructive.
• Avoid technical jargon unless it is clearly explained.
• Focus on providing practical, actionable advice.
• Be specific and avoid vague recommendations.
• Explain the 'why' behind each recommendation (i.e., how it benefits users with disabilities).

5 - Have you ever felt concerned about the size of your AGENTS.md file?

Maybe you should be. A bad AGENTS.md file can confuse your agent, become a maintenance nightmare, and cost you tokens on every request.

So you’d better know how to fix it.

What is AGENTS.md?

An AGENTS.md file is a markdown file you check into Git that customizes how AI coding agents behave in your repository. It sits at the top of the conversation history, right below the system prompt.

Think of it as a configuration layer between the agent’s base instructions and your actual codebase. The file can contain two types of guidance:

• Personal scope: Your commit style preferences, coding patterns you prefer
• Project scope: What the project does, which package manager you use, your architecture decisions

The AGENTS.md file is an open standard supported by many - though not all - tools. CLAUDE.md

Why Massive AGENTS.md Files are a Problem

There’s a natural feedback loop that causes AGENTS.md files to grow dangerously large:

The agent does something you don't like
 
You add a rule to prevent it
 
Repeat hundreds of times over months
 
File becomes a "ball of mud"

Different developers add conflicting opinions. Nobody does a full style pass. The result? An unmaintainable mess that actually hurts agent performance.

Another culprit: auto-generated AGENTS.md files. Never use initialization scripts to auto-generate your AGENTS.md. They flood the file with things that are “useful for most scenarios” but would be better progressively disclosed. Generated files prioritize comprehensiveness over restraint. The Instruction Budget

Kyle from Humanlayer’s article mentions the concept of an “instruction budget”:

Frontier thinking LLMs can follow ~ 150-200 instructions with reasonable consistency. Smaller models can attend to fewer instructions than larger models, and non-thinking models can attend to fewer instructions than thinking models.

Every token in your AGENTS.md file gets loaded on every single request, regardless of whether it’s relevant. This creates a hard budget problem: Scenario Impact Small, focused AGENTS.md More tokens available for task-specific instructions Large, bloated AGENTS.md Fewer tokens for the actual work; agent gets confused Irrelevant instructions Token waste + agent distraction = worse performance

Taken together, this means that the ideal AGENTS.md file should be as small as possible. Stale Documentation Poisons Context

Another issue for large AGENTS.md files is staleness.

Documentation goes out of date quickly. For human developers, stale docs are annoying, but the human usually has enough built-in memory to be skeptical about bad docs. For AI agents that read documentation on every request, stale information actively poisons the context.

This is especially dangerous when you document file system structure. File paths change constantly. If your AGENTS.md says “authentication logic lives in src/auth/handlers.ts " and that file gets renamed or moved, the agent will confidently look in the wrong place.

Instead of documenting structure, describe capabilities. Give hints about where things might be and the overall shape of the project. Let the agent generate its own just-in-time documentation during planning.

Domain concepts (like “organization” vs “group” vs “workspace”) are more stable than file paths, so they’re safer to document. But even these can drift in fast-moving AI-assisted codebases. Keep a light touch. Cutting Down Large AGENTS.md Files

Be ruthless about what goes here. Consider this the absolute minimum:

One-sentence project description (acts like a role-based prompt)
 
Package manager (if not npm; or use corepack for warnings)
 
Build/typecheck commands (if non-standard)

That’s honestly it. Everything else should go elsewhere. The One-Liner Project Description

This single sentence gives the agent context about why they’re working in this repository. It anchors every decision they make.

Example:

This is a React component library for accessible data visualization.

That’s the foundation. The agent now understands its scope. Package Manager Specification

If you’re In a JavaScript project and using anything other than npm, tell the agent explicitly:

This project uses pnpm workspaces.

Without this, the agent might default to npm and generate incorrect commands. Corepack is also great

Instead of cramming everything into AGENTS.md, use progressive disclosure: give the agent only what it needs right now, and point it to other resources when needed.

Agents are fast at navigating documentation hierarchies. They understand context well enough to find what they need. Move Language-Specific Rules to Separate Files

If your AGENTS.md currently says:

Always use const instead of let. Never use var. Use interface instead of type when possible. Use strict null checks. …

Move that to a separate file instead. In your root AGENTS.md:

For TypeScript conventions, see docs/TYPESCRIPT.md

Notice the light touch, no “always,” no all-caps forcing. Just a conversational reference.

The benefits:

TypeScript rules only load when the agent writes TypeScript
 
Other tasks (CSS debugging, dependency management) don't waste tokens
 
File stays focused and portable across model changes

Nest Progressive Disclosure

You can go even deeper. Your docs/TYPESCRIPT.md can reference docs/TESTING.md. Create a discoverable resource tree:

docs/ ├── TYPESCRIPT.md │ └── references TESTING.md ├── TESTING.md │ └── references specific test runners └── BUILD.md └── references esbuild configuration

You can even link to external resources, Prisma docs, Next.js docs, etc. The agent will navigate these hierarchies efficiently. Use Agent Skills

Many tools support “agent skills” - commands or workflows the agent can invoke to learn how to do something specific. These are another form of progressive disclosure: the agent pulls in knowledge only when needed.

We’ll cover agent skills in-depth in a separate article. AGENTS.md in Monorepos

You’re not limited to a single AGENTS.md at the root. You can place AGENTS.md files in subdirectories, and they merge with the root level.

This is powerful for monorepos: What Goes Where

Root AGENTS.md:

This is a monorepo containing web services and CLI tools. Use pnpm workspaces to manage dependencies. See each package’s AGENTS.md for specific guidelines.

Package-level AGENTS.md (in packages/api/AGENTS.md):

This package is a Node.js GraphQL API using Prisma. Follow docs/API_CONVENTIONS.md for API design patterns.

Don’t overload any level. The agent sees all merged AGENTS.md files in its context. Keep each level focused on what’s relevant at that scope. Fix A Broken AGENTS.md With This Prompt

If you’re starting to get nervous about the AGENTS.md file in your repo, and you want to refactor it to use progressive disclosure, try copy-pasting this prompt into your coding agent:

I want you to refactor my AGENTS.md file to follow progressive disclosure principles.

Follow these steps:

1. Find contradictions: Identify any instructions that conflict with each other. For each contradiction, ask me which version I want to keep.

2. Identify the essentials: Extract only what belongs in the root AGENTS.md:

   • One-sentence project description
   • Package manager (if not npm)
   • Non-standard build/typecheck commands
   • Anything truly relevant to every single task

3. Group the rest: Organize remaining instructions into logical categories (e.g., TypeScript conventions, testing patterns, API design, Git workflow). For each group, create a separate markdown file.

4. Create the file structure: Output:

   • A minimal root AGENTS.md with markdown links to the separate files
   • Each separate file with its relevant instructions
   • A suggested docs/ folder structure

5. Flag for deletion: Identify any instructions that are:

   • Redundant (the agent already knows this)
   • Too vague to be actionable
   • Overly obvious (like “write clean code”)

Don’t Build A Ball Of Mud

When you’re about to add something to your AGENTS.md, ask yourself where it belongs: Location When to use Root AGENTS.md Relevant to every single task in the repo Separate file Relevant to one domain (TypeScript, testing, etc.) Nested documentation tree Can be organized hierarchically

The ideal AGENTS.md is small, focused, and points elsewhere. It gives the agent just enough context to start working, with breadcrumbs to more detailed guidance.

Everything else lives in progressive disclosure: separate files, nested AGENTS.md files, or skills.

This keeps your instruction budget efficient, your agent focused, and your setup future-proof as tools and best practices evolve. Share

6 - L’absolutisme de l’IA est en train de nous faire perdre la tête. L’avenir apocalyptique qu’on nous vend n’est pas inévitable

Tout ce que nous entendons sur l’intelligence artificielle est contradictoire, et il semble impossible d’y échapper. L’IA est terrible. L’IA est merveilleuse. Elle va détruire le monde. Elle va transformer l’avenir. Il est essentiel de l’adopter. Il est moralement impératif de refuser de l’utiliser.

Déjà, l’IA devrait générer des revenus presque inimaginables. Au dernier trimestre de 2025, elle représentait près de 60 % de la croissance de l’économie américaine. Déjà, commentateurs et économistes s’inquiètent des catastrophes qui pourraient survenir si la bulle de l’IA venait à éclater.

Depuis la sortie de ChatGPT, le premier grand modèle de langage, fin 2022, plus d’un demi-million de travailleurs ont perdu leur emploi dans le seul secteur technologique. Toute mention de l’IA s’accompagne désormais d’avertissements annonçant des suppressions de postes encore plus importantes dans de nombreux autres secteurs.

En 2025, Jensen Huang, PDG du géant des puces Nvidia, déclarait : « Tous les emplois seront affectés, et immédiatement. C’est incontestable. Vous ne perdrez pas votre emploi à cause d’une IA, mais à cause de quelqu’un qui utilise une IA. »

En janvier, Dario Amodei, PDG d’Anthropic, affirmait : « L’IA n’est pas un substitut à certains emplois humains spécifiques, mais plutôt un substitut général au travail humain. »

De plus en plus de jeunes et de moins jeunes se ruent vers une nouvelle ruée vers l’or dans la Silicon Valley pour travailler sur des start-up alimentées par l’IA. Beaucoup sont moins motivés par un enthousiasme idéaliste que par la peur de manquer le dernier train vers la richesse — et de rester coincés à jamais dans une « sous-classe permanente » qu’ils contribueront eux-mêmes à créer.

Ce que toutes ces visions apocalyptiques, pourtant divergentes, ont en commun, c’est leur absolutisme de l’IA : une manière de voir l’IA comme une force quasi divine qui soit accélérera un âge d’or de la productivité et de l’innovation, soit condamnera l’humanité. Cette vision reflète la polarisation politique de notre époque et même le fanatisme religieux.

Et ce n’est pas un hasard. Aussi contradictoires soient-elles, toutes ces affirmations et inquiétudes s’inscrivent parfaitement dans le message central des personnes qui développent cette technologie : la domination de l’IA est inévitable. Montez à bord ou restez sur le quai. Les nouveaux barons du capitalisme ont tout intérêt à tirer profit non seulement de l’enthousiasme suscité par leur produit vedette, mais aussi de la peur qu’il inspire.

« Si vous voulez justifier cette valorisation gigantesque lors de votre introduction en bourse, vous devez montrer les revenus que vous générerez à l’avenir », explique Suresh Naidu, professeur d’économie à l’université Columbia. « Il suffit de donner l’impression que vous possédez quelque chose capable d’absorber tout le travail de la planète, pour qu’un investisseur se dise : “Je ne veux surtout pas rater ça.” »

Naidu ne conteste pas que l’IA puisse réduire certains emplois ou bouleverser certaines industries. Il qualifie cette technologie de « transformatrice » et affirme l’utiliser quotidiennement dans son travail de chercheur. Mais lorsqu’il prend du recul et replace l’IA et toutes ses promesses dans une perspective historique, il y voit surtout beaucoup d’exagération.

Il n’existe pas de groupe témoin

Anil Dash, ancien PDG de la start-up Glitch et observateur du secteur technologique depuis des décennies, doute lui aussi que l’IA puisse accomplir tout ce que les dirigeants de la tech lui attribuent.

« Toute technologie dans laquelle on investit mille milliards de dollars finira par être capable de faire beaucoup de choses, en bien ou en mal. L’IA représente un bond en avant. Je ne pense pas que nous ayons déjà eu un système d’apprentissage automatique capable d’accomplir autant de tâches. »

Mais, ajoute-t-il, « il y a tellement de bruit qu’il est difficile de savoir dans quels domaines elle est réellement applicable ».

Le développement logiciel constitue une exception. Les résultats produits par une IA sont faciles à vérifier : soit le code fonctionne, soit il ne fonctionne pas. Beaucoup d’autres usages sont plus subjectifs et donc moins susceptibles d’entraîner un remplacement immédiat des travailleurs.

C’est notamment pour cette raison que le secteur technologique a connu jusqu’à présent les suppressions d’emplois les plus importantes. Pourtant, alors que des entreprises comme Amazon, Meta ou Block ont procédé à des licenciements massifs, certains employés affirment que les gains de productivité attribués à l’IA par leurs dirigeants sont largement surestimés.

Même le rôle exact de l’IA dans ces licenciements et dans la réduction des postes de début de carrière reste flou.

Martin Beraja, professeur à la Haas School of Business de l’université de Californie à Berkeley, estime que les études établissant un lien direct entre la sortie de ChatGPT et la baisse des emplois juniors dans le développement logiciel sont « problématiques ».

Selon lui, l’industrie technologique a connu une forte expansion après la pandémie. Puis, lorsque les habitudes de consommation sont revenues du monde numérique vers le monde réel, le secteur s’est retrouvé avec davantage d’employés qu’il n’en avait réellement besoin.

Fait intéressant, certains des plus fervents défenseurs de l’IA dans le monde de la tech arrivent à des conclusions similaires à celles de ses critiques.

En mars, l’investisseur Marc Andreessen affirmait que des entreprises surdimensionnées utilisaient l’IA comme un « prétexte miracle » pour réduire leurs effectifs.

En mai, Sam Altman, PDG d’OpenAI, est revenu sur certaines de ses prévisions concernant les pertes d’emplois massives liées à l’IA :

« Je pensais que davantage d’emplois administratifs de premier niveau auraient déjà disparu à cause de l’IA. Cela ne s’est pas produit dans les proportions attendues. »

Et même si le pire scénario pour les emplois technologiques devait se réaliser — ce qui serait effectivement très difficile pour de nombreuses personnes — cela resterait loin de l’apocalypse du travail que beaucoup redoutent.

« Va-t-elle réellement détruire tous les emplois ? » demande Naidu. « Je n’en suis pas convaincu. Même le logiciel ne représente qu’environ 4 à 6 % du PIB. C’est important, mais ce n’est pas comme si toute l’économie pouvait être remplacée par Claude Code. »

Une stratégie marketing particulièrement efficace

Convaincre le public que l’IA remplacera massivement les travailleurs humains constitue une stratégie marketing redoutablement efficace.

Non seulement cela alimente la spéculation des investisseurs, mais cela détourne également l’attention d’une utilisation beaucoup plus réaliste de l’IA dans le monde du travail : surveiller les employés, les microgérer et extraire toujours plus de productivité d’eux, tout en leur faisant comprendre qu’ils devraient déjà s’estimer heureux d’avoir un emploi.

Les travailleurs des plateformes — chauffeurs Uber ou livreurs DoorDash — servent déjà de cobayes à cette forme de gestion algorithmique, et les spécialistes du travail prédisent son extension à de nombreux autres secteurs.

Nous avons parfois l’impression de vivre une gigantesque expérience sociale avec l’essor de l’IA. Naidu propose cependant une autre manière de voir les choses :

« Une expérience suppose l’existence d’un groupe témoin qui ne serait pas affecté. Ici, il n’y a pas de groupe témoin. »

N’oublions pas qu’il existe des alternatives

La version de l’IA qu’on nous vend n’est pas forcément celle que nous devons acheter. Et ce n’est pas non plus l’histoire que nous sommes obligés de croire.

Il ne s’agit pas de défendre une relation d’abstinence totale avec l’IA, une position qui rappelle par certains aspects les discours évangéliques sur l’abstinence sexuelle avant le mariage. Chacun sait que ce type d’interdits fonctionne rarement dans la réalité.

C’est déjà le cas avec l’IA. Comme l’écrivait cette année la journaliste Shira Ovide du Washington Post : « L’IA est simplement une technologie que les Américains n’aiment pas mais qu’ils ne peuvent plus cesser d’utiliser. »

L’enjeu est plutôt celui de la modération.

Martin Beraja estime qu’on accorde trop d’importance à l’IA comme outil de remplacement des travailleurs. En dehors de quelques secteurs comme la technologie, les études montrent que les usages les plus efficaces de l’IA consistent à aider les individus et les entreprises à apprendre davantage et plus rapidement, plutôt qu’à supprimer des postes.

« Nous devons parvenir à l’idée qu’il peut exister des alternatives », affirme Anil Dash. « Au lieu de chercher un nouveau tueur de ChatGPT, nous pourrions imaginer une multitude de petites IA développées par de petits acteurs responsables. »

Certaines commencent déjà discrètement à émerger, rappelant les débuts plus optimistes d’Internet et laissant entrevoir ce qui pourrait devenir possible si les utilisateurs reprenaient davantage le contrôle de ces technologies.

Et pour les secteurs et les emplois bouleversés par l’IA, ces transformations pourraient paradoxalement favoriser un regain du pouvoir des travailleurs, à mesure que les employés de bureau redécouvrent l’intérêt de la solidarité, que ce soit avec leurs collègues ou avec les travailleurs manuels.

Après tout, la révolution industrielle — autre grande période de transformation technologique qui présente d’étranges similitudes avec notre époque — a été l’un des principaux catalyseurs du mouvement ouvrier, même si ses victoires ont mis du temps à se concrétiser.

7 - My 'Grill Me' Skill Went Viral

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree resolving dependencies between decisions one by one.

If a question can be answered by exploring the codebase, explore the codebase instead.

For each question, provide your recommended answer.

8 - Prompt: ACCESSIBILITY EVALUATION

You are a senior Accessibility, WCAG 2.2 and Front-End UI expert. Your task has 2 phases:

PHASE 1 — ACCESSIBILITY EVALUATION (WCAG 2.2 AA)

You will receive:

• a website URL,
• screenshots, or
• a description of the interface.

Evaluate the interface based on WCAG 2.2 AA and modern accessibility best practices.

Evaluate the following categories (WCAG-aligned):

1. Perceivable (structure, text alternatives, captions, contrast, resizing, reflow)
2. Operable (keyboard, focus, navigation, timing, gestures, pointers, animations)
3. Understandable (predictability, clear labels, form errors, language)
4. Robust (semantic HTML, ARIA, compatibility with assistive tech)
5. Keyboard Accessibility (tab order, focus visibility, traps)
6. Screen Reader Compatibility (roles, names, states, announcements)
7. Semantic HTML & Landmarks (headings, regions, lists, tables)
8. Color, Contrast & Visual Accessibility (contrast, non-color information)
9. Forms & Input Assistance (labels, errors, autocomplete, instructions)
10. Motion, Timing & Cognitive Load (animations, distractions, complexity, alternatives)

For each category, provide:

• Score (0–100)
• Risk level
  • 0–59% = High
  • 60–79% = Needs improvement
  • 80–100% = Good
• Specific accessibility issues (WCAG-linked)
• User impact (especially AT users)
• Actionable WCAG-based recommendations
• A “So what?” sentence explaining business impact

Short Overview

Provide:

• Type of website
• Scope of what was tested
• 2–4 sentence accessibility impression

Prioritisation — Top 5 Accessibility Issues

For each:

• Severity (low / medium / high / critical)
• Short justification
• Business impact (legal / trust / conversion / support / brand)
• Recommended urgency

Stakeholder Summary (5–7 bullets)

• Non-technical language
• Clear benefits for users & business
• Focus on risk mitigation, compliance, inclusion

PHASE 2 — PRODUCE A STANDALONE HTML REPORT

After completing the evaluation internally, output ONLY a complete HTML document.

No Markdown.

No explanations outside HTML.

HTML REPORT REQUIREMENTS

A) VISUAL DESIGN

• Modern consulting-report look
• Card-based layout
• Light shadows, spacing, rounded corners (8–12px)
• Deep blue palette + accessible accent colors
• Font: system-ui, -apple-system, BlinkMacSystemFont, sans-serif
• Strategic icons/emojis
• Clean hero section

B) REPORT STRUCTURE

1. Hero Section

• Title: Accessibility Evaluation (WCAG 2.2 AA) — [Website Name]
• 2-sentence subtitle
• Pills for:
  • Website type
  • Scope
  • Overall accessibility impression
• Executive summary (60 seconds): 3–4 bullets

2. Overview Section

Cards for:

• Purpose of the site
• First accessibility impressions
• Key risks at a glance

3. WCAG Accessibility Analysis (Cards Grid)

Each card includes:

• Category name + icon
• Score (0–100) + colored progress bar
• Benchmark line (“Benchmark ~75% for modern sites”)
• WCAG-aligned issues (bullets)
• Impact & recommended fixes (bullets)
• “So what?” business relevance sentence

4. Prioritisation — Top 5 Issues

Table with columns:

• Issue
• Severity (color-coded)
• Business impact tags (⚖️ / 🤝 / 📈 / 📞)
• Why it matters
• Recommended urgency

5. Visuals Section

Must include:

• Simple accessibility user-flow diagram
• Radar/Spider Chart (inline SVG)
  • Dashed ideal ring (~85%)
  • Highlight <60% risk zone

6. Stakeholder Summary

• 5–7 bullets
• Business-friendly
• Emphasis on compliance, inclusion, risk mitigation

7. Footer

• Short note about heuristic WCAG evaluation

C) STRICT OUTPUT RULES

• Do NOT output reasoning
• Do NOT ask questions
• Do NOT wrap HTML in Markdown
• Output ONLY the final standalone HTML page

WEBSITE INPUT:

User will provide URL, screenshots, or interface description

9 - Run Claude Code inside my Obsidian

I run Claude Code inside my Obsidian vault through a terminal extension. This lets me treat the AI as a collaborator that can read, write, and traverse my notes.

The structure

My vault follows a light hierarchy:

• 01 Inbox for quick capture
• 02 Journal for reflections and plans
• 03 Garden for permanent, evergreen notes
• 04 Projects for active work, each in its own folder
• 05 Areas for ongoing life contexts

The Garden is where ideas mature. Notes there are atomic (one idea each), opinionated (stating positions rather than describing topics), and linked to each other. They accumulate slowly.

Projects live in separate folders. I can open a terminal in any project folder and give Claude Code the specific context it needs. The AI sees only what’s relevant.

Maps of Content

I maintain a handful of Maps of Content (MOCs) that act as entry points into clusters of ideas. These are pages that link to related notes on a theme: creative work, tools for thought, software philosophy, focus, durability, self-experimentation.

MOCs help me and the AI navigate. When I ask Claude to explore a topic, I can point it to the relevant MOC instead of hoping it finds the right notes through search alone.

How Claude Code fits in

The point is not to have AI write for me. It’s to think alongside something that can hold more context than I can in my head at once.

The terminal interface matters. I’m not pasting notes into a chat window. Claude can use tools: reading files, searching across the vault, writing drafts directly where they belong. It operates inside my system rather than alongside it.

Common patterns:

• Filling gaps: I have scattered thoughts across journal entries and inbox notes. I ask Claude what’s missing, what I haven’t addressed, where the argument is weak.

• Surfacing connections: It finds relationships between notes I hadn’t linked. Sometimes it surfaces tensions or contradictions I’d missed.

• Deepening thinking: I describe a half-formed idea. Claude asks questions, challenges assumptions, helps me see angles I hadn’t considered. The goal is sharper thinking, not finished prose.

• Drafting from my material: When I do ask it to write, it’s working from my notes, my fragments, my voice. The output is a starting point I’ll rewrite.

The AI becomes useful when it has real context and when I stay in the loop. A vault full of linked notes provides the context. Staying critical of the output keeps the thinking mine.

Daily practice

I write daily notes when something needs processing. These go in the Journal, not the Garden. They’re messy, personal, often questions more than answers.

Periodically I review the Journal and promote ideas worth keeping into proper evergreen notes. Claude can help with this: “What themes keep appearing in my recent journal entries?”

What this isn’t

The system is simple. There’s no elaborate tagging taxonomy, no complex automation, no perfect template. I’ve tried those approaches. They create maintenance burden that eventually collapses.

The current setup works because it’s light enough to actually use. Five folders. A few MOCs. Notes that link to each other. An AI that can read and write in place.

For those exploring this

The ideas behind evergreen notes come largely from Andy Matuschak ( @andy_matuschak ), who has published extensively on the topic at notes.andymatuschak.org . His work on making notes atomic, concept-oriented, and densely linked shaped how I think about the Garden. His notes are themselves an example of the method.

For the underlying methodology, I recommend How to Take Smart Notes by Sönke Ahrens. It explains the Zettelkasten approach that influenced much of modern networked note-taking. The core insight: writing is thinking, and a good note system makes thinking accumulate.

The right setup depends on what you’re trying to do. Mine is optimized for accumulating clear thinking over time and having an AI collaborator that can work with that accumulated context. Yours might need something different.

Start light and add structure only when you feel its absence.

10 - Ultimate prompt for lectures

1/ ULTIMATE PROMPT FOR LECTURES:

“Review all uploaded materials and generate 5 essential questions that capture the core meaning.

Focus on:

• Core topics and definitions
• Key concepts emphasized
• Relationships between concepts
• Practical applications mentioned”

2/ THE “5 ESSENTIAL QUESTIONS” PROMPT

Reddit called this a “game changer.” It forces NotebookLM to extract pedagogically-sound structure instead of shallow summaries:

“Analyze all inputs and generate 5 essential questions that, when answered, capture the main points and core meaning of all inputs.”

3/ STEVEN JOHNSON’S “INTERESTING BITS” PROMPT

NotebookLM’s director tested this on 500,000 words of NASA transcripts. Did 10 hours of manual work in 20 seconds:

“What are the most surprising or interesting pieces of information in these sources? Include key quotes.”

4/ EXTENDED VERSION WITH STEERING:

“I’m interested in writing about [TOPIC].

What are the most surprising facts or ideas related to [TOPIC] in these sources?

Include key quotes. Focus on [SPECIFIC ASPECT], not [OTHER ASPECTS].”

Traditional search can’t surface “interestingness.” This can.

5/ THE QUIZ SHOW FORMAT (Audio Overview)

Students love this. The AI hosts quiz each other and intentionally get answers wrong so corrections stick:

“A quiz show with two hosts. First host quizzes the second on [TOPIC]. 10 questions total. Mix of multiple choice and True/False.

The host gets answers wrong sometimes. The other corrects with right answers. Share results at the end.”

6/ MULTILINGUAL PODCAST HACK

Before official language support existed, users generated podcasts in Spanish, German, Japanese:

“This is the first international special episode of Deep Dive conducted entirely in [Language].

Special Instructions:

• Only [Language] for entire duration
• No English except to clarify unique terms”

7/ PRODUCT MANAGER PERSONA (Official Google)

Transforms documents into decision memos:

“Act as a Lead Product Manager reviewing internal documentation. Ruthlessly scan for actionable insights, ignoring fluff.

Synthesize into “Decision Memo” format:

• User Evidence: Direct quotes indicating user problems
• Feasibility Checks: Technical constraints mentioned
• Blind Spots: What’s missing from source text

Use bullets. If I ask vague questions, force me to clarify.”

8/ SCIENTIFIC RESEARCHER PERSONA (Official Google)

For academics who need methodology over conclusions:

“Act as research assistant for a senior scientist. Tone: strictly objective, formal, precise.

Assume advanced knowledge of [FIELD]. Don’t define standard terminology.

Focus on methodology, data integrity, and conflicting evidence.

Prioritize sample size, experimental design, and statistical significance over general conclusions.

Format with bolded sections:

• Key Findings
• Methodological Strengths/Weaknesses
• Contradictions”

9/ MIDDLE SCHOOL TEACHER PERSONA (Official Google)

Makes dense content accessible:

“Act as an engaging Middle School Teacher. Translate source documents into language a 7th grader understands.

Structure every response:

• The “tl;dr”: One sentence using simple words
• Analogy: Real-world metaphor for the concept
• Vocab List: 3 difficult words defined simply

For dense paragraphs, break into True or False quiz format.”

10/ LITERATURE REVIEW THEMES PROMPT

For researchers synthesizing multiple papers:

“From papers on [TOPIC], identify 5-10 most recurring themes.

For each theme provide:

1. Short definition in your own words
2. Which papers mention it (with citations)
3. One sentence on how it’s treated (debated, assumed, tested)

Present as structured table.”

11 - ultrathink

as someone who’s been using it heavily for 9 months, here are my top tips to maximize its potential: getting started & configuration customize your status line - use /statusline to show your current model, git branch, and token usage. keeps you aware of what’s going on learn essential slash commands - /usage (rate limits), /chrome (browser), /mcp (tools), /stats (activity), /clear (fresh start). these are your power moves use claude. md for project context - create a claude. md file in your project root with commands, style guides, and setup instructions. claude pulls it in automatically create custom slash commands - turn your repetitive workflows into custom commands by adding markdown files to .claude/commands. automate the boring stuff configure allowed tools - use /permissions or edit .claude/settings.json to let claude use certain tools without asking every time. saves you a ton of back-and-forth install the gh cli - if you’re on github, grab the gh command-line tool. makes it way easier for claude to create issues and prs use terminal aliases - create alias c=‘claude’ so you’re not typing the full command constantly. small thing, big quality of life improvement prompting & interaction use voice input - talking is faster than typing. grab a local transcription tool and just talk to claude. it understands even with typos break down large problems - don’t throw a massive problem at claude. split it into smaller pieces and solve them one by one. works way better use the “think” keyword - when you want claude to really dig deep, use “think,” “think hard,” “think harder,” or “ultrathink” to give it more thinking time provide detailed specs - for bigger tasks, write a proper spec in markdown. more detail upfront means better results. worth the effort use @ to reference files - point claude to specific files with @ instead of just describing them. clearer and you get tab auto-completion interrupt and add context anytime - if claude’s going the wrong way or you think of something important, just type it. claude will pick it up and adjust on the fly workflow & best practices minimize context - start a fresh conversation for each new task. long chats with irrelevant stuff actually make claude perform worse plan before coding - hit shift+tab twice for planning mode. let claude map out the solution before writing code. saves so much time use git for version control - commit often. if claude messes up, just git restore and try again with a better prompt. no stress let claude handle git operations - ask claude to write commits and commit messages. it’s surprisingly good at it and you’ll get better messages always verify output - check what claude gives you. have it write tests, review changes, or create a draft pr. don’t ship blind use handoff documents for long tasks - for multi-session work, ask claude to write a handoff doc summarizing what it did, what worked, and what’s next. makes pickups way easier try test-driven development - have claude write failing tests first, then code to make them pass. powerful workflow that leads to better code advanced techniques use subagents for complex problems - for tricky research or investigation, tell claude to use subagents to verify details. keeps your main chat clean create feedback loops - for stubborn bugs, set up a loop where claude builds, runs, checks output, and tries again on its own. let it grind use tmux for interactive clis - when working with interactive command-line stuff, use tmux so claude can send commands and capture output clone and half-clone conversations - use clone to copy a conversation or half-clone to keep only the recent half. quick way to manage context juggle multiple sessions - run multiple claude instances in different tabs. focus on a few tasks at a time and switch between them. solid multitasking approach