The accessibility conversation usually stops at alt tags and ARIA labels. Those matter, and they do nothing for a layout that shatters the moment a user with low vision pushes browser zoom to 150%. I have watched enterprise themes come apart at the seams because the developer typed pixel values everywhere instead of building something that scales. Figma Variables for Accessibility are how you stop guessing about that and start engineering for the 26% of mobile users who raise their default font size.
Why scaling is not optional
A design nobody has viewed at 200% has not been tested for accessibility. The WCAG 1.4.4 Resize Text guideline says users must be able to resize text up to 200% without losing content or functionality, and in most jurisdictions that is now a legal requirement rather than a preference.
The gap between design and production is where it usually goes wrong. A designer hands over a static mockup at 100% scale and the developer is left to work out what happens when 16px body text becomes 32px. That is how you end up with checklist accessibility, which I have argued before is why your accessibility efforts are likely failing. Figma variables close the gap by letting you build a mode for each scale and flip between them.
Setting up Figma variables for accessibility
This only works on a systematized design. If you are still eyeballing spacing and font sizes, the process will find every shortcut you took. The workflow I use:
- Start with number variables. Make a collection for typography, with a
font-sizeand aline-heightvariable for every text style. - Add modes for 100%, 120%, 150% and 200%. In the 200% mode every value is double the 100% baseline.
- Then pay the Auto Layout tax. Elements that are not wrapped in solid Auto Layouts will burst out of their containers, so reach for Hug or Fill rather than a fixed width.
Toggling between the modes shows you where the visual hierarchy gives up. A headline that reads well at 100% can turn into a wall of text at 200%. That is the point to refactor, not later when you are deep in the CSS.
Translating the variables into CSS
Once the scaling logic holds up in Figma, implement it with relative units. Font sizes never go in px. Use rem so the browser’s root setting actually reaches your layout. Pair that with advanced CSS contrast techniques and the UI stays legible whatever the variables are set to.
How I handle the scaling variables in production, using CSS custom properties:
/* Define the scaling logic based on the Figma Variable modes */
:root {
--bbioon-base-font-size: 1rem; /* 16px default */
--bbioon-scale-factor: 1; /* This changes based on user zoom/settings */
--text-sm: calc(0.875rem * var(--bbioon-scale-factor));
--text-base: calc(var(--bbioon-base-font-size) * var(--bbioon-scale-factor));
--text-lg: calc(1.25rem * var(--bbioon-scale-factor));
--text-xl: calc(1.5rem * var(--bbioon-scale-factor));
}
/* Example of a fluid container that respects scaling */
.bbioon-content-card {
padding: 1.5rem;
display: flex;
flex-direction: column;
gap: calc(1rem * var(--bbioon-scale-factor));
min-height: min-content; /* Prevent content clipping */
}
The pitfalls that keep coming back
Fixed-height headers are the one I keep running into. A height: 60px; header plus menu text at double size is a broken site. Use min-height, or let the padding decide the height. Icons are the other one. Text that scales next to icons that stay tiny loses the visual affordance, so drive the icon dimensions from Figma’s number variables as well.
If this kind of design system work is eating your dev hours, I do it for a living. I have been wrestling with WordPress since the 4.x days.
The bottom line on accessible scaling
Accessibility is an architectural decision, not a feature you bolt on at the end of a sprint. Figma Variables for Accessibility commit you to a design system that holds up under pressure, and yes, that means actually learning Auto Layout. What you get back is not having to rebuild a broken layout in the middle of a client audit. Design for the messy way people really use the web rather than the perfect scenario in the mockup.