Semantics for Designers: Why It’s Not Just a Designer’s Task

The designer passed the layout, the developer coded, QA checked the pixels. A month later, an email comes from a user with a screen reader: "I can't pass your onboarding." Open the inspector - half of the buttons is <div>, headers go h1 → h4 → h2, form without label, icon-button without a name.

And the first thought is, "This is for the developer." No way.

Semantics begins in Figma, not the code editor. If the button is drawn in the layout as a rectangle without the status of a “button”, if the titles are arranged according to the font size, and not according to the semantic hierarchy, if the input field lives separately from the signature, the developer will inherit this ambiguity and code as he can. div on top of div.

## Why is this a designer’s problem

Semantics is not “accessibility for the blind,” as is sometimes abbreviated on glides. This is a semantic framework of the interface, on which several things depend at once:

• Screenreaders and voice control – without roles and signatures, the product simply doesn’t work for some people.
• Search Results and Sharing – correct h1, meta, alt directly affect how the page looks in Google and in the preview of the messenger.
• AI Agents and Automation – LLM browsers and autocomplete rely on DOM semantics. There is no div button for the agent.
• **Testability: Autotests that search for roles and names are more stable than CSS selectors. This directly saves the team time.
• **Model-to-Code Transfer — Figma Dev Mode, MCP, coding plugins pull structure from layers. Porridge in layers = porridge in code.

So semantics is not charity. This is the quality of the product, which is visible in the metrics: conversion of mobile users, indexation, onboarding time, support cost.

## Where a designer loses semantics first

### Heading hierarchy by font size

Classic: the layout has three “headers” – 32, 24 and 18 px. The developer looks at the size and arranges h1, h2, h3. And the meaning of the page should be, for example, one h1 and two h2 on the same level, just visually different weights.

Font size is style. The title level is the structure. These are different things, and they need to be bred in the layout.

How to do it in practice:

• In the design system, name styles by meaning: Heading/Page, Heading/Section, Heading/Subsection, not Text/32, Text/24.
• In the layout, sign where h1, where h2. A tag in the frame or a comment in Dev Mode is enough.
• There should be one h1 on the page. If there are two, it’s a design issue, not a developer issue.

### Button, link and "clickable thing"

Visually, it could be the same rectangle. Semantically, three different things:

• Button - action in the current context (send the form, open the modular, add to the cart).
• Link – Switch to another URL, including within the SPA.
• *Switch/Checkbox/Radio - Change of state.

If the designer does not distinguish them in the layout, the developer guesses. And guesses bad: the “back button” becomes <div onClick>, loses focus from the keyboard, does not work in the middle mouse button, is not voiced by the screen reader.

Anti-patterns that you can see right in Figma:

• "Shoot button" without a signature and without a layer name. In code, it will become an icon without aria-label.
• A whole link card that still has a button in it. On layout, this will turn into nested interactives, which is technically invalid.
• A tab is drawn as a set of buttons without specifying which is active. aria-selected is taken from the air.

### Forms without a bundle label ы input

In the layout, the signature “Email” lies above the field as a separate text layer. Technically, it's okay. But if this connection is not fixed, the code will get a field without <label for>, and the tap signature will not focus input – especially on mobile.

A checklist for any field in the layout:

• The field has a visible signature (not just a placeholder).
• The signature and field are grouped into one component/frame.
• Error states, prompts, and "mandatory" are drawn and signed.
• The field has a name in layers, Input/Email, not Rectangle 482.
• The icon inside the field (eye, cleaning) has a name and is described as a button if clicked.

The short summary of the segment: semantics is that part of the quality that the designer puts into the layout, not that which the developer “has to add.” Next, we will analyze how to build this into a design system, review and work with AI tools.

## How to Incorporate Semantics into a Design System

Semantics is not based on the heroism of one designer, but on the fact that the components of the library already carry meaning. If the button in the system is Button and not Rectangle + Text, the chance that it will reach the correct code is much higher.

### Name components by role, not by appearance

Bad names: Blue Box, CTA Big, Card 3. Good names: Button/Primary, Link/Inline, Card/Article, Field/Text, Tabs/Item.

The name in the library is the first thing that a person, LLM, and coding plugin will see. If a component is called by meaning, then later in the code it almost always becomes the correct tag.

### Properties that describe behavior

In variants, it is worth laying not only the color and size, but also the role:

• Button has the property type: button | submit | link. Yeah, just like HTML.
• Input has the properties of label, required, error, helper. If they are not in the component, they will not be drawn.
• Heading has the property level: h1 | h2 | h3 | h4. Size separately, level separately.
• Icon has the property decorative or label. The icon is either decorated or meaningful and requires a signature.

This is the point where a design system begins to speak to development in one language.

### Layer structure = DOM structure

Inside the component, the order and grouping of the layers already prompt the layout. If inside the card first there is a picture, then a title, then a description, then a button - so it will be in the code. If everything is piled into one frame with absolute positioning, the developer will assemble it as best he can.

A simple rule: Open the component layers and read them from top to bottom aloud. It made a meaningful piece of the page -- OK. It turned out "rectangle, rectangle, text, rectangle" - rework.

