Skip to content
easeweb

For developers and designers

Accessibility fixes and checks, in your coding agent.

The Learn guides as a Model Context Protocol server: what breaks for real people, the fix with code, and the checks only a person can do. Free, no login.

Without EaseWeb

  1. build an autoplaying hero carousel
  2. setInterval(next, 3000)
  3. Done.

3 failures, found after release.

The same request, without and with EaseWeb.

Setup

Set it up and use it in four steps.

  1. Add the server to your coding agent

    No key and no account. The address is https://easeweb.dev/mcp. Pick your client:

    In a terminal:

    claude mcp add --transport http easeweb https://easeweb.dev/mcp
  2. Tell it to ask first

    Your agent decides when to call a tool. Paste this line into your project rules (CLAUDE.md, AGENTS.md or .cursor/rules) so it asks before every UI change:

    When asked to design, build or change UI, call the easeweb before_building tool with the request before writing code or drawing the design. When choosing colours, call check_palette. After building, call test_steps and hand the "a person must check" items to me as written; never report them as done.
  3. Ask for UI as you normally would

    Before it writes code, the agent calls before_building with your words. If the request would fail as asked, it builds a version that passes and tells you why.

    > build an autoplaying hero carousel
    ● easeweb · before_building
  4. Do the checks it hands you

    When it’s done, the agent lists what only a person can check, such as listening with a screen reader. Do those before you ship; the agent never marks them as done.

The tools

Five tools, each with a moment to call it.

  • before_building

    When: Before any UI is designed or built: menus, dialogs, carousels, tabs, forms, drag and drop, custom controls. Wireframes and prototypes too.

    Returns: The guides that apply, the requirements to build in from the start, working reference code, and the checks split by who can do them. When the request itself breaks a rule, a passing version that keeps what was asked for, and one sentence to tell you.

  • find_fix

    When: A finding, a complaint, a failing check or a question names a problem.

    Returns: For each matching topic: the problem, the fix in a line, how to test it, the guide link, and the criterion in WCAG, EN 301 549, Section 508 and JIS X 8341-3 terms. Topics with no guide yet say so.

  • get_guide

    When: The agent needs the full fix.

    Returns: The guide as Markdown, the same as /learn/⟨slug⟩.md, with the Before and After code as plain text and its marks: recommended, not enough on its own, the rule of thumb behind it.

  • test_steps

    When: After building or fixing, before the agent says it is done.

    Returns: The pass criteria, the checks the agent can run itself, the two-minute script only a person can do (which keys to press, what should happen), the guide’s limits, and a Playwright regression test skeleton that never passes empty.

  • check_palette

    When: Choosing or changing colours, a palette or design tokens, before they are used.

    Returns: Each pair’s contrast ratio, pass or fail for text (1.4.3) and controls (1.4.11) at AA or AAA, the nearest passing shade of the same hue, and the guides that apply.

Every guide is also an MCP resource, so you can @-mention one in clients that support it, and two prompts (before_building, handoff) run the two moments as slash commands.

What an answer looks like

It doesn’t say no. It says how.

This is before_building for “a settings form with placeholders instead of labels”, cut to the parts that differ from a scanner: the passing version of what was asked for, the sentence to say, and the checks a person must do.

Part of this request fails as asked

Breaks: WCAG 3.3.2 Labels or Instructions (A; JIS X 8341-3 3.3.2; EN 301 549 9.3.3.2; Section 508)

Instead: A visible label that stays while people type: a label above the field, or a floating label that moves above the field on focus and stays there. The placeholder, if any, is an example value, not the name of the field.

Say to the user: “The placeholder disappears as soon as someone types, so I’ll keep a small visible label that stays, and use the placeholder for an example.”

The agent can check

  • Every field has a label element linked by for and id, and the label stays visible while typing.
  • The accessible name matches the visible label text.

A person must check

  • A screen reader reads each label when the field gets focus.
  • Labels stay readable at 200% zoom and in forced colors.

Abridged. The full answer has the guide link, the reference code and the two-minute test script.

The loop

A person at both ends of every fix.

  1. 1

    A person finds it

    Testing by hand with a keyboard, screen readers and zoom finds what scans miss.

  2. 2

    Your agent fixes it

    From guides written for agents: the fix, the code and the checks. Free.

  3. 3

    A person confirms it

    Fixed means a human recheck passed, not that a scan came back clean.

  4. 4

    A test keeps it fixed

    A regression test in your CI for each confirmed fix, from the skeleton test_steps returns. Free.

Steps 2 and 4 are free and live today. On ongoing support, steps 1 and 3 come into the same agent too: your findings, rechecks and project rules, as that part is built.

Limits, up front

What it can’t do.

  • It never sees your page. It answers from the guides and the words you give it; scanning stays in your own CI with axe or Playwright.
  • A clean answer is not an accessible page. Every answer splits what the agent can check from what a person must check, and the second list is the one that counts.
  • check_palette checks values. Text over images, real focus and hover states and forced colors need the rendered page.
  • Guides cover the common failures first. A topic without a guide comes back as in progress, with its criteria; the outline grows every week.
  • Fair use: 600 requests a day per address, counted by a hash. No account, no cookie, no arguments stored.

Also for developers

Without an MCP client.

When the agent has done its part

The checks a person must do are the ones that decide. Ongoing support puts a Section 508 Trusted Tester on them: findings, rechecks and a regression test for each confirmed fix, for your whole team.