Accessibility Checks to Run Inside the Design File

Contrast ratios get checked in a browser. Tap targets get checked on a phone. Focus order gets checked with a keyboard. All of that happens after the design file has already been marked ready for development, which is precisely why so many accessibility bugs turn out to be design decisions wearing a costume. The design file is the cheapest place to catch them, and almost nobody looks there first.

What follows is a set of checks that can be run inside Figma, Sketch, or whatever tool the team uses, before a single line of markup exists. None of them require a plugin purchase or a specialist audit. They require a designer willing to look at the file the way a screen reader, a keyboard, and a tired pair of eyes will eventually look at the built product.

Text contrast measured against the real background

The most common failure in a design file is a contrast check performed against the wrong surface. A label sits at 4.6:1 against white, passes, ships, and then lands on a card with a light gray fill where it drops to 3.1:1. The check was technically run. The result was meaningless.

The fix is procedural: every text layer gets its contrast measured against the actual fill directly beneath it, including any overlay, gradient stop, or semi-transparent tint. Gradients deserve special suspicion. A headline that clears 4.5:1 at the top of a gradient can fail badly at the bottom, and the eye reading a mockup rarely notices because the whole thing looks fine at a glance.

Placeholder text deserves the same scrutiny. It is routinely set at 2:1 or 3:1 on the theory that it is temporary, which it is not. Placeholder text is content, it sits in the same box users must read to understand what goes there, and it fails the same standard as anything else.

Body text sized for the reader, not the composition

Design tools make it trivially easy to set body copy at 13px and let the layout breathe. The mockup looks elegant. Then it ships, and a sizable share of the audience reads it at arm's length on a laptop, or at 200 percent zoom because their eyes are not what they were at 25.

A useful check: set the primary body size in the file to 16px minimum and see whether the layout survives. If the design only works at 13px, the design has a problem that no amount of contrast fixing will solve. The same test applies to line height. Body copy set at 1.2 line height looks tight and editorial in a mockup and becomes a wall of text in reality. Somewhere around 1.5 for running text is a reasonable floor, and designers who insist on tighter settings should be able to say why.

The 200 percent zoom test on a full frame

Zoom the entire artboard to 200 percent and look at what breaks. Text that reflows into a fixed-width container will clip. Buttons sized to their label will overflow. Two-column layouts will crush. This is not a pixel-peeping exercise; it is a preview of what a low-vision user sees when they zoom the browser, and it takes about ninety seconds to run.

The failures found here are usually structural. A card with a fixed height and a three-line description has nowhere for a fourth line to go. A navigation bar with evenly spaced items has no room for longer translated strings, let alone enlarged type. Catching this in the file means the developer builds flexible containers from the start instead of retrofitting them after a QA ticket.

Color used for meaning with no second signal

A red border on an invalid field. A green dot for online status. A chart where four categories are distinguished only by hue. Each of these works for most people and fails for a meaningful minority, and each is visible in the design file if anyone thinks to look.

The check is simple: for every element where color carries information, ask what else carries it. An error field needs an icon or a message, not just a red outline. A status dot needs a label. A chart needs patterns, direct labels, or distinct shapes. Designers often resist this on aesthetic grounds, and they are sometimes right that the first solution is ugly. The second solution is usually fine.

Color blindness simulators built into design tools help here, but they can also mislead. Running a mockup through a deuteranopia filter and declaring victory misses the point. The question is not whether the design still looks acceptable in the simulation. The question is whether the information survives.

Touch targets drawn at their actual size

Mobile mockups are usually displayed at 1x in a frame that fits on a monitor, which means a 32px icon button looks generous on screen and is genuinely small under a thumb. The recommended minimum is around 44 by 44 CSS pixels, and a design file is the only place where that number can be checked before the developer hardcodes the smaller value from the mockup.

Two patterns fail this constantly. Icon-only buttons in dense toolbars, where the visual icon is 20px and the hit area was never specified. And inline text links inside paragraphs, which are legitimately hard to enlarge but which can be given padding or spacing in the design so the developer knows to do it. If the file shows a 24px close button with no invisible padding indicated, the developer will build exactly that.

Spacing between targets matters as much as their size. Two 44px buttons placed 4px apart technically pass the size check and still produce mis-taps. The design file should show the gap, and the gap should be big enough to be deliberate.

Heading levels mapped to the visual hierarchy

Designers choose type sizes. Screen readers choose navigation by heading level. These two decisions are made in different rooms by different people and then reconciled badly at build time, usually by a developer guessing which text is an h2 and which is an h3.

The design file can settle this. Annotating each text layer with its intended heading level, or at minimum marking the page's single h1 and the sections below it, costs a few minutes and prevents the classic outcome where a page has four h1s because every section title looked big. It also surfaces the harder case: a visual hierarchy with three levels where the content only has two. That mismatch is a design problem, and it is better discovered in the file than in an audit.

Focus states designed, not left to the browser

Open the component library and count how many interactive components have a focus state drawn. In many files the answer is zero. Hover states are drawn, pressed states are drawn, disabled states are drawn, and focus, the one state that keyboard users depend on entirely, is missing.

An undefined focus state does not stay undefined. It gets replaced by whatever the browser default is, which on a dark custom button is often an invisible outline against a dark background. The design file is where this gets decided: a visible ring, sufficient contrast against both the component and the surrounding surface, offset so it does not disappear into a same-colored border. Every link, button, input, checkbox, tab, and card that can be clicked needs one drawn in the library.

Forms with labels, hints, and errors in the layout

Form mockups are frequently drawn in their happy state: empty fields, neat labels, no errors. The accessible version of a form has persistent visible labels, hint text where format matters, and error messages positioned so they can be associated with their field. None of that exists in a mockup that only shows the empty default.

A design file that shows the error state, the hint state, and the required-field treatment gives the developer a specification to build against. One that shows only the pristine state guarantees the error message gets invented during development, usually as a red toast at the top of the page that announces nothing useful to a screen reader. Adding those states to the file is unglamorous work, and it is the difference between a form that works and one that merely looks like it does.

Motion and auto-playing elements flagged in annotations

A carousel that advances on its own, a looping hero animation, a video that starts muted in the background: these are design decisions with accessibility consequences, and they are almost never annotated as such. The file shows a pretty loop. It does not show that the loop needs a pause control or that the animation must respect a reduced-motion preference.

The check is to mark every auto-advancing or continuously animating element in the file and note the expected behavior: pause button, stops after a few seconds, disabled under reduced motion. A developer reading a mockup with no such note will build the loop exactly as drawn, and the fix will arrive later as a bug report from someone who could not read the page because the hero kept sliding.

Alt text written into the file, even as placeholder

The single most neglected field in any handoff is the image description. It is usually missing entirely, which leaves the developer to write it in a hurry or, more often, to leave the alt attribute empty. A design file can carry the description in the layer name or a note, and doing so forces a useful design question: what is this image for?

Decorative images get marked decorative and given an empty alt deliberately. Informative images get a sentence describing what they convey. Functional images, like an icon that is the only content of a button, get a label. Writing this in the file while the image is being chosen takes seconds. Reconstructing the intent three weeks later from a screenshot takes considerably longer, and the result is usually worse.

None of these checks require an accessibility specialist, a plugin, or a meeting. They require a designer to spend an hour in the file before calling it done, looking at contrast against real surfaces, zooming the artboard, counting focus states in the library, and annotating the things that only exist as intent. The bugs caught there cost nothing to fix. The same bugs caught after launch cost a sprint, a heated conversation, and a user who quietly gave up.