Accessibility for Designers: 10 Barriers to Inclusive Design

Graphic designers, UI specialists, and service designers consistently deprioritise accessibility, often for the same reasons. This knowledge base names those reasons honestly, then presents the evidence-based reality behind each one.

These are not edge-case attitudes. They appear in design reviews, brand guidelines, sprint retrospectives, and client briefs across every industry. Understanding where they come from is the first step to addressing them, in yourself and in your team.

Creative Control

"Accessibility kills creative freedom"

"If I follow WCAG, every design will look the same. It's all corporate blue on white."

This is the most persistent myth in accessible design. It assumes WCAG is a visual style guide rather than a set of perceivability and operability requirements. Contrast ratios govern text against its background. They say nothing about layout, typography personality, illustration, motion, or the overwhelming majority of visual design decisions.

The reality

Apple, Spotify, Airbnb, the BBC, and the Australian Government Design System all meet WCAG 2 Level AA and are regularly recognised for design excellence. WCAG constraints apply to a narrow subset of design decisions. Working within them is a creative skill, not a creative surrender.

Creative Control

"Our brand colours can't meet contrast requirements"

"Our brand guidelines use light grey body text and a pale logo. We can't just change the brand."

Contrast requirements (4.5:1 for normal text, 3:1 for large text and UI components) apply only to specific text-on-background and UI-element combinations. They do not apply to logos, decorative elements, disabled controls, or incidental text in photographs. Most brand palettes can be adapted with a one-shade adjustment without compromising brand recognition.

The reality

83.9% of the top one million websites fail contrast checks (WebAIM Million, 2026), making low contrast the single most common WCAG failure. A slightly darker shade of any brand colour still reads as that colour. Contrast is a physical property of human vision, not a design preference. Brands that ignore it exclude 4.4 million Australians with low vision or colour blindness.

Process & Responsibility

"Alt text isn't a design decision"

"That's a content team problem. We supply the images, writing descriptions is someone else's job."

Alternative text for images is WCAG 1.1.1, Level A, the most fundamental requirement in the standard. And it is inherently a design decision: only the designer knows whether an image is decorative, informational, or functional. A decorative image gets an empty alt attribute (alt=""). An informational image needs a description that conveys the same meaning as the visual. That decision cannot be made by a content editor who wasn't in the room when the image was chosen.

The reality

53.1% of the top one million website homepages have images with missing alt text (WebAIM, 2026). Design handoff documentation should include an alt text decision for every image: decorative (null), informational (description), or functional (button action). This takes seconds per image and prevents one of the most common screen reader failures.

Process & Responsibility

"I design in Figma, accessibility is a developer concern"

"Accessibility happens in code. My job is done when I hand off the designs."

Decisions made in a design file, heading hierarchy, button versus link, reading order, form field labelling, colour combinations, touch target size, directly determine whether the built product is accessible. If those decisions are not documented in the handoff, developers must guess. They typically guess wrong.

The reality

Figma supports accessibility annotations natively and through plugins (A11y Annotation Kit, Andiamo). These allow designers to document reading order, alt text decisions, heading levels, focus management, and ARIA roles in the design file itself, closing the handoff gap before a line of code is written. Accessibility is a shared responsibility, and the designer's contribution is the largest single factor in the outcome.

Audience & Business

"Our users don't have disabilities"

"We know our audience. They're young, tech-savvy professionals. Accessibility isn't relevant for us."

21.4% of Australians, 5.5 million people, have a disability, and this figure rises to 52.3% for Australians over 65. More importantly, disability is not a fixed category: temporary impairment (broken arm, eye surgery recovery), situational limitation (bright sunlight, noisy environment, one hand occupied), and cognitive fatigue affect every user at some point.

The reality

The principle of designing for the extremes benefits everyone in the middle, the curb-cut effect. Good contrast helps users in sunlight. Large touch targets help users on mobile one-handed. Clear structure helps users in a hurry. The assumption that "our users don't have disabilities" is statistically false for any product with more than a few dozen users.

Creative Control

"Focus indicators are ugly, we remove them"

"We use outline: none in our global CSS to clean up the design. The browser default ring is terrible."

Removing keyboard focus indicators is one of the most severe and common WCAG failures in production. Keyboard users, including people with motor impairments, power users, and blind screen reader users, depend on a visible focus indicator to know which element is active. Removing it makes keyboard navigation impossible in practice.

The reality

WCAG 2.4.7 (Level A) requires keyboard focus to be visible. WCAG 2.4.11 (Level AA, introduced in 2.2) requires a minimum focus appearance size and contrast. The browser default ring can be replaced with a custom focus style that matches the brand, this is the correct solution, not removal. A 2px solid ring in the brand's primary colour, offset from the element, satisfies WCAG and can look excellent.

Audience & Business

"We'll add an accessibility overlay widget"

"There's a plugin that fixes accessibility automatically. We'll just drop it on the site."

Accessibility overlay tools (such as AccessiBe and UserWay) are marketed as one-line code solutions that achieve WCAG conformance. They cannot. An overlay cannot fix missing alt text, inaccessible keyboard navigation, or poor semantic structure, it can only superficially modify the rendered page for some users, sometimes incorrectly.

The reality

Over 800 accessibility professionals signed the Overlay Fact Sheet (overlayfactsheet.com) opposing overlay tools. Screen reader users frequently disable overlays because they conflict with assistive technology preferences. Several organisations have faced legal action after installing overlay tools. Genuine accessibility requires fixing the underlying product, not applying a superficial layer.

Related service: Accessibility Audit
Testing & Process

"We tested it ourselves and it seemed accessible"

"The whole team reviewed it on different devices. Everyone agreed it looked fine."

Visual inspection by sighted designers and developers catches visual issues, not accessibility issues. Screen reader behaviour, keyboard navigation order, focus management, cognitive load, and the meaningfulness of alternative text cannot be assessed by looking at a screen.

The reality

Automated testing tools (axe, WAVE, Lighthouse) detect approximately 30–40% of WCAG failures. The remaining 60–70% require manual testing and real assistive technology. Effective accessibility testing includes keyboard-only navigation, screen reader testing (VoiceOver, NVDA), contrast analysis, and testing with people with disabilities. Our user testing service provides this.

Knowledge & Learning

"WCAG keeps changing, we can't keep up"

"We followed 2.1, now there's 2.2, and WCAG 3.0 is coming. It's a moving target."

WCAG versioning creates an impression of constant upheaval. In practice, the core design requirements, contrast ratios, text alternatives, keyboard operability, logical structure, error handling, have been essentially unchanged since WCAG 2.0 in 2008. Each new version adds a small number of criteria at the margins.

The reality

WCAG 2.2 added 9 new success criteria and removed 1 vs WCAG 2.1. Most of the additions (focus appearance, dragging movements, accessible authentication) affect niche interaction patterns. If your design is already strong on contrast, alt text, focus management, and structure, you already meet the vast majority of WCAG 2.2. Use our WCAG Criteria Search and filter to "2.2" to see exactly what's new.

Related tool: WCAG Criteria Search
Knowledge & Learning

"We don't have time to retrofit the design system now"

"Our design system has 200 components. We'll deal with accessibility in the next major version."

Every inaccessible component in a design system is technical debt that multiplies across every screen that uses it. Deferring fixes to the "next major version" typically means it never happens, the next major version has its own priorities, and the debt grows with every new page built on inaccessible foundations.

The reality

Accessibility built in at design time adds an estimated 1–3% to project cost. Remediating post-launch can cost 10–20x more. A focused design system audit typically identifies a small number of high-impact issues, contrast, focus states, component labelling, that, when fixed at the token and component level, propagate improvements across the entire system at once. The right time to start is now. Our accessibility consulting service can help prioritise a remediation roadmap.

Related service: Consulting & Strategy Training

Ready to Build Accessibility into Your Design Practice?

Our team works directly with designers and design systems to embed accessibility from day one, not as a retrofit.

Talk to Us