Accessibility Is a Feature, Not a Checklist

The Day I Couldn't Use My Own Product

Two years ago, I broke my right wrist in a skiing accident. Nothing too dramatic — just a fracture that kept my dominant hand in a cast for six weeks.

Suddenly, I couldn't use my own software.

Not because I'd built something bad. I was proud of that HR dashboard. Clean design, intuitive navigation, responsive layout. But it was designed for two-handed mouse users, and I was now a one-handed keyboard user with a trackpad.

Every dropdown required precise clicking. Every data table assumed mouse hover. Every form had tiny hit targets. The software worked great — for the narrow slice of users who happened to match my assumptions.

That experience changed how I think about accessibility. It's not about compliance. It's not about edge cases. It's about building software that works for everyone, including future-you with a broken wrist, or present-you when you're exhausted at 6 PM and your fine motor control is shot.

Here's the thing most developers don't realize until it's too late: accessibility isn't just the right thing to do. It's also a business advantage.

The Business Case Nobody Talks About

Let's address the elephant: business stakeholders often see accessibility as a cost center. "We'll add it later." "Our users don't have disabilities." "Web Content Accessibility Guidelines (WCAG) compliance takes too long."

Here's the data they're missing:

1. Disability is common and often invisible.

According to the CDC, 26% of American adults have some form of disability. That includes low vision (11%), mobility impairments (13%), and cognitive disabilities (10%). These categories overlap—many people have multiple disabilities, which is why the percentages sum to more than 26%. Many don't disclose, especially in enterprise settings.

2. Situational impairment affects everyone.

• Using your phone in bright sunlight (vision impairment)
• Taking a call while checking email (attention impairment)
• Operating software with a crying baby in your arms (mobility impairment)
• Working in a noisy factory floor (hearing impairment)

Your users aren't always at a quiet desk with perfect eyesight and two free hands.

3. Accessible design improves usability for everyone.

In our HR platform redesign, we made these "accessibility" changes:

• Keyboard navigation for all features
• Clear focus indicators
• Higher contrast text
• Larger click targets

In our internal measurements, user satisfaction scores increased 23% across all users, not just those with disabilities. Turns out, everyone likes buttons they can actually click and text they can actually read.

So what does good accessibility actually look like in practice? Let me break down WCAG in a way that actually makes sense.

What WCAG Actually Asks For (And Why It Makes Sense)

WCAG (Web Content Accessibility Guidelines) is often dismissed as bureaucratic checklist theater. Some of the requirements do feel arbitrary. But the core principles are common sense:

Perceivable

Users must be able to perceive information. This means:

• Text alternatives for images (so screen readers can describe them)
• Captions for video (so deaf users can follow along)
• Sufficient color contrast (so low-vision users can read)
• Don't rely on color alone (8% of men are colorblind)

In practice:

// Bad: Color is the only indicator

 {status}


// Good: Color + icon + text

 {status === 'error' ? '❌' : '✓'} {status}

Operable

Users must be able to operate the interface. This means:

• Keyboard accessible (no mouse required)
• No time limits (or user-adjustable ones)
• No seizure-triggering animations
• Clear navigation

The keyboard test: Put your mouse in a drawer and try to use your app. Can you reach every feature? Can you tell what's focused? If not, keyboard users can't use your product.

Understandable

Users must be able to understand information and operation. This means:

• Clear language (not jargon soup)
• Consistent navigation
• Error messages that explain how to fix the problem
• Predictable behavior (no surprises)

Good error message:

"Email address is required. Please enter a valid email like name@company.com."

Bad error message:

"Validation failed: field_email_01"

Robust

Content must work across different technologies. This means:

• Valid HTML (screen readers depend on proper structure)
• Standard controls (not custom divs pretending to be buttons)
• Accessible Rich Internet Applications (ARIA) labels where needed (and only where needed)

Okay, that's the theory. Now here's the checklist my team actually uses every sprint.

The Practical Checklist We Actually Use

WCAG has dozens of success criteria. Here's what catches 90% of issues:

Before Writing Code

• [ ] Can you describe the feature without mentioning visual appearance?
• [ ] What happens if the user can't see colors?
• [ ] What happens if the user can't use a mouse?
• [ ] What happens if the user is using a screen reader?

During Development

• [ ] Semantic HTML elements (button, not div with onClick)
• [ ] Logical heading hierarchy (h1 → h2 → h3)
• [ ] Form inputs have associated labels
• [ ] Images have alt text (or alt="" for decorative)
• [ ] Focus is visible and logical
• [ ] Color contrast passes (4.5:1 for text, 3:1 for large text)