## Workflow: Where semantics are built into a designer’s day

### At the wireframe stage

Semantics is laid before the visual. You can see on the wireframe: here's the title of the page, here's the section, here's the list, here's the form of three fields. If you do not decompose the structure at this step, then anyone will finish it - except you.

Useful habit: next to the wireframe write in words what kind of screen it is. “Product page. h1 is the name. h2 - characteristics, reviews, similar. The main action is to buy.” Three lines of text save a day of controversy.

### At the layout stage

• Components only from the library. Any Rectangle with onClick in your head is a bell.
• All interactions are named by action type: Button/Add to cart, not Button/Yellow.
• States (hover, focus, disabled, error, loading) are drawn for anything clicked or entered.
• The order of focus is clear from the location. If on Tab the user has to jump first to the right, then down, this should be clearly noted.

### Transferred to development

In Dev Mode or in the comments, we capture what is not visible to the eye:

• Headline level.
• What are the buttons, what are the links.
• Texts for aria-label at icon buttons.
• The order of reading and focus, if different from the visual.
• What is a "living region" - toasts, form errors, load indicators.

It takes 10-15 minutes to screen and takes half of the questions to code review.

### When AI appears in the process

Code generation from Figma, MCP servers, IDE assistants – they all read what you put in the layout. If the structure of the layers is meaningful and the components are named by role, the AI produces a pretty decent code. If the layout of porridge - AI confidently generates a beautiful porridge, and it will be more difficult to fix than to write from scratch.

The main risk here is not “AI will make a mistake”, but “no one will notice that they made a mistake”. Therefore, the AI build still needs to be checked using the same semantic line: the correct tags, the available names, the working keyboard.

## Quick diagnosis of the finished layout

Running through this list takes five minutes and catches most of the problems before they go into the code.

• There's one h1 on the page, and it answers the question, "What is this screen about?".
• Header levels go without jumping: h2 does not appear after h4.
• All clickable elements are Button or Link components, not bare frames.
• Icon buttons have a text signature for the screen reader.
• Each form field has a visible label and states of error and focus are drawn.
• Layers are named in meaning, the library does not have Frame 128 and Group 14.
• The states of selected, expanded, current are clearly marked - both visually and in the captions.
• Modals, toasts and clues are labeled as separate roles rather than "just a plaque on top.".

## Questions to Ask in a Design Review

• If you remove the color and icons, will the structure of the page remain clear?
• Is it possible to pass this screen only from the keyboard? In what order?
• What will the person with the screen reader on the main button hear? And the cross icon?
• What is h1 and why is it?
• What distinguishes a “button” from a “link” in this layout other than color?
• What elements are dynamically changing and should be announced to the screen reader?

If the author of the layout answers these questions confidently, semantics is in place. If it swims, it's better to figure it out now than read bugs through a sprint.

In short, semantics is built into three points – a library of components, habits on the layout and a review before transfer. None of these dots require code, but they determine which product will end up in the browser, in the screen reader and in the hands of the AI agent.

## When an AI agent or MCP comes in

The bundle “Figma → MCP-server → IDE-assistant” now looks like magic: the designer gives the frame, in a couple of minutes a component appears in the repository. But magic works exactly as long as there is a meaning in the layout that the agent can read. Layer names, component types, variants, auto-layouts are not cosmetics for an agent, but the only source of structure truth.

### What the Agent Really Reads

Roughly speaking, the agent sees the layer tree and the properties of the components. From this he tries to guess:

• what is a container and what is content;
• where is the button, where is the link, where is the text;
• what items are repeated and should be a list;
• what changes between options is condition, size, or any other component.

If you have Frame 412 / Frame 87 / Rectangle 3, the agent will honestly generate <div><div><div>. If you have ProductCard / Header / Title, the chance of getting a normal markup is radically higher.

### A workflow that doesn’t fall apart

• Before transferring to the agent, we run the layout on the same checklist as for the human layout designer.
• In the description of the task for the agent, we directly write semantics: “This is a product card, the header is h3, the button is the main CTA, the price is not the header.”.
• Generated code looks primarily at tags and roles, not pixels. The pixels are easy to fix, the plowed structure is expensive.
• Available names and aria-attributes for icon buttons are prescribed by hand or by an obvious prompt. The agent almost never guesses them.

### Anti-patterns when working with AI

• "We'll generate and then we'll figure it out." Do not understand: semantic errors spread over the components and copied further.
• Trust the agent with the headline structure. It will easily put h1 on each card.
• Accept PR from the agent without opening it in the browser from the keyboard and screen reader. Visually everything can be perfect, and Tab flies to nowhere.

## How to check quality if there is no auditor nearby

You don’t have to wait for a separate availability cycle to know that the layout or build is alive. There are some cheap checks that fit on a normal working day.

### Five-minute pass on the finished screen

• Open the page and pass it only with the Tab key. Record the order, mark the places where the focus disappears or jumps.
• Turn on the system screen reader for ten minutes. Listen to the main button, cross icon, form field with error.
• Open the inspector and see the header tree. One h1, then an even hierarchy - or porridge.
• Reduce the window to mobile width and make sure the reading order is not broken.
• Turn off CSS (or view reader mode). If the content is read logically, the structure is alive.

### What to consider "good enough"

Perfect semantics is a myth, especially in large products. It is better to keep three levels in mind:

• Basic: Correct tags for interactives, headings, forms with label, focus visible.
• Worker: states are added to the baseline, live regions for toast and error, meaningful aria-label icons.
• Mature: to work - thoughtful landmark-areas, correct roles in custom widgets, accessibility tests in CI.

Most teams are confident enough to live at the “working” level and pull up the “mature” where it is critical – payment forms, personal account, registration.

## How to explain the decision to the team

Semantics often sounds like “designer picks on.” The argument should not be about rules, but about consequences.

### A language that works

• With the developer: “If it’s div, we’ll have to manually hang the role, focus and keyboard handlers – the button does it itself.”.
• Now on page three h1, the search engine does not know what it is about. The review shows that such pages rank worse.”.
• With the manager: In six months, we'll want to reuse this block. If it's called Frame 128, no one will find it.
• With another designer: "Let's not paint the link like a button - users on the keyboard expect it to behave differently.".

### Questions for the general audit

• What role does each interactive element play – button, link, switch?
• What happens if the user comes here from the keyboard?
• Which messages should be announced automatically and which should be announced only upon request?
• What will a person see and hear if the visual layer does not load?
• Which of this screen will be reused, and will it survive the renaming?

When these questions become commonplace, semantics ceases to be the personal war of one designer and becomes a common standard.

The short summary of the segment: semantics at an advanced level is not more tags, but more discipline. The same checklist works for both a layout designer and an AI agent; the same questions are asked for both a design review and a code review. The smaller the difference between these conversations, the calmer the product lives.

## The final checklist: what should be in your head on each layout

Semantics works well when it becomes part of a routine layout check rather than a separate ritual. Below is a minimum set of items that makes sense to run before throwing a layout into work or taking PR.

### Designer's checklist before transfer

• Each screen has one main title and a clear hierarchy below.
• All interactive elements are named by role: button, link, switch, field. Not "rectangle with arrow.".
• The icon buttons have an accessible name – text in the specification or in the comment to the component.
• Forms have visible signatures, error states and clues, not just placeholders.
• The order of reading coincides with the order in the layout: from top to bottom, from left to right, without surprises.
• The states hover, focus, active, disabled are drawn rather than left “like a browser.”.
• Toasts, banners and online errors are tagged: what is announced automatically and what is not.
• Layer and component names are read by humans, not by an Auto Layout generator.

### Checklist for code review by the designer

• The main CTA is button or a, not div with a handler.
• Headings are not selected by font size, but reflect the structure.
• The list looks like a list and in the markup.
• The modal gets the focus when it opens and returns it back when it closes.
• Hidden visually does not mean hidden to the screen reader, and vice versa.
• Color contrast is not broken by dark theme and brand accents.

## Anti-patterns that pop up regularly

These mistakes are repeated from project to project, regardless of stack and team size. Keep them in your head as a separate list.

### In the layout

• The title for the sake of size. "Get Bigger to Get Noticed" turns into the third h1 on screen.
• Button-link-button. The same item looks like a link or a button in different places. The user on the keyboard ceases to understand what will happen.
• Placeholder instead of label. The field looks clean until it starts typing and then the signature disappears.
• Icon without a name. Cross, triplet, gear without a signature. Eyes understand, ears don't.
• • Grid instead of meaning. * Cards are beautifully built, but the order of reading is zigzag.

### In code and working with AI

• **We'll fix it later. * Semantics are almost never repaired later: they're buried with new components.
• div with onClick as standard. Once allowed - and now it's a template in the codebase.
• Blind run by an agent. PR from AI without opening in the browser, without a keyboard, without a screen reader.
• Aria on top of the pain. When, instead of a normal tag, five attributes are hung to "voice properly.".

## Questions for Design and Product Review

These questions are convenient to ask aloud - yourself, the author of the layout, the developer. They quickly pull out weak spots.

• What is the main element of the screen and why it?
• What happens if you pass that screen just with the keyboard?
• What messages should the user hear, even if they are not looking at the screen?
• Where are the buttons, and where are the links, and does that match the behavior?
• Which of these screens will live in the library in a year, and what is it called now?
• If you remove the visual layer, will you understand what the page is about?

If the team stumbles on these questions every time, it is a signal that semantics is not built into the process, but lives in the head of one person.

## Practical outcome

Semantics is the habit of asking two questions about each element: what it is and how it will be read without a picture. Everything else — tags, roles, attributes, layer names, agent prompts — is derived from these two questions.

When this habit appears, the gap between the layout and the code disappears: the developer does not need to guess what was meant, the agent - to invent the structure, the auditor - to rewrite half the components. There is one common screen model on which everyone relies.

And it is at this point that accessibility, SEO, component overuse, and understandable analytics cease to be separate tasks. They become a side effect of the fact that the layout and markup finally call the same thing – the same.