Accessibility for Designers - what to consider

Stuart Harland

28 July 2025

Everyone should be involved

When people talk about accessibility, designers are often left out of the conversation - or seen as having to ‘fix’ things after the fact. But many of the most important accessibility decisions happen long before any code is written. In fact, some of the biggest wins start at the design stage.

This introduction article is for anyone involved in UX, UI, or visual design - whether you’re working in Figma, sketching wireframes, or designing full user journeys. You don’t need to be a Web Content Accessibility Guidelines (WCAG) expert to make more inclusive choices. You just need to know what to look out for, and where you can make a difference.

Mindset change: accessibility doesn’t kill creativity

A common thing I hear from some designers is that ‘accessibility kills creativity’ - that you’ll be stuck using dull colours, huge fonts, and can’t experiment or push ideas. That fear is understandable, especially when ‘accessible’ gets wrongly mistaken for ‘safe’ or ‘boring’.

as a designer, you’re in a powerful position to shape how inclusive, usable, and effective a product can be, before it ever gets near the browser.

But real creativity isn’t about doing something radical just for the sake of it, or just to satisfy yourself. It’s about solving problems in thoughtful, user-focused ways. And accessibility is part of that. Designing something that still works when zoomed in, is translated, browsed using a screen reader, or with a keyboard - that’s design at its most considerate and functional.

Rather than thinking of accessibility as a limitation, think of it as designing with more real-world users in mind - different devices, abilities, environments, and needs. These ‘constraints’ can lead to better outcomes and can offer a more satisfying creative challenge when approached with the right mindset.

Kick-off: consider accessibility early

Some of the most important accessibility conversations happen before a single component is designed. If it doesn’t come up at the start, there’s a risk it gets ignored until it’s too late or too costly to fix.

What to do:

• Welcome accessibility as a consideration from day one.
• Ask what the WCAG compliance level or legal standards the project needs to meet (e.g. WCAG 2.2 AA - you should always aim for this.)
• Check if personas and journeys include a range of users - especially users who navigate differently, use assistive tech, or face things like cognitive load.
• If being used, suggest a design system or UI library that has solid, well tested accessibility fundamentals.

What to flag:

• Tight timelines that leave no room for design testing or iteration.
• Projects that treat accessibility as a ‘dev problem’ or something to look at before going live.
• Stakeholders who assume ‘our users won’t need this’.

During design…

This is where you can make a real impact. Your choices around typography, layout, colours, and component structure play a big role in how accessible a design ends up being. So putting in the thought at this stage helps avoid a lot of design and technical debt later on.

Typography

Good typography is readable, flexible, and works across devices. Getting typography fundamentals right can make your design more inclusive, especially for users with visual impairments, cognitive differences, or users browsing in challenging conditions.

What to check:

• Don’t go below 12pt/16px - text smaller than this can become difficult to read on many devices, especially for users with low vision or when zoomed..
• Set a sensible line height - good line height (aim for 1.4 - 1.6) improves readability by giving the eye enough space to track from one line to the next.
• Don’t rely on light grey or very thin fonts for body text - low contrast or ultra-light typography makes reading harder, especially for users with visual impairments or using poor displays.
• Keep paragraph lengths reasonable (consider around 65-75 characters per line) - lines that are too long make it harder to track back to the next line.
• Do not use ALL CAPS - this reduces word recognition, which slows down reading and can also feel shouty or aggressive.
• Rotated text can be hard to read - vertical or diagonal text can break reading patterns depending on the language.

Colour and contrast

Colour can be expressive, but poor contrast is one of the most common accessibility issues.

What to check:

• Use contrast checkers for all text - especially on background images/videos or coloured/gradient blocks. Visual contrast can vary across devices and lighting conditions, so checking ensures text remains readable in the real-world.
• Use 4.5:1 contrast for normal text, 3:1 for larger text - these are WCAG minimum contrast ratios that help ensure readability for users with low vision, or colour sensitivity, or even in poor lighting conditions.
• Don’t use colour alone to convey meaning - pair it with icons and text as additional cues ensure clarity for everyone.

Buttons, links, and touch targets

Interactivity should be obvious and easy for everyone, including people using a keyboard, screen reader, or a touch device.

What to check:

