nataliemac7.bsky.social

@nataliemac7.bsky.social

"I have a master's in software development, and accessibility was never in the curriculum." A developer told me that last week. When accessibility gets missed, it's almost never that people don't care. It's that no one ever taught them. That's a far more hopeful problem to solve. #a11y

A carousel that only advances by swiping leaves out everyone who can't swipe: head pointers, eye tracking, tremors, one finger. That's WCAG 2.5.1 Pointer Gestures. The fix: add previous and next buttons. Keep the swipe, just don't make it the only way in. #a11y

We spent close to seven months rebuilding Visual Mode, the part of AAArdvark people rely on most. It already worked - that was the problem. "Works" isn't "works reliably," and reliable is a feature. Rebuilt from the ground up: loads cleanly, easier logins. Give it another look. #a11y

Build anything, anything, and people come out of the woodwork wanting to buy it. I get "want to sell AAArdvark?" emails almost daily. The answer's no. But the knocking isn't really about your thing being special. It's proof you finished something real. Keep building.

The accessibility alphabet soup (ADA, Section 508, EAA, VPAT, Trusted Tester) scares people off before they start. The secret: almost all of it traces back to WCAG (Web Content Accessibility Guidelines), the technical standard. Learn that, then just know which law applies to whom.

"Move fast and break things" is ableism wearing a startup t-shirt. The stuff that breaks first is what disabled people depend on: focus order, labels, contrast, alt text. None of it shows up in a launch demo. Move fast if you want. Just decide on purpose what you won't break.

I've tested so many tab components that look perfect and break the moment you press an arrow key. Today I'm building accessible tabs from scratch, live, testing with a screen reader at every step, using the ARIA tabs pattern. Come build with me: https://bit.ly/3QH8AqL #a11y

Building Accessible Tabs From Scratch

Tabs look simple. A row of labels, a panel of content, click to switch. So why do so many tab components trap keyboard users, confuse screen readers, or do n...

bit.ly

Most accessibility issues aren't bugs. They're design decisions. IBM found ~67% start in design, not code - the contrast, the unlabeled form, the "learn more" links. By code review you're catching most issues at the priciest moment to fix it. Move the conversation earlier. #a11y

For years I thought I was good at accessibility. Keyboard nav, contrast, passing scans. Then I listened to a screen reader read one of my own sites and it was a mess. You don't know what you don't know. Finding that out isn't failure - it's the job. #a11y

What I've spent months on: plain-English fix instructions for every accessibility failure our scanner can flag. More than 300 written so far. The industry solved finding problems. It never solved fixing them. A finding without a fix is just a guilt trip. We're closing that gap, one at a time. #a11y

You are temporarily abled. Burned fingers. Arm in a sling. Vertigo. Parent holding a baby. Cracked AirPods on a train. Allergies wrecking low-contrast text. None tick "disabled" on a form. All need your site to work. Disability isn't a fringe. It's most of us, eventually. #a11y

Missed the same 12-pixel close button three times last week. Steady hands. Mouse. Sitting still. The button still won. That's WCAG 2.5.8 failing in real time. Tap targets need 24 by 24 CSS pixels in WCAG 2.2 AA. Walked through the most common failures and CSS fixes on LinkedIn today. #a11y

Five things on GAAD (Global Accessibility Awareness Day): 1 Scanners catch a third. 2 Semantic HTML does most of the work. 3 Keyboard support is the wedge. 4 ARIA is the last resort, not the safety net. 5 And the hardest part isn't the code. It's making the case to the people writing it. #a11y

Most a11y debates aren't really about accessibility. They're about unnamed priorities. Compliance, user experience, time-to-market - these aren't the same goal. They produce different roadmaps. The fastest way to make better accessibility decisions: be honest about what you're optimizing for.

You used to be able to dismiss a11y warnings in AAArdvark but never confirm them - so every scan felt like starting over. Now: one-click confirm or dismiss, batch across instances. Warnings become errors. The list shrinks as you review it. We built this because we needed it.

Steve Frenzel's 4 roles every a11y advocate plays: Adviser - in the room when decisions are made Mediator - translating between teams Smuggler - folding a11y into work scoped as something else Hacker - linters and CI rules to make the right thing easy You're probably already playing three. #a11y