Here I am with another compilation of a few of my thoughts. New and old content.

Before getting into it, I want to address a comment that was made about this newsletter. I'm paraphrasing, but I was told more or less that this newsletter is content dense. That it contains several elements.

Yes, it does. I include several different thoughts, all broken down with headings. Because that's what I like to see in a newsletter. I prefer newsletters that are content rich rather than a newsletter with only one topic. So that's what I do. I hope the table of content and the headings allow you to break down your reading into manageable chunks.

In this newsletter

1. WCAG Levels are like a car
2. From the podcast: Might as well start now with accessibility
3. From the old blog: Show/hide password tutorial
4. Outdated accessibility statements
5. Wrapping up

WCAG Level A vs AA: The Bare-Bones Car

I've spoken to many companies and organizations over the years that didn't know much about accessibility. They looked at the Web Content Accessibility Guidelines. Saw Level A, and thought "well, that's all we really need to meet". Or they got an audit report and thought we can fix all Level A items before fixing all Level AA items, because it's going to reduce our legal risk.

Level A conformance is like driving a car with no seat, no windshield, and no body. You have the chassis, wheels, an engine, and a steering wheel. Technically, you can get from point A to point B. But should you?

The bare minimum isn't usable

Picture yourself in that Level A car. The engine runs. The wheels turn. You can technically drive it down the road. But you're balancing on the chassis. Wind and rain hit you directly in the face. Every bump rattles your bones.

That's what many websites feel like to disabled users when they only meet Level A requirements. Sure, the site works at the most basic level. Screen readers can access some content. Keyboard navigation exists in theory. But the experience can be exhausting, if not painful.

Level AA adds what makes it functional

Now add a seat to that car. Install a windshield. Put on doors and a roof. Suddenly the car becomes something you'd actually want to drive. You can see where you're going. You're protected from the elements. You can sit comfortably for the journey. Level AA success criteria do the same thing for digital accessibility. They add the elements that make websites actually usable for disabled people. Better color contrast so text is readable. Meaningful page titles that help users orient themselves. Consistent navigation that doesn't require guessing.

A question of consensus

Here's what many people don't know: Some Level AA criteria started as Level A. A success criterion might be Level AA simply because consensus couldn't be reached. Meanwhile, disabled users struggle daily because that "optional" feature is missing. Touch targets that are large enough to tap accurately. Text that can be resized without breaking the layout. Error messages that actually explain what went wrong. These Level AA requirements directly affect whether disabled people can complete basic tasks.

Real impact on real people

When your site only meets Level A, disabled users face constant barriers. They squint at low-contrast text. They get lost in confusing navigation. They abandon forms because error messages make no sense. Each barrier means another person who can't apply for a job. Can't buy groceries online. Can't access healthcare information. Can't participate equally in digital society.

What about Level AAA?

If we continue with the car analogy, this is the trim package. Power seats. Heated seats. Features that might look like luxuries on the surface. But they're not luxuries for everyone.

Heated seats aren't a luxury in winter if you have chronic pain. Power seats aren't a luxury if you have arthritis and can't manually adjust the seat. These "extras" are necessities for many drivers. Level AAA works the same way. Sign language interpretation for videos. Enhanced color contrast beyond AA ratios. Detailed help text for complex interactions. These features seem optional until you need them. For many disabled users, they're the difference between struggling through a task and completing it comfortably.

Not every site needs to meet Level AAA for everything. But dismissing these criteria as "nice to have" ignores the real people who depend on them.

Aim higher than the minimum

Don't ask "can we get away with Level A?" Ask "how do we make this genuinely usable?" Level AA isn't a nice-to-have upgrade. It's the baseline for creating experiences that disabled people can actually use.

Yes, you can drive that chassis with wheels and an engine. But why would you when you could have a car that's actually comfortable and safe? Build the full car. Meet Level AA from the start, at a minimum.

From the podcast - Might as well start now with accessibility

Eric Eggert said that you have to start implementing accessibility at some point, why not from the start?

He also said that you shouldn't give up on implementing as much accessibility as you can because it might be too difficult to implement 100%

Eric also said his greatest frustration was that "the whole internet is not accessible. Come on, it's 2018". 8 years on, I wonder if that's still a frustration of his!

You can listen to the whole episode on the podcast website. Or if you prefer, you can read the whole interview with the (human edited) transcript, on the same page.

Show/hide password tutorial

One of my most viewed post on my archived site is a tutorial on how to make show/hide password features accessible. As well as password hints. It's an older piece, but still solid.

I'm resharing this here because I came across three different situations where an accessible show/hide password could have been useful. There you go, I hope it's useful to you!

Show/hide password accessibility and password hints tutorial

Your outdated accessibility statement reveals your real priorities

It's 2026. Your accessibility statement references WCAG 1.0. It recommends Internet Explorer 9 as the best browser to use. You have a serious credibility problem.

WCAG 1.0 was replaced 18 years ago. Microsoft stopped supporting IE9 in 2016. Your statement is a decade out of date, at minimum.

What this actually tells disabled users

When disabled people find your accessibility statement, they learn something important. Not about your accessibility. About your priorities. The words on the page promise commitment to accessibility. The decade-old recommendations tell the real story. You don't care enough to keep basic information current.

If you can't maintain a single webpage, why would anyone trust your accessibility claims?

This goes beyond outdated information

An outdated accessibility statement signals systematic neglect. Nobody reviewed it. Nobody updated it. Nobody noticed it was wrong. That same neglect probably affects your actual accessibility. If you ignore your public accessibility promises, you likely ignore the work behind them.

Disabled users notice this immediately. They've learned to read between the lines. Outdated statements predict inaccessible experiences.

The compound effect of broken trust

Disabled people encounter accessibility barriers constantly. Every outdated statement adds to that burden. It wastes their time. It erodes their trust.

They read your statement hoping to understand your accessibility support. Instead, they discover evidence that you don't take accessibility seriously. Now they must decide whether to attempt using your product anyway.

That's emotional labor you created. That's time they can't recover.

This problem is completely preventable

Accessibility statements need semi-annual reviews. Add it to someone's responsibilities. Set a calendar reminder. Make it part of your accessibility program.

Update WCAG version references when new versions release. Remove browser recommendations entirely or keep them current. List your actual conformance level honestly.

If you claim WCAG 2.2 Level AA conformance, verify that claim regularly. Test with disabled users. Document known issues transparently.

Your statement is a promise

Every accessibility statement makes a commitment to disabled people. That commitment requires ongoing attention.

Keep your statement current. Review it annually. Update it when standards change. Be honest about your conformance level.

Remember that disabled users judge your accessibility by your actions. An abandoned statement suggests abandoned accessibility work. Your accessibility statement should demonstrate care through accuracy. Make sure it does.

Wrapping up

That's it for now! I hope you enjoyed the newsletter. I'd love to get feedback - What was good? What could be improved? What topic would you like me to talk about? I'm not making any promise, but if a topic you suggest catches my fancy, I'll share my opinion on it.

Just hit reply to this email, or send an email at info@nicolas-steenhout.com. I read every response.

And a reminder that my content is Human Generated Content #HumanGeneratedContent