• Buttons and links should have a minimum 24 x 24px target area for AA, and 44 x 44px for AAA. Larger targets reduce the chance of accidental taps, especially on mobile or for users with limited dexterity. Find out more about touch target sizes.
• If you provide designs for hover states, also provide clear focus states. Keyboard users rely on focus indicators to navigate, and without them, interfaces can become confusing.
• Check text links are clear and obvious, and do not rely on colour alone to be visually evident. Users with colour deficiencies may not see a difference compared to the body text, so always use decorations like underlines or other visual cues make things clear.
• Icon-only buttons should really also include a visible label or description. Icons can be ambiguous or misinterpreted, so accompanying text helps all users understand purpose.

Icons and visual context

Icons can help clarify meaning, support navigation, and add visual interest, but they can just as easily confuse users if they’re ambiguous or overused. Without clear context, icons risk becoming part of a guessing game, especially for users who are unfamiliar with the interface or rely on assistive technologies.

What to check:

• Always provide a text label or visible description along with icons. As mentioned above, icons alone can be unclear or interpreted differently, so accompanying labels ensures the meaning is clear for all users, including screen reader users.
• Avoid using icons as the only navigation or action (especially for mobile menus). Clear navigation supports discoverability and usability
• Do not overuse UI patterns that rely heavily on icons (e.g. menus or toolbars with no labels) - as users shouldn’t have to guess what an option is for.

Navigation and layout

Navigation should be simple, predictable, and resilient across screen sizes and languages. Good navigation helps users stay in control of their journey.

What to check:

• Use clear headings and a consistent layout - a clear structure helps all users orient themselves, scan content quickly, and navigate with familiarity and ease.
• Make sure the primary navigation can handle longer translated text on multilingual sites. Some languages take up significantly more space, so navigation should adapt without breaking layout or hiding links.
• Avoid complex multi-tier mega menus unless absolutely necessary - and heavily test keyboard access and usability. Huge, milti-layered menus are often difficult to navigate on mobile or with a keyboard, so what seemed a good UX solution, ends up becoming a barrier.
• Ensure navigation menus do not disappear or ‘collapse’ awkwardly. If menus vanish unexpectedly or at the wrong time, it can really confuse users or interrupt navigation.
• Do not overuse off-canvas or hidden menus. This can slow users down and can be missed entirely. This pattern can work well on mobile, but it shouldn’t become the default on desktop as well.

Forms and inputs

Form accessibility is a major consideration, and many of the most common issues can start at the design stage. Poor layout, no use of labels, or unclear instructions can all create serious barriers. A well-designed form should be clear, logical, and easy to complete - regardless of device or familiarity with the content.

What to check:

• Every input should have a visible, associated label - these provide essential context for screen readers (and all users), so without them, the purpose of form fields can be confusing.
• Instructions should be shown clearly - not hidden behind tooltips, info icons, or question marks. If things are hidden, it makes it harder for users to complete forms accurately, so just have clear, visible instructions to reduce friction and errors.
• Use plain language and group related fields logically. Simple language and a clear structure make forms easier to understand and complete.
• Flag required fields clearly, and don’t rely on just a red asterisk or colour cue to indicate. Not everyone can see or interpret colour or icons, so just use plain text (e.g. ‘email is required’) to make things clear.
• Do not rely on placeholder text alone and ensure placeholder text has appropriate colour contrast (if used). Placeholders should never replace the use of proper labels.
• Do not overly use modal or pop-up forms - they might not work well on smaller screens, screen readers, or with keyboards-only navigation.

Managing client expectations

Sometimes you’ll need to push back on client requests that aren’t accessible or very user-focused, and help the client see why it matters. This might mean saying no to trends or patterns you already know cause problems, offering alternatives to ideas that could cause problems, or explaining the rationale for seemingly ‘straightforward’ design choices.

What to do:

• Be ready to explain why a change is needed - e.g. ‘this icon needs a label, so users know what it does - currently it’s not clear.’
• Offer alternatives: ‘Your brand colours look great in print, but for online use we’ll need to tweak a few of them to meet accessibility standards. We could put together a web-friendly version of your palette that still feels on-brand.’
• Many assume accessibility means plain design – so show examples of amazing, accessible sites to help shift that viewpoint.
• It’s easy to feel pressure to mirror other sites, especially if a client says, ‘Just copy what our competitor is doing on their site.’ But if those sites aren’t accessible, it’s time to push back and suggest a more inclusive approach that still meets the brief.
• Push back on brand font and size choices if they risk readability - particularly if they’re too small, too thin/light, hard to read, or just not suited for digital use.

