# Jeikin

> Accessibility compliance, built into your dev workflow.

Jeikin is an accessibility compliance platform for software teams. It turns WCAG 2.2 into an automated, continuous review that runs inside AI coding tools (Claude Code, Cursor, Windsurf) and surfaces findings on a shared dashboard for developers, engineering managers, and compliance teams. Every finding and fix is timestamped so the audit trail matches legal frameworks including the European Accessibility Act, ADA Section 508, and EN 301 549.

## Product

- [Jeikin for VS Code](https://jeikin.com/vscode): Make your AI coding assistant accessibility-aware. Install the Jeikin extension, connect in one click, and every AI interaction follows WCAG.
- [Jeikin for Developers](https://jeikin.com/for/developers): Jeikin works inside Claude Code, Cursor, and Windsurf to catch accessibility issues while you code. 86 WCAG criteria, handled for you.
- [Jeikin for Compliance](https://jeikin.com/for/compliance): Continuous WCAG 2.2 accessibility compliance evidence. Every finding and fix timestamped. Supports EAA, ADA Section 508, and EN 301 549.
- [Jeikin for Agencies](https://jeikin.com/for/agencies): Dashboard per project with continuous evidence of accessibility work. Give clients proof, not promises.
- [Jeikin for Engineering Managers](https://jeikin.com/for/engineering-managers): Accessibility compliance visibility per project. Catch issues during development, not after audits. Evidence for leadership reporting.

## Blog

- [EN 301 549, the accessibility rulebook Europe actually uses](https://jeikin.com/blog/en-301-549-explained): Europe's accessibility laws don't tell you what to build. They point at a technical document most people have never opened. A major new version landed on 3 September 2026, and this is what that document is, where it came from, and what changed.
- [Who checks the checker?](https://jeikin.com/blog/who-checks-the-checker): The free accessibility tools that run inside AI coding assistants have quietly become good. We spent time with the two most popular ones. They find problems and they fix them, and they share an architecture worth understanding before you rely on one.
- [More ARIA than human](https://jeikin.com/blog/more-aria-than-human): WebAIM counted 133 million ARIA attributes in 2026, a 27% jump in one year, alongside more errors per page than the year before. More accessibility code, less accessible web. Here is what that says about AI-generated markup and the criteria nobody ever wrote down.
- [The W3C just put the accessibility overlay lie in writing](https://jeikin.com/blog/wcag-em-2-the-official-recipe): WCAG-EM 2.0, the W3C's new official method for evaluating conformance, says in plain text what the 'automate it all' vendors never will: no tool alone can prove a site is accessible. Here's why that vindicates the way we built Jeikin.
- [Accessibility is where 'looks done' and 'is done' come apart](https://jeikin.com/blog/accessibility-looks-done-is-done): AI made producing plausible-looking code nearly free. Accessibility is the property where plausible and correct diverge the most, which is why it regressed the year everyone adopted tooling to fix it.
- [The agent loop is becoming the enforcement layer](https://jeikin.com/blog/the-agent-loop-is-the-new-enforcement-layer): Security and quality tools are moving their checks inside the AI writing loop, enforced by the agent as it generates code. Accessibility is arriving there too. Here's the pattern, and what it takes to count.
- [The AI tools that broke accessibility just became the only place to fix it](https://jeikin.com/blog/the-industry-agreed-accessibility-belongs-in-the-loop): The whole accessibility industry now agrees the fix belongs inside the AI authoring loop. The only question left is what "in the loop" actually has to do to count.
- [The European Accessibility Act, one year in: what enforcement actually looks like, country by country](https://jeikin.com/blog/eaa-one-year-in-enforcement-by-country): One year after the EAA deadline, the picture is clearer than the headlines suggest. France has convicted a retailer, most states have issued notices, and not a single confirmed fine has yet been collected. Here's the verified, per-country reality.
- [Automated accessibility testing catches 30 to 40 percent of issues. Here's the other 60.](https://jeikin.com/blog/the-other-60-percent): Automated scanners set a capability floor for accessibility, not a ceiling. Here's what they catch, what they can't, and how to cover the rest.
- [What AI coding tools can (and can't) fix on your Shopify or WooCommerce store](https://jeikin.com/blog/ai-coding-tools-shopify-woocommerce): Small founders on Shopify and Woo lean on Cursor, Copilot, and Claude Code for the custom bits of their store. Here's the map of what AI tools can actually fix, what they can't, and which parts of accessibility are yours to own in the first place.
- [What AI just gave accessibility professionals back](https://jeikin.com/blog/what-ai-just-gave-accessibility-professionals-back): For two decades, accessibility specialists have spent a meaningful slice of their week on the boring 30–40% — missing alt text, wrong heading levels, ARIA in invalid combinations. In the last 60 days, that layer started handling itself. Here's what that frees them to do.
- [The AI coding tools finally noticed accessibility. Now what?](https://jeikin.com/blog/the-ai-coding-tools-finally-noticed-accessibility): GitHub shipped its own accessibility scanner. A community pack shipped 79 specialised agents. The lane is no longer empty. Here's what those tools do, what they miss, and where evidence still has to come from.
- [Accessibility MCP servers for AI coding agents (2026)](https://jeikin.com/blog/accessibility-mcp-servers-compared-2026): A practical comparison of accessibility MCP servers and tools that work with Claude Code, Cursor, and Windsurf — what each one does, what it doesn't, and when to pick which.
- [Preparing for the 2026 accessibility deadlines: HHS, DOJ Title II, and the EAA, ten months in](https://jeikin.com/blog/preparing-for-the-2026-accessibility-deadlines): HHS's May 2026 healthcare accessibility deadline still stands, DOJ extended Title II by a year, and the EAA is enforcing in Europe. What changed, what didn't, and what evidence regulators want.
- [An accessibility check that runs on every pull request](https://jeikin.com/blog/jeikin-on-github-marketplace): The Jeikin Accessibility app is on the GitHub Marketplace. Install it on a repo and every pull request gets a WCAG review before it merges.
- [The accessibility tree is the new API](https://jeikin.com/blog/the-accessibility-tree-is-the-new-api): AI agents don't see your website. They read the accessibility tree. The same structure built for screen readers is now the interface for every AI agent on the web.
- [The in-house illusion: why hiring an accessibility lead isn't a compliance strategy](https://jeikin.com/blog/the-in-house-illusion): Forbes just put a number on it. Settlements run $25k to $100k per case, before legal fees. One person can't merge every PR. Compliance isn't a role, it's a pipeline.
- [The enforcement gap: why finding issues was never the problem](https://jeikin.com/blog/the-enforcement-gap): Every AI coding tool can find accessibility issues. Almost none can prove they were fixed. That gap is where compliance falls apart.
- [Accessibility belongs where developers already work](https://jeikin.com/blog/accessibility-where-developers-already-work): AI coding assistants can follow instructions. But instructions without enforcement are just suggestions. Here's what changes when accessibility has a system behind it.
- [Accessibility overlays: why painting over problems doesn't fix them](https://jeikin.com/blog/accessibility-overlays-why-they-dont-work): Accessibility overlay widgets promise instant compliance, but they create more problems than they solve. Here's what actually works.
- [Introducing Jeikin: accessibility compliance for AI-assisted development](https://jeikin.com/blog/introducing-jeikin): Why we built an accessibility tool that works through your AI coding assistant — and what makes it different from everything else.

## WCAG criteria

- [WCAG 1.1.1 Non-text Content](https://jeikin.com/wcag/1-1-1-non-text-content.md): Every image, icon, and non-text element must carry a text alternative that conveys the same meaning. The cost of getting this wrong is invisibility for screen-reader users.
- [WCAG 1.2.1 Audio-only and Video-only (Prerecorded)](https://jeikin.com/wcag/1-2-1-audio-only-and-video-only-prerecorded.md): Prerecorded audio-only and video-only media must carry an alternative that conveys the same information. A podcast without a transcript is invisible to deaf users; a silent product demo without a description is invisible to blind users.
- [WCAG 1.2.2 Captions (Prerecorded)](https://jeikin.com/wcag/1-2-2-captions-prerecorded.md): Every prerecorded video with an audio track needs synchronised captions. The spoken dialogue, the relevant sound effects, the speaker identification — all of it has to be available as on-screen text, in sync with the video.
- [WCAG 1.2.3 Audio Description or Media Alternative (Prerecorded)](https://jeikin.com/wcag/1-2-3-audio-description-or-media-alternative-prerecorded.md): Prerecorded video with an audio track must give blind users a way to follow what's on screen. Either an audio description narrating the visuals, or a full text transcript that covers everything dialogue alone misses.
- [WCAG 1.2.4 Captions (Live)](https://jeikin.com/wcag/1-2-4-captions-live.md): Live audio in synchronised media — webinars, conference streams, real-time product launches — must carry live captions. The standard isn't "captions later"; it's captions in sync, in the moment.
- [WCAG 1.2.5 Audio Description (Prerecorded)](https://jeikin.com/wcag/1-2-5-audio-description-prerecorded.md): At Level AA, the text-alternative escape hatch from 1.2.3 goes away. Prerecorded video with audio must carry an audio description track that narrates the visuals — full stop.
- [WCAG 1.2.6 Sign Language (Prerecorded)](https://jeikin.com/wcag/1-2-6-sign-language-prerecorded.md): At Level AAA, prerecorded synchronised media must include a sign-language interpretation. For Deaf users whose first language is a sign language, captions alone are second-language reading — interpretation in their native language is the equivalent experience.
- [WCAG 1.2.7 Extended Audio Description (Prerecorded)](https://jeikin.com/wcag/1-2-7-extended-audio-description-prerecorded.md): When the natural pauses in a video aren't long enough to fit the necessary visual narration, the video must pause to let the description finish. Standard audio description with no room to breathe is incomplete description.
- [WCAG 1.2.8 Media Alternative (Prerecorded)](https://jeikin.com/wcag/1-2-8-media-alternative-prerecorded.md): For Level AAA, the video itself isn't enough — even with captions and description. A full text alternative covering the audio AND the visuals must exist, so deafblind users have a way in too.
- [WCAG 1.2.9 Audio-only (Live)](https://jeikin.com/wcag/1-2-9-audio-only-live.md): Live audio without video — a live radio show, a live audio chat, a live podcast — still has to be perceivable to deaf users. The Level AAA requirement is a real-time text alternative.
- [WCAG 1.3.1 Info and Relationships](https://jeikin.com/wcag/1-3-1-info-and-relationships.md): Information conveyed by visual structure — headings, lists, tables, form labels, groupings — must also be available to assistive technology programmatically. The shape of the page has to match the shape of the markup.
- [WCAG 1.3.2 Meaningful Sequence](https://jeikin.com/wcag/1-3-2-meaningful-sequence.md): The DOM order has to match the visual reading order. CSS can move things around for sighted users, but a screen reader reads the source — and if the source is scrambled, the announcement is scrambled.
- [WCAG 1.3.3 Sensory Characteristics](https://jeikin.com/wcag/1-3-3-sensory-characteristics.md): "Click the green button on the right." For a colour-blind user there is no green button; for a screen-reader user there is no right. Instructions that depend on sensory characteristics alone leave entire populations out.
- [WCAG 1.3.4 Orientation](https://jeikin.com/wcag/1-3-4-orientation.md): A user with their phone mounted in a wheelchair, a tablet on a stand, or a device with a stuck orientation lock has no way to "just rotate it". Content that only works one way locks them out.
- [WCAG 1.3.5 Identify Input Purpose](https://jeikin.com/wcag/1-3-5-identify-input-purpose.md): Common form fields — name, email, phone, address, credit card — must declare their purpose with `autocomplete` so browsers and assistive tech can pre-fill, decorate, or substitute the input. The tokens are standardised; use them.
- [WCAG 1.3.6 Identify Purpose](https://jeikin.com/wcag/1-3-6-identify-purpose.md): AAA-level personalisation needs more than well-named inputs — it needs every UI region and component to declare what it is, so user-agent tools can simplify, swap, or annotate them.
- [WCAG 1.4.1 Use of Color](https://jeikin.com/wcag/1-4-1-use-of-color.md): Colour can carry information; it just can't be the only thing carrying it. Red rows for errors, green dots for available, "the blue links" — they all break the moment colour stops working, and they break silently.
- [WCAG 1.4.2 Audio Control](https://jeikin.com/wcag/1-4-2-audio-control.md): Audio that starts playing on its own and lasts more than three seconds without an obvious way to stop it can drown out a screen reader, startle a user, and make a page genuinely unusable.
- [WCAG 1.4.3 Contrast (Minimum)](https://jeikin.com/wcag/1-4-3-contrast-minimum.md): Body text needs at least 4.5:1 contrast against its background; large text needs 3:1. The numbers exist because anything less is unreadable for people with low vision, in bright sunlight, or on a low-quality screen.
- [WCAG 1.4.4 Resize Text](https://jeikin.com/wcag/1-4-4-resize-text.md): A user with low vision who turns the browser zoom to 200% should still be able to read every word and use every control. The page can change shape; it cannot lose content.
- [WCAG 1.4.5 Images of Text](https://jeikin.com/wcag/1-4-5-images-of-text.md): If a piece of information could have been text, it should be text. Images of text don't scale, can't be reflowed, can't be translated, can't be searched, and routinely fail contrast at higher zoom levels.
- [WCAG 1.4.6 Contrast (Enhanced)](https://jeikin.com/wcag/1-4-6-contrast-enhanced.md): At Level AAA, the contrast bar nearly doubles. Body text needs 7:1 against its background. The "Lorem Ipsum on light grey" pattern that just clears AA at 4.5:1 doesn't survive here.
- [WCAG 1.4.7 Low or No Background Audio](https://jeikin.com/wcag/1-4-7-low-or-no-background-audio.md): Spoken audio with music underneath sounds professional. For users with auditory processing difficulties or moderate hearing loss, that same background track turns the speech into noise.
- [WCAG 1.4.8 Visual Presentation](https://jeikin.com/wcag/1-4-8-visual-presentation.md): At AAA, blocks of text become user-configurable: foreground and background colours, width capped at 80 characters, line-height at least 1.5, no full justification. The page becomes a starting point, not a fixed artefact.
- [WCAG 1.4.9 Images of Text (No Exception)](https://jeikin.com/wcag/1-4-9-images-of-text-no-exception.md): The AAA cousin of 1.4.5 removes the "customisable" escape hatch. Unless the appearance is essential or the image is a logotype, images of text are out.
- [WCAG 1.4.10 Reflow](https://jeikin.com/wcag/1-4-10-reflow.md): Squeeze the viewport to 320 CSS pixels — roughly a 400% zoom on a phone — and the content should reflow into a single column with no horizontal scrollbar. Either it does, or it doesn't, and an awful lot of marketing sites don't.
- [WCAG 1.4.11 Non-text Contrast](https://jeikin.com/wcag/1-4-11-non-text-contrast.md): UI components and meaningful graphics need at least 3:1 contrast against their adjacent colour. The criterion exists because a button you cannot see is a button you cannot use.
- [WCAG 1.4.12 Text Spacing](https://jeikin.com/wcag/1-4-12-text-spacing.md): A user with dyslexia or low vision applies a stylesheet that opens up line height, letter spacing, and word spacing. The page should accommodate — not clip text, not break layout, not lose content.
- [WCAG 1.4.13 Content on Hover or Focus](https://jeikin.com/wcag/1-4-13-content-on-hover-or-focus.md): A tooltip that appears on hover should be dismissible, hoverable itself, and persistent enough to read. The trio of failures — invisible Escape, can't move the pointer to the tooltip, vanishes too fast — locks out anyone with motor or vision impairments.
- [WCAG 2.1.1 Keyboard](https://jeikin.com/wcag/2-1-1-keyboard.md): Every interaction must be reachable and operable from a keyboard alone. The mouse is one of several input devices, not the canonical one — and for many users, it isn't an option at all.
- [WCAG 2.1.2 No Keyboard Trap](https://jeikin.com/wcag/2-1-2-no-keyboard-trap.md): Focus must move into a widget and out again. A modal you can't escape, a date-picker that swallows Tab, an embedded video that captures the keyboard — these are not minor annoyances. For keyboard users they end the session.
- [WCAG 2.1.3 Keyboard (No Exception)](https://jeikin.com/wcag/2-1-3-keyboard-no-exception.md): The AAA cousin of 2.1.1 closes the "specific timings" exception. Every function must be operable from the keyboard without timing-dependent input — no exceptions for drawing, no exceptions for gestures.
- [WCAG 2.1.4 Character Key Shortcuts](https://jeikin.com/wcag/2-1-4-character-key-shortcuts.md): Single-letter shortcuts (`r` to reply, `j` to next message) are great until a screen-reader user with a voice-control setup says the word "reply" and the page deletes their work. Single-key shortcuts must be turnable off, remappable, or scoped to focus.
- [WCAG 2.2.1 Timing Adjustable](https://jeikin.com/wcag/2-2-1-timing-adjustable.md): Session timeouts, OTP windows, "click to confirm in 10 seconds" patterns — each one assumes a user who reads, decides, and acts faster than the timer. For users who don't, the page resets and the work is lost.
- [WCAG 2.2.2 Pause, Stop, Hide](https://jeikin.com/wcag/2-2-2-pause-stop-hide.md): Anything that moves, blinks, scrolls, or auto-updates for more than five seconds must have a control to pause, stop, or hide it. Motion is a barrier for people with vestibular disorders, attention differences, and cognitive disabilities.
- [WCAG 2.2.3 No Timing](https://jeikin.com/wcag/2-2-3-no-timing.md): The AAA position: no time limits, full stop. The only exceptions are real-time events that genuinely depend on timing — and even there, the standard wants you to remove the dependency where you can.
- [WCAG 2.2.4 Interruptions](https://jeikin.com/wcag/2-2-4-interruptions.md): Toasts that pop up unprompted, modal nags about cookies, "you've been idle" warnings — for a user with attention or cognitive disabilities, every interruption is a context reset. AAA wants a global mute switch.
- [WCAG 2.2.5 Re-authenticating](https://jeikin.com/wcag/2-2-5-re-authenticating.md): A user fills out a 20-question form, the session expires while they fact-check one answer, and they sign in again to find an empty form. AAA forbids this — work in progress survives the re-auth.
- [WCAG 2.2.6 Timeouts](https://jeikin.com/wcag/2-2-6-timeouts.md): If your app destroys data after a period of inactivity, the user has the right to know before it happens — not after, not "by the way it might". Warn explicitly, durably, and up front.
- [WCAG 2.3.1 Three Flashes or Below Threshold](https://jeikin.com/wcag/2-3-1-three-flashes-or-below-threshold.md): Anything flashing more than three times per second can trigger seizures in people with photosensitive epilepsy. The risk isn't theoretical — there are documented cases of broadcasts hospitalising hundreds of people.
- [WCAG 2.3.2 Three Flashes](https://jeikin.com/wcag/2-3-2-three-flashes.md): At AAA, the small-area exception that 2.3.1 grants is gone. Anything that flashes more than three times per second fails — regardless of how small or dim it is.
- [WCAG 2.3.3 Animation from Interactions](https://jeikin.com/wcag/2-3-3-animation-from-interactions.md): Parallax scrolling, slide-in transitions, large transforms on click — for users with vestibular disorders, motion isn't decorative. It's nauseating. AAA requires a way to turn it off.
- [WCAG 2.4.1 Bypass Blocks](https://jeikin.com/wcag/2-4-1-bypass-blocks.md): Every page has the same header, the same nav, the same sidebar. A keyboard user without skip links tabs through twenty-five links to reach the main content. On every page. The fix is small; the absence is a recurring tax.
- [WCAG 2.4.2 Page Titled](https://jeikin.com/wcag/2-4-2-page-titled.md): A useful `<title>` tells the user what page they're on before they read a single word of content. Default titles like "React App" or "Untitled" are AI-generation tells that ship to production with surprising frequency.
- [WCAG 2.4.3 Focus Order](https://jeikin.com/wcag/2-4-3-focus-order.md): When a user tabs through a page, the order in which they reach things has to make sense — both for understanding the content and for operating it. The DOM order is the focus order, unless you've gone out of your way to break it.
- [WCAG 2.4.4 Link Purpose (In Context)](https://jeikin.com/wcag/2-4-4-link-purpose-in-context.md): A link's purpose must be clear from its text or its immediate surroundings. "Click here" tells a screen-reader user nothing when the device announces links one at a time without context.
- [WCAG 2.4.5 Multiple Ways](https://jeikin.com/wcag/2-4-5-multiple-ways.md): One way to navigate a site is one fragile path. WCAG asks for at least two — search, sitemap, table of contents, related-content links — so users with different needs can find their way through.
- [WCAG 2.4.6 Headings and Labels](https://jeikin.com/wcag/2-4-6-headings-and-labels.md): Headings and labels have to describe what the section contains or what the control does — specifically enough that a user can navigate by them alone. "Header" doesn't qualify; neither does "Click here".
- [WCAG 2.4.7 Focus Visible](https://jeikin.com/wcag/2-4-7-focus-visible.md): Every focusable element must have a visible focus indicator. The default browser ring is functional and ugly; the design-systems response is too often to remove it without replacing it. Removing it without a replacement is the failure.
- [WCAG 2.4.8 Location](https://jeikin.com/wcag/2-4-8-location.md): A user three levels deep in a docs hierarchy needs to know where they are. Breadcrumbs, a highlighted active nav item, a clear page title — these orient the user. Their absence is disorientation by default.
- [WCAG 2.4.9 Link Purpose (Link Only)](https://jeikin.com/wcag/2-4-9-link-purpose-link-only.md): At AAA, "click here" is finally a hard fail. The link text alone — out of context, lifted into a list of every link on the page — must say where the link goes.
- [WCAG 2.4.10 Section Headings](https://jeikin.com/wcag/2-4-10-section-headings.md): A long page divided by visual style alone is unnavigable by screen reader. Real heading elements turn a wall of prose into a table of contents — and at AAA, that structure is required, not optional.
- [WCAG 2.4.11 Focus Not Obscured (Minimum)](https://jeikin.com/wcag/2-4-11-focus-not-obscured-minimum.md): Sticky headers, sticky footers, cookie banners, chat widgets — they all live on top of the page. The element that should be focused is often underneath, invisible. WCAG 2.2's new criterion says: not entirely hidden.
- [WCAG 2.4.12 Focus Not Obscured (Enhanced)](https://jeikin.com/wcag/2-4-12-focus-not-obscured-enhanced.md): The AAA version of focus-not-obscured: zero overlap. The focused component is fully visible, end of story. Sticky chrome and floating panels need real scroll-margin or they need to go.
- [WCAG 2.4.13 Focus Appearance](https://jeikin.com/wcag/2-4-13-focus-appearance.md): A focus ring exists; it's also a hair-thin line in light grey on a white background. Visible to the spec checker, invisible to most users. WCAG 2.2's new AAA criterion sets a minimum size and contrast for focus indicators.
- [WCAG 2.5.1 Pointer Gestures](https://jeikin.com/wcag/2-5-1-pointer-gestures.md): Pinch-to-zoom, two-finger rotate, swipe-with-two-fingers — multi-point gestures and path-based gestures lock out users with limited dexterity, single-finger input, or alternative pointing devices.
- [WCAG 2.5.2 Pointer Cancellation](https://jeikin.com/wcag/2-5-2-pointer-cancellation.md): Press the button by accident, drag your finger off before lifting — the click should cancel. Pages that fire on `mousedown` or `pointerdown` rob users of the chance to back out.
- [WCAG 2.5.3 Label in Name](https://jeikin.com/wcag/2-5-3-label-in-name.md): A control's accessible name must include its visible text. Voice-input users say what they see; if the accessible name doesn't start with the visible label, the voice command misses.
- [WCAG 2.5.4 Motion Actuation](https://jeikin.com/wcag/2-5-4-motion-actuation.md): "Shake the device to undo" is fun until a user with tremor can't avoid triggering it, or a user whose phone is mounted in a wheelchair can't trigger it at all. Motion can be a feature; it can't be the only path.
- [WCAG 2.5.5 Target Size (Enhanced)](https://jeikin.com/wcag/2-5-5-target-size-enhanced.md): AAA pushes tap targets to 44×44 CSS pixels. The reasoning isn't arbitrary — it's the standard size used by major mobile platforms to keep buttons comfortably tappable for users with motor impairments.
- [WCAG 2.5.6 Concurrent Input Mechanisms](https://jeikin.com/wcag/2-5-6-concurrent-input-mechanisms.md): A user has a touchscreen, a keyboard, and a mouse all plugged in at once. The site shouldn't pick one and disable the others. AAA says: support every input the platform supports.
- [WCAG 2.5.7 Dragging Movements](https://jeikin.com/wcag/2-5-7-dragging-movements.md): Drag a card to a column, drag a slider thumb, drag a file into an upload zone. For users without fine motor control, drag isn't an interaction — it's a barrier. Each draggable thing needs a non-drag path.
- [WCAG 2.5.8 Target Size (Minimum)](https://jeikin.com/wcag/2-5-8-target-size-minimum.md): WCAG 2.2's new AA criterion sets a floor: 24 CSS pixels per tap target, or enough spacing around smaller targets to keep them tappable. Half the height of the AAA target — but enforced everywhere.
- [WCAG 3.1.1 Language of Page](https://jeikin.com/wcag/3-1-1-language-of-page.md): Every page must declare its primary language with a `lang` attribute on the `<html>` element. Screen readers use this to pick the right pronunciation engine; without it, an English page read with a Spanish voice is gibberish.
- [WCAG 3.1.2 Language of Parts](https://jeikin.com/wcag/3-1-2-language-of-parts.md): A quoted phrase in another language inside an English page needs a `lang` marker so the screen reader switches voices for that span. Without it, "C'est la vie" gets read with English phonics — and no screen-reader user will recognise the phrase.
- [WCAG 3.1.3 Unusual Words](https://jeikin.com/wcag/3-1-3-unusual-words.md): Industry jargon, regional slang, technical terms with everyday surface meanings — they create entry barriers for users with cognitive disabilities and for anyone outside the niche. AAA wants a way to look them up in place.
- [WCAG 3.1.4 Abbreviations](https://jeikin.com/wcag/3-1-4-abbreviations.md): SDK, AAA, MFA, SSO, A11Y. Each acronym is shorthand inside a community and obstruction outside it. A user who doesn't know the expansion has to guess or stop reading.
- [WCAG 3.1.5 Reading Level](https://jeikin.com/wcag/3-1-5-reading-level.md): When content requires advanced reading ability, AAA wants either prose written at a lower secondary education level, or a simpler version available. Compliance is mostly about respecting the audience's actual reading capacity.
- [WCAG 3.1.6 Pronunciation](https://jeikin.com/wcag/3-1-6-pronunciation.md): "Lead" the metal and "lead" the verb. "Bow" the gesture and "bow" the weapon. When meaning depends on pronunciation, AAA wants the reader to be able to disambiguate without context-guessing.
- [WCAG 3.2.1 On Focus](https://jeikin.com/wcag/3-2-1-on-focus.md): Tab onto a field, the page navigates away. Focus a button, a modal opens. These "helpful" focus-triggered changes derail keyboard and screen-reader users who were just exploring the layout.
- [WCAG 3.2.2 On Input](https://jeikin.com/wcag/3-2-2-on-input.md): Tick a checkbox, the form submits. Type a single character, the page navigates. Inputs that act unilaterally on the user's behalf surprise everyone — and disorient screen-reader users in particular.
- [WCAG 3.2.3 Consistent Navigation](https://jeikin.com/wcag/3-2-3-consistent-navigation.md): The nav on the home page and the nav on the product page should be the same nav, in the same order, on every page. Reordering by section is novelty that costs cognition.
- [WCAG 3.2.4 Consistent Identification](https://jeikin.com/wcag/3-2-4-consistent-identification.md): A "Search" button on one page and a "Find" button on another, doing the same thing. A magnifying glass icon here and a globe icon there. The same function, different identity — confusion compounds across the site.
- [WCAG 3.2.5 Change on Request](https://jeikin.com/wcag/3-2-5-change-on-request.md): AAA forbids unrequested changes of context — auto-refresh, auto-open popups, auto-redirects. The user asked for the page they're on; honour that, until they ask for something else.
- [WCAG 3.2.6 Consistent Help](https://jeikin.com/wcag/3-2-6-consistent-help.md): If "Contact us" lives in the footer on the home page, it should live in the footer on every page. WCAG 2.2's new criterion: when help mechanisms appear on multiple pages, put them in the same place each time.
- [WCAG 3.3.1 Error Identification](https://jeikin.com/wcag/3-3-1-error-identification.md): A form fails to submit, the page is silent. Or a red border lights up with no text. For sighted users, the visual cue is enough; for everyone else, the form has rejected them in a language they can't read.
- [WCAG 3.3.2 Labels or Instructions](https://jeikin.com/wcag/3-3-2-labels-or-instructions.md): Form fields that require user input need visible labels or instructions before the user types. Placeholders alone don't count — they disappear the moment the user starts.
- [WCAG 3.3.3 Error Suggestion](https://jeikin.com/wcag/3-3-3-error-suggestion.md): "Email is invalid" tells the user what's wrong but not how to fix it. Where the system can offer a suggestion ("did you mean acme@example.com?"), it should — unless suggesting it compromises security.
- [WCAG 3.3.4 Error Prevention (Legal, Financial, Data)](https://jeikin.com/wcag/3-3-4-error-prevention-legal-financial-data.md): For commitments with legal, financial, or data-altering consequences, "Submit" can't be one accidental click. The submission must be reversible, verified, or confirmed.
- [WCAG 3.3.5 Help](https://jeikin.com/wcag/3-3-5-help.md): Context-sensitive help is the difference between "I'm stuck" and "I'll try it". AAA wants help text right where the user needs it — beside the field, beside the step — not in a separate FAQ they have to discover.
- [WCAG 3.3.6 Error Prevention (All)](https://jeikin.com/wcag/3-3-6-error-prevention-all.md): The AAA cousin of 3.3.4: every submission, not just legal/financial/data, must be reversible, checked, or confirmable. Even a comment posting deserves a review-before-publishing pass.
- [WCAG 3.3.7 Redundant Entry](https://jeikin.com/wcag/3-3-7-redundant-entry.md): Re-typing the same address into shipping and billing. Re-entering an email after the page reloads. WCAG 2.2's new criterion: previously entered data should be auto-populated or selectable, not retyped.
- [WCAG 3.3.8 Accessible Authentication (Minimum)](https://jeikin.com/wcag/3-3-8-accessible-authentication-minimum.md): Cognitive function tests as login gates — remember this string, identify this picture, solve this puzzle — lock out users with cognitive disabilities. The AA criterion: don't require them unless there's an alternative.
- [WCAG 3.3.9 Accessible Authentication (Enhanced)](https://jeikin.com/wcag/3-3-9-accessible-authentication-enhanced.md): At AAA, cognitive function tests are simply not allowed in authentication, with object-recognition and personal-content exceptions intact. Passkeys, magic links, and biometric flows become the practical path.
- [WCAG 4.1.2 Name, Role, Value](https://jeikin.com/wcag/4-1-2-name-role-value.md): Every interactive element must expose three things to assistive technology: what it's called, what kind of control it is, and what state it's in. Get any of those wrong and screen-reader users get a broken UI.
- [WCAG 4.1.3 Status Messages](https://jeikin.com/wcag/4-1-3-status-messages.md): "Your changes have been saved." A sighted user sees a small green confirmation in the corner. A screen-reader user hears nothing — unless the message was announced through a live region. Status messages have to reach everyone.

## Patterns

- [Accessible modal dialog](https://jeikin.com/patterns/accessible-modal.md): A modal that doesn't break for keyboard users, screen readers, or anyone who hits Escape expecting it to close. The pattern AI tools get wrong most often, with the canonical fix.
- [Accessible tabs](https://jeikin.com/patterns/accessible-tabs.md): A tab list that handles keyboard navigation, ARIA state, and focus management the way the ARIA Authoring Practices Guide specifies. The pattern AI tools get wrong by inventing keyboard handlers from scratch.

## Integrations

- [Jeikin with Claude Code](https://jeikin.com/with/claude-code.md): Wire Jeikin into Claude Code's MCP integration so accessibility reviews run inside the same loop as the rest of your engineering work — find issues, fix them, prove the fix in one session.
- [Jeikin with Cline](https://jeikin.com/with/cline.md): Connect Jeikin's MCP server to Cline so the agent that just edited fifteen files runs a WCAG check on every one of them before it stops. Every finding tracked, every fix verified.
- [Jeikin with Cursor](https://jeikin.com/with/cursor.md): Connect Jeikin's MCP server to Cursor so accessibility findings land in the same chat you use for the rest of the work. WCAG-aware reviews, tracked issues, verified fixes, and a dashboard the auditor can read.
- [Jeikin with GitHub Copilot](https://jeikin.com/with/copilot.md): Use Jeikin from GitHub Copilot Chat in VS Code's Agent Mode. Findings land on the Jeikin dashboard, fixes are verified against the WCAG criterion they claimed to satisfy, and the audit trail matches the rest of your engineering work.
- [Jeikin with Windsurf](https://jeikin.com/with/windsurf.md): Connect Jeikin's MCP server to Windsurf so the Cascade agent runs WCAG reviews inside the same flow as the rest of your engineering work — every finding tracked, every fix verified.