Description
Design world has evolved a lot since the early days of the web, and today we try to make websites that EVERYONE can use. A design that looks clean but that some people can't read or navigate fails at its main job: to communicate with all users. So our goal is to create something more than just visually appealing designs, we want designs that are accessible, where every user, no matter their abilities, can navigate and interact with our product.
In this guide we're going to learn about the most popular Figma plugin for accessibility, Stark, and go through its features. There are other tools out there you can explore, but Stark has everything we need.
Testing tools explained:
Contrast
- Checks the contrast between two layers (for example text and its background) and gives it a score from WCAG, which is the official accessibility standard. You will see two scores: AA and AAA.
- AA is the one you HAVE to pass. It's what the law (the European Accessibility Act) and basically every client asks for. AAA is a bonus, and for some designs it's not even possible, so don't stress about it. Pass AA everywhere and take AAA when it comes for free.
- The numbers, so you can check colors yourself without the plugin:
- Normal text: 4.5:1
- Large text (around 24px, or 19px bold): 3:1
- Icons and borders of input fields: 3:1 (people forget these because there is no text!)
- Tip: fix contrast when you are picking your color palette, not at the end. Changing a brand color after everything is designed is a pain.
Typography
- Flags text that will be hard to read: text that is too small, lines that are too long, and justified text (it makes uneven gaps between words that are really hard to follow, especially for people with dyslexia).
- Fun fact: WCAG has no minimum font size. What it asks for is that people can zoom the text to 200% without the layout breaking. That said, body text under 16px is uncomfortable for a lot of people, so use 16px as your minimum.
Touch targets
- A touch target is the area you can actually tap with your finger. Fingers are much less precise than a mouse, and someone with shaky hands, or sitting on a bus, is even less precise. This tool checks that your buttons and links are big enough.
- 24x24px is the minimum (AA), 44x44px is AAA, and 44 is also what Apple and Google recommend, so aim for 44.
- The tap area can be bigger than what you see: a small 16px icon with padding around it can still be a 44px target.
Vision simulator
- There are many conditions that affect vision, like color blindness, blurry vision or loss of contrast. This tool shows us how people with these conditions SEE our design, so we can fix colors, sizes and contrast.
Annotation tools explained:
Annotation tools are not for testing. They are for marking how things should be built, so the developers know exactly what to do:
Alt text
- Alt text is the name of an image for someone who can't see it. A screen reader reads it out loud instead of the picture. Without it the user just hears "image", or even worse, the file name
IMG_4821.png. - Describe what the image is DOING on the page, not just what is in it. The same team photo could be "Our team outside the Reykjavík office" on an About page, and "Six people laughing together over lunch" on a careers page.
- If an image is only decoration, mark it as decorative, so the screen reader skips it instead of reading out noise.
Focus order
- Many people can't use a mouse and navigate a website with the keyboard only, jumping from one link or button to the next with the Tab key. We decide in which order they move through the page so it makes sense, for example: logo → menu → main button → content → footer. The developers then build it in that same order.
Headings & landmarks
- Headings: we mark which text is H1, H2, H3 and so on, so the developers use the right tags. Screen reader users jump between headings to scan a page, just like you scan a page with your eyes.
- Landmarks: we mark the main sections of the page, like header, nav, main and footer. If a developer uses a
<div>for the menu instead of<nav>, the screen reader just says "group", but with<nav>it says "navigation" and the user knows where they are.
One last thing, and it's the important one!
These annotations are NOT just paperwork. In Module 4 the developers are building them: they learn that a clickable thing has to be a
<button>, that icon-only buttons need a name, and that focus always has to be visible. But they can't guess YOUR decisions: which image is decorative, what the alt text should say, and in which order a keyboard user should move through the page.So if you skip the annotations, nobody can make them up later. And if you add them, they end up in the real product!
What about AI?
AI can help you here, for example you can ask it to suggest alt text for your images or to check if your heading structure makes sense. But always read it through yourself: AI knows what is IN the image, not what it's DOING on your page. And AI is not a replacement for testing your design with Stark.