Responding to feedback

If your work is reviewed by accessibility advocates or testers, you might get feedback that feels at odds with your design intentions. That’s normal. What matters is how you respond to it.

What to do:

• Treat feedback as a chance to improve, not as criticism. Everyone should be trying to make the experience better for more users, so think of feedback as an opportunity for refinement, and not fault-finding.
• If you’ve designed something complex, find another example of this online, and try using a screen reader or keyboard navigation yourself to understand how it could be an issue. This helps build empathy and makes it easier to design with real user needs in mind.
• If something clashes with your design vision, work together to get alternatives or tweaks rather than just dismissing feedback. Collaboration leads to better outcomes.
• If feedback seems overly technical or lacks clear rationale, ask for clarification. Accessibility guidance should be understandable, so just speak up if you need more information or want to understand reasoning behind any feedback.
• If something can’t be changed, document the reasons clearly and be honest about the trade-offs. In some cases, the Account Manager or Project Manager may need to speak with the client to help manage expectations and convince them that change is needed. Not every issue can be resolved immediately, but being open about the limitations helps build trust and can keep the project running smoothly.

Be wary: design-to-code tools

More and more these days, there’s a growing number of tools promising to turn designs into code automatically - you have no doubt seen the many SaaS sites popping up, the Figma plugins, or the recently announced Figma Sites. These might be useful in prototyping or for fun personal projects, but shortcuts come with huge caveats.

What to know:

• Some tools don’t generate semantic HTML - headings, landmarks, proper structure can often be missing or wildly incorrect. Semantic structure is essential for screen readers and keyboard navigation, and without it, content becomes difficult or impossible to read and navigate.
• Interactive elements (like modals or dropdowns) lack proper keyboard support or any accessibility considerations. If users can’t access or operate interactive features without a mouse, the experience becomes exclusionary and is then just broken.
• Code output can be bloated and difficult to maintain. Overly complex or unstructured HTML makes future updates harder and increases the risk of introducing more accessibility issues.
• Some designers often have no visibility of the technical issues these tools create. Without understanding the output, accessibility and performance problems can go unnoticed.
• Only treat these tools as quick visual aids, not production-ready output. They’re useful for rapid prototyping, but often not reliable enough for the real-world.
• Always review the output with a developer who understands accessibility. A developer can identify structural, semantic, and interactive issues that automated tools can miss.
• Don’t rely on automation to make things accessible - this needs human thinking and testing. Accessibility depends on context, intent, and user needs - things no automated tool can fully understand or build for.

What to flag:

• Projects or clients expecting design-to-code to replace proper development. These tools just can’t replicate the care, structure, and accessibility of well-crafted front-end code.
• SaaS marketing promises about ‘clean code’ or ‘accessibility out of the box’. These claims are rarely accurate, and accessible, maintainable code requires human decisions, testing, and refinement beyond what automation can deliver.
• Anyone planning to hand off directly from Figma-to-code tools without a build phase. A plugin alone isn’t a replacement for thoughtful development.

Please watch Kevin Powell’s video: Figma Sites is worse than you might have thought for an example of the problems these tools can create.

Ultimately, if you want your designs to become accessible websites, learn HTML, CSS, and JavaScript - or collaborate closely with a front-end developer.

Conclusion

Accessibility isn’t something you add at the end, as it comes from the decisions made at every stage of a project. As a designer, you’re in a powerful position to shape how inclusive, usable, and effective a product can be, before it ever gets near the browser.

By checking key elements like type, colour, interactivity ideas, and layout - and by having open conversations with clients and the other teams - you can make a real impact. You don’t need to be an expert in WCAG or assistive technologies to spot when something might be an issue.

Think of accessibility as being part of design quality. It makes things easier to use, clearer to understand, and available to more people - which is what good design should be about.

So, if you’ve ever wondered whether it’s your job to consider accessibility: yes, it is - and you’ve got real power to make things better.

Resources, References & Tools

• WCAG 2.2 Guidelines
• WebAIM Contrast Checker
• Designing for Web Accessibility
• Figma Sites is worse than you might have thought