Testing

• [ ] Keyboard navigation works (Tab, Enter, Escape, Arrow keys)
• [ ] Screen reader makes sense (test with VoiceOver or NonVisual Desktop Access (NVDA))
• [ ] Zoom to 200% and verify layout doesn't break
• [ ] Automated tools pass (axe, Lighthouse)

Now let me show you the patterns that come up over and over in real codebases.

Patterns That Solve Real Problems

Pattern 1: Skip Links

For keyboard users, navigating through 50 menu items to reach the main content is torture. Skip links let them jump straight to what matters:

 Skip to main content


{/* ... navigation ... */}


 {/* Main content */}

The link is invisible until focused, then appears prominently.

Pattern 2: Accessible Modals

Modals are accessibility landmines. Done wrong, screen reader users don't know a modal opened, keyboard users can tab behind it, and closing requires a precise click.

function AccessibleModal({ isOpen, onClose, title, children }) {
 const modalRef = useRef(null);
 
 // Trap focus inside modal
 useEffect(() => {
 if (isOpen) {
 modalRef.current?.focus();
 document.body.style.overflow = 'hidden';
 
 // Trap focus with focusable elements query
 const focusableElements = modalRef.current?.querySelectorAll(
 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
 );
 // ... focus trap logic
 }
 return () => {
 document.body.style.overflow = 'unset';
 };
 }, [isOpen]);
 
 // Close on Escape
 useEffect(() => {
 const handleEscape = (e) => {
 if (e.key === 'Escape') onClose();
 };
 document.addEventListener('keydown', handleEscape);
 return () => document.removeEventListener('keydown', handleEscape);
 }, [onClose]);
 
 if (!isOpen) return null;
 
 return (
 

 
{title}
 {children}
 Close
 
 );
}

Or better yet: use a library that handles this. Radix UI, Headless UI, and React Aria have battle-tested accessible components. Honestly, I wish I'd started with these instead of rolling our own. Would've saved weeks.

Pattern 3: Data Tables That Don't Suck

Tables are semantic gold for screen readers — if you use them correctly:

 
Employee directory - 47 employees
 

 

 
Name
 
Department
 
Status
 
 
 

 

 
Sarah Chen
 
Engineering
 

 {/* Status with multiple indicators */}
 
 ● Active
 
 
 
 

The scope attributes tell screen readers how to navigate. Users can jump by column ("read all departments") or row ("tell me everything about Sarah").

All this code is great, but how do you know it actually works? Here's the testing process that caught issues we never would've found otherwise.

Testing Like You Mean It

Automated Testing (The Easy Part)

Add these to your CI pipeline:

// jest-axe for unit tests
import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

test('form has no accessibility violations', async () => {
 const { container } = render();
 const results = await axe(container);
 expect(results).toHaveNoViolations();
});

Automated tests catch about 30-40% of issues — the easy structural stuff.

Manual Testing (The Important Part)

Once a sprint, test your new features with:

1. Keyboard only. Hide your mouse. Navigate the entire feature using only Tab, Enter, Escape, and Arrow keys.
2. Screen reader. Turn on VoiceOver (Mac: Cmd+F5) or NVDA (Windows, free). Listen to your app. Does it make sense?
3. Zoom test. Zoom your browser to 200%. Does the layout still work? Can you still read everything?
4. Color blindness simulator. Chrome DevTools has a built-in simulator. Can you still distinguish your UI elements?

So does all this effort actually pay off? Here's what happened when we committed to accessibility across our entire platform.

The Payoff

Six months after our accessibility overhaul:

• Support tickets dropped 31%. Clearer error messages and consistent UI reduced confusion for everyone.
• Task completion time improved 18%. Better keyboard navigation helped power users fly through workflows.
• We won a contract. A government agency required WCAG 2.2 AA compliance. We were ready; our competitor wasn't.

But honestly, the best payoff is simpler than any of those numbers: we built something that works for more people.

Remember that broken wrist I mentioned? Last winter I fractured my ankle. (I'm a slow learner when it comes to skiing.) This time, I could use every feature of our product from my couch, one-handed, without a single moment of frustration. That felt like the real win.

At Aark Connect, accessibility isn't a phase we tack on at the end — it's built into every project from sprint one. Curious how your product holds up? Try the keyboard test yourself. And if you don't like what you find, we're happy to help.

---

Related Reading:

• What Happens When 50,000 Students Log In at Once
• The Security Architecture That Passed Our SOC 2 Audit

Need help building accessible enterprise software? Talk to our UX engineering team about integrating WCAG 2.2 compliance into your development process from day one.