Aesthetic Appeal vs. Accessibility: The Design Dilemma
Web design has become an art form — designers push for visually striking sites that capture attention. But that pursuit can create barriers. Some design choices that look great make a site harder, or impossible, to use for certain visitors.
We're designers and developers ourselves, and we've made most of these mistakes firsthand. Low contrast because it looked cleaner. Placeholders instead of labels because the form looked tidier without them. We learned where the line is by crossing it first.
This post covers where that tension comes from, the specific design patterns that create it, what to do instead, and the relevant Web Content Accessibility Guidelines (WCAG) criteria behind each one.
Aesthetics vs. accessibility
Web aesthetics covers a site's visual design: layout, color, typography, imagery, animation, and interactive elements. Accessibility covers whether people can actually use the site — including font size, color contrast, alt text, and navigation structure — regardless of physical or cognitive disability.
At first glance these can look opposed. A heavy, image-and-animation-driven site may look impressive but load slowly, creating a barrier for users on slow connections. Small, light-colored type on a white background can look sleek but be unreadable for users with visual impairments.
Finding the Balance
Aesthetics and accessibility aren't mutually exclusive. A site using high-contrast color, large legible type, and clear navigation can be both visually strong and highly accessible.
Design is about solving problems. A designer's job is finding the best solution — whether the problem is visual impact or usability for everyone. That means trade-offs: sometimes an aesthetic choice gives way to an accessible one. It doesn't mean accessibility costs you the aesthetic — it means finding a more creative solution that serves both.
Popular Trends of Attractive but Inaccessible Design
1. Low Contrast Color Schemes
Low contrast text is hard or impossible to read for users with low vision or color blindness — a real barrier to the content itself.
It also affects users with normal vision, especially in low light or on lower-quality displays: blurry, straining text that pushes people to leave the site or look elsewhere for the same information.
Contrast checking tools: WebAIM's Contrast Checker tests your color pairs against WCAG's thresholds for text and UI.
Those thresholds are: 4.5:1 for normal text and 3:1 for large text (WCAG SC 1.4.3, Level AA), and 3:1 for meaningful UI components and graphical objects like icons and chart elements (WCAG SC 1.4.11, Level AA). It flags combinations that fall short and helps identify fixes — adjusting foreground/background colors, or the palette itself.
2. Unnecessary Motion
Motion adds visual appeal but can distract or overwhelm users with cognitive or vestibular disorders. Hover effects specifically create problems for users with mobility or dexterity limitations, and for touch-screen users where "hover" doesn't translate cleanly.
Here are some examples of safe, risky, and non-compliant motion effects:
- Safe motion effects: subtle animation that guides attention or signals a page transition — helps users track where they are.
- Risky motion effects: fast or strobing animation that can trigger nausea or dizziness in users with vestibular disorders or epilepsy.
- Non-compliant motion effects: animation the user can't pause or stop, or that triggers automatically without any input.
That last tier maps directly to WCAG: any moving, blinking, scrolling, or auto-updating content that starts automatically, runs more than five seconds, and appears alongside other content must be pausable, stoppable, or hideable (WCAG SC 2.2.2, Level A). Flashing content is a separate, stricter bar — nothing may flash more than three times per second, since that can trigger seizures (WCAG SC 2.3.1, Level A). And content that appears on hover or focus — including hover-triggered menus and tooltips — must be dismissible without moving the pointer, and stay visible long enough to interact with (WCAG SC 1.4.13, Level AA).
Prioritize user control. Avoid animation the user didn't ask for and can't stop. Test motion design with real users, including people with disabilities, and check it against WCAG's actual requirements rather than instinct.
3. Automatic Audio or Video
Autoplaying media is disruptive for users with sensory processing difficulties, and simply unwelcome in quiet environments like offices or libraries.
More critically, autoplay can directly conflict with screen readers — competing audio makes it hard or impossible for users with visual impairments to follow what their screen reader is announcing.
WCAG sets a firm line here: if audio plays automatically for more than three seconds, users need a way to pause or stop it, or to control its volume independently of their system volume (WCAG SC 1.4.2, Level A).
4. Overuse of Decorative Elements
Heavy decoration clutters a page and makes it harder to tell meaningful content from visual noise — especially for screen reader users navigating by structure rather than sight. A page full of decorative icons can bury the actual navigation links or headings a user is looking for.
Use decoration sparingly, and mark it as decorative — empty alt text on decorative images, for instance — so assistive technology skips past it.
Every other piece of non-text content needs a text alternative that serves the same purpose (WCAG SC 1.1.1, Level A). Simplifying the overall design, prioritizing what users actually need to find, does more for accessibility than any single fix.
5. Placeholders Instead of Labels
Placeholder text is a common way to keep forms visually clean — but it's not a substitute for a real label. Placeholders disappear the moment a user starts typing, so anyone using a screen reader who reaches the field after that point gets no indication of what's expected.
Placeholders are also typically lower-contrast than labels, which compounds the problem for users with low vision.
Use both: a real, persistent label next to or above each field, with placeholder text as supplementary guidance — never the only source of what the field is for.
WCAG requires a visible label or instruction whenever a field asks for input (SC 3.3.2, Level A), and requires that the label's relationship to its field be programmatically determinable, not just visually implied (SC 1.3.1, Level A) — which is exactly what a real <label> element does and a placeholder can't.
6. Non-Intuitive Navigational Elements
Hidden menus and unfamiliar icons slow users down — a bigger problem for users with cognitive disabilities or less familiarity with current web conventions.
The "hamburger" menu is the clearest example. It's a useful way to condense navigation into limited space, but it's not automatically the right choice. A site with only a few main pages may be more usable with those pages listed directly in the nav bar. A site built for an audience less familiar with the convention may be better served by a traditional menu.
The decision should follow the site's actual structure and audience — not default to a trend.
If you do use a hamburger menu, pairing the icon with a visible "Menu" label removes the ambiguity — it costs almost nothing and works for both unfamiliar users and screen reader users who need a clear accessible name on the control either way.
7. Poorly Formatted Text and Small, Fixed Font Sizes
Mixing fonts, sizes, and colors within the same block of text makes it harder to read, especially for users with visual impairments. Aim for clean, consistent typography.
Font size matters just as much: small or non-adjustable text shuts out users with low vision. WCAG requires that text can be resized up to 200% — via browser zoom or a page's own controls — without losing content or functionality (SC 1.4.4, Level AA).
8. Using Images Instead of Text
Screen readers rely on alt text to convey what an image shows — they can't interpret the image's visual content on their own. Using an image for a "Submit" button, for instance, means the button's meaning exists only if the alt text is present and accurate. Real text carries that meaning directly, and it's also the only version a low-vision user can resize, recolor, or otherwise adjust to their needs.
WCAG requires real text over an image of text whenever the same visual result is achievable with real text — logos and brand marks are the standard exception (SC 1.4.5, Level AA). Where an image is genuinely necessary, it still needs accurate alt text (SC 1.1.1, Level A).
This is a trend already shifting: more designers now default to real text for buttons and functional elements, sized and contrasted properly, as accessibility awareness grows.
Conclusion
The tension between aesthetics and accessibility is a reminder that design is about solving problems, not just creating beautiful things. Put user needs first, make the necessary trade-offs, and stay open to finding a better solution — that's what makes a site both visually strong and genuinely usable by everyone.
AxAll helps organizations meet EU accessibility law – through EN 301 549 audits and remediation, a compliance platform, and expert consultancy.
Schedule a discovery call to start making your digital products compliant and accessible to people with disabilities.
Newsletter subscription
Twice a month we send insights, event updates, and valuable resources on best accessibility practices in Lithuania, the Baltics, and the EU market. Subscribe to get the latest knowledge and stay informed.
