What is Nystagmus?
I've had nystagmus since birth. If you've never heard of it, nystagmus is an eye condition where your eyes involuntarily move and you have no control over it. It can cause light sensitivity, tiredness and difficulty focusing on a fixed object.
One thing I've noticed over the years is that I naturally move my head to find a comfortable focus point. People sometimes mistake this for me shaking my head or giving them a look because I'm squinting my eyes. In reality I'm just trying to find that relaxed position where I can see comfortably. It's something I do without thinking but it can be misread by people who don't know what nystagmus is.
On top of nystagmus I'm also colour blind, so it's a combination of reduced vision and colour confusion that I've navigated my whole life. What I've found though, perhaps surprisingly, is that being in the tech industry and having a genuine passion for design actually complements both conditions rather than conflicts with them.
How My Conditions Shape My Approach to Design
I've been passionate about design since childhood and I studied a Bachelor of Arts in Computer Games Modelling and Animation. That background gave me a deep understanding of colour theory, visual composition and how design choices affect the people experiencing them. Those skills directly inform how I approach web design today.
Having nystagmus means I take accessibility seriously on every website I build. It's not a box to tick at the end of a project. It's something I think about from the very beginning because I know first hand what it feels like when a website doesn't consider users like me.
Light and Dark Mode
One of the most important accessibility features a website can offer is a proper light and dark mode. For users with nystagmus and light sensitivity, a bright white website can be genuinely uncomfortable to use for any length of time. A well implemented dark mode isn't just a nice visual option, it can make the difference between a website being usable or not.
I say well implemented because there's a big difference between a thoughtful dark mode and one that's just been bolted on. Colours need to be reconsidered for dark backgrounds, not just inverted. Contrast still needs to work. Text still needs to be readable. Getting this right takes care and intention.
Colour theming goes a step further. Being able to adjust contrast and colour combinations can help users find a combination that works for their specific needs. Colours that complement each other naturally while still contrasting well against one another make a huge difference to readability, especially for colour blind users.
WCAG requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Getting contrast right also means making sure interactive elements like buttons and links have visible focus states so keyboard users and those with low vision can always tell where they are on the page.
/* Ensure sufficient contrast for text */
body {
background-color: #ffffff;
color: #1a1a1a; /* Much stronger contrast than a mid grey */
}
/* Never remove focus styles, enhance them instead */
:focus {
outline: none;
}
/* Do this instead */
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 3px;
border-radius: 3px;
}
/* Dark mode using the user's system preference */
@media (prefers-color-scheme: dark) {
body {
background-color: #121212;
color: #e0e0e0;
}
:focus-visible {
outline-color: #90caf9;
}
}
A common mistake is removing the default focus outline with outline: none and not replacing it with anything. For keyboard users and those with visual impairments this makes a website extremely difficult to navigate. Using :focus-visible means the focus style only shows when it's actually needed, keeping the design clean without sacrificing accessibility.
Typography and Readability
With nystagmus, making sure text is readable isn't just about font size. Headings need strong, thick fonts that stand out clearly. Body text needs enough weight and spacing to be comfortable to read without putting unnecessary strain on the eyes. Nothing should require the user to work hard to focus on it.
Font size is just as important. Websites should be easy to magnify without the layout falling apart. Modern browsers now offer excellent built in tools for magnification and colour adjustment and websites should be built to support these rather than fight against them. A user who needs to zoom in to 150% or 200% should still have a comfortable, functional experience.
One of the simplest things a developer can do is use relative units like rem instead of fixed pixel values for font sizes. This means the text scales correctly when a user increases their browser's default font size or zooms in, rather than staying fixed and forcing them to strain.
/* Avoid this */
body {
font-size: 16px;
}
h1 {
font-size: 32px;
}
/* Do this instead */
html {
font-size: 100%; /* Respects the user's browser font size preference */
}
body {
font-size: 1rem; /* Scales relative to the root */
}
h1 {
font-size: 2rem; /* Scales proportionally */
}
The W3C Web Content Accessibility Guidelines (WCAG) recommend that text can be resized up to 200% without loss of content or functionality. Using rem units is one of the most straightforward ways to meet this standard.
Animation and Motion
This one is nuanced. Animation is often discussed purely as something to avoid for accessibility reasons and while that's true for aggressive or excessive motion, subtle animation can actually help some nystagmus users by making elements stand out and drawing the eye to what matters without requiring intense focus.
The key word is subtle. Smooth, purposeful transitions and animations that guide attention rather than demand it. Nothing that flashes, spins or moves continuously. The prefers-reduced-motion media query in CSS is an important tool here, allowing developers to respect a user's system preference for reduced motion and adjust or remove animations accordingly. It's a small thing to implement and it makes a real difference to users who need it.
ARIA Tags and Semantic HTML
Accessibility goes beyond visual design. For users relying on screen readers or assistive technology, the structure of the HTML itself matters enormously. This is where ARIA (Accessible Rich Internet Applications) tags come in, a set of attributes defined by the W3C that help communicate the purpose and state of elements to assistive technologies.
The first rule of ARIA is to use semantic HTML wherever possible before reaching for ARIA attributes. A properly used <button> element is already accessible. A <div> styled to look like a button is not, without extra work.
<!-- Avoid this — a div has no semantic meaning -->
<div class="btn" onclick="handleClick()">Book Appointment</div>
<!-- Do this — a button is natively accessible -->
<button type="button" onclick="handleClick()">Book Appointment</button>
<!-- For icons or images that convey meaning, always add alt text -->
<img src="/logo.png" alt="Hey Jude Hair Salon" />
<!-- For decorative images that don't need to be announced, use an empty alt -->
<img src="/divider.png" alt="" />
<!-- Use ARIA labels when the purpose of an element isn't clear from its text alone -->
<button type="button" aria-label="Close navigation menu">
<svg>...</svg>
</button>
<!-- Use ARIA roles to define landmark regions -->
<nav aria-label="Main navigation">...</nav>
<main aria-label="Main content">...</main>
The W3C WCAG guidelines set out four core principles for accessible web content, often referred to as POUR. Content should be Perceivable, Operable, Understandable and Robust. ARIA tags, semantic HTML, proper contrast and scalable text all feed into meeting these principles and making websites genuinely usable for everyone.
Tools That Help Developers Build Accessibly
Accessibility can feel overwhelming to get right but there are some brilliant tools available that make it much easier to catch issues during development rather than after launch. Here are the ones I'd recommend.
For Nuxt developers
Nuxt a11y is an official Nuxt module that integrates directly into Nuxt DevTools. It uses axe-core under the hood, the same accessibility testing engine used by Google and Microsoft, to scan your pages as you navigate and highlight WCAG violations in real time. You can click any violation to see exactly which element is affected and get guidance on how to fix it. It even generates a full accessibility report during build time, and you can configure it to fail your CI pipeline if violations are found. It's a fantastic tool and one I'd recommend adding to any Nuxt project from the start.
npx nuxi module add @nuxt/a11y
I've also put together a Nuxt 4 accessibility starter template on GitHub that has accessibility baked in from the very beginning. It includes sensible defaults for contrast, focus styles, reduced motion and semantic HTML structure so you're not starting from scratch every time. Feel free to use it as a starting point for your own projects.
For React and Next.js developers
eslint-plugin-jsx-a11y is a static analysis ESLint plugin that checks your JSX for accessibility issues as you write code. It catches things like missing alt text, invalid ARIA roles and non-interactive elements being used as buttons. It's already included in Create React App by default but it's worth enabling the full recommended ruleset if you haven't already.
npm install eslint-plugin-jsx-a11y --save-dev
Then in your ESLint config:
{
"extends": ["plugin:jsx-a11y/recommended"]
}
Because it only checks static code, pair it with @axe-core/react which tests the rendered DOM at runtime and logs violations to your browser console during development.
For React Native developers
If you're building mobile apps with React Native, eslint-plugin-react-native-a11y brings the same linting approach to native mobile development, enforcing accessibility props and roles on touchable components.
Browser tools
Beyond framework specific tools, the axe DevTools browser extension is available for Chrome and Firefox and lets you run an accessibility audit on any webpage with a single click. It's useful for auditing existing sites and catching issues you might have missed during development.
All of these tools check against W3C WCAG standards, so using them in combination gives you solid coverage across both development and testing.
Why This Matters Beyond My Own Experience
Accessibility in web design is often treated as an afterthought or something that only affects a small number of users. But nystagmus alone affects around 1 in 1000 people. Add colour blindness, which affects approximately 1 in 12 men and 1 in 200 women, and you start to realise that designing without accessibility in mind means leaving a significant number of people with a worse experience of your website.
For me this isn't abstract. I've experienced poorly designed websites my whole life and I know exactly how it feels to strain to read text that doesn't have enough contrast, to be overwhelmed by a bright white page or to struggle with a layout that doesn't hold up when magnified.
That experience makes me a better developer and designer. It means the websites I build are more considered, more inclusive and more comfortable for a wider range of users. And that can only be a good thing.