Testing With a Keyboard Only

I spent three hours last Tuesday untangling a “premium” theme that promised everything but delivered a nightmare of unreadable contrast and broken keyboard navigation. It’s the same old story: developers slap a flashy demo together, call it “accessible,” and leave the actual work to us. Most people think you need a massive budget or a specialized certification to figure out how to test a theme for accessibility, but that’s just another way to sell you a solution you don’t need. Honestly, if a theme’s core decisions are fundamentally broken, no amount of expensive plugins will save your site from being a useless barrier to your users.

I’m not here to give you a theoretical lecture or a checklist of jargon that sounds good in a boardroom. I’m going to show you how I actually audit a theme’s DNA before I let it anywhere near a client’s server. We’re going to look at the real-world friction points—from screen reader compatibility to focus states—so you can stop guessing and start knowing if a theme is built to last. No fluff, just the practical steps I use to make sure the decisions made by someone else don’t become my problem later.

Run Your Own Wcag Compliance Checklist

Look, you can run all the automated web accessibility auditing tools you want, but don’t let a green checkmark fool you into thinking you’re finished. Those tools are great for catching low-hanging fruit, but they lack the intuition to tell you if a site actually feels broken. I always start by running through my own manual WCAG compliance checklist because I want to see how the theme handles real human interaction, not just code syntax.

The first thing I do—and you should too—is try navigating via keyboard only. If I can’t tab through the entire menu structure or reach the call-to-action buttons without a mouse, the theme is a failure. I’m looking for visible focus indicators; if the “focus ring” disappears or is too faint to see, the developer prioritized aesthetics over usability, and that’s a massive red flag for me.

Next, I dig into the visual layer. It’s not enough to just “look good”; you have to respect color contrast accessibility standards. I’ve inherited far too many beautiful, minimalist themes where the light gray text on a white background makes it practically invisible to anyone with visual impairments. If the contrast ratios aren’t there, the design isn’t good—it’s just loud.

Audit Their Color Contrast Accessibility Standards

Don’t let a “minimalist” aesthetic fool you into thinking a theme is actually good design. I’ve inherited more client sites where the designer thought a light grey font on a white background looked “sophisticated,” only to realize they’d effectively locked out anyone with even a slight visual impairment. When I’m checking color contrast accessibility standards, I’m looking for more than just vibes; I’m looking for math. If the contrast ratio between your text and its background doesn’t hit that 4.5:1 sweet spot for normal text, the theme is failing before you even hit publish.

I don’t rely on my eyes alone—honestly, I trust my eyes far too much for my own good. I pull out actual web accessibility auditing tools to see if the theme’s preset color palettes are actually usable. A lot of these bloated themes come with “pre-styled” buttons that look great in a demo but become invisible the second you try to swap in your own brand colors. If a theme makes it difficult to maintain high contrast without fighting the code, it’s not a tool; it’s a liability. Don’t settle for a theme that forces you to choose between style and usability.

Stop trusting the "accessibility ready" badge and do this instead

• Break the site with your keyboard. If I can’t navigate your entire menu and every single button using nothing but the Tab and Enter keys, your theme is a failure. I don’t care how pretty it looks in a mockup; if it’s a keyboard trap, it’s broken.
• Hunt down the “ghost” labels. I’ve inherited more sites than I care to admit where form fields look fine but have zero programmatic labels. If a screen reader hits a search bar and just says “edit text” without telling the user what it’s for, you’ve already lost.
• Check the focus states. It sounds trivial, but it’s not. When I tab through a site, I need to see exactly where I am. If your theme hides the focus outline because “it ruins the aesthetic,” you’re effectively making the site invisible to anyone not using a mouse.
• Audit the heading hierarchy. A theme shouldn’t just let you pick font sizes; it needs to enforce a logical structure. I look for H1s through H6s that actually follow a sequence. If a developer skips from an H2 to an H4 just to make the text smaller, they’re making my job impossible.
• Test the alt text flexibility. A good theme shouldn’t force “decorative” images to be part of the document flow in a way that confuses assistive tech. I check to see if the theme allows for truly null alt attributes so screen readers can actually ignore the fluff and focus on the content.

Stop Guessing and Start Auditing

Look, testing a theme isn’t about checking a single box and calling it a day; it’s about dissecting the architecture of the decisions the developer made before you even hit “install.” We’ve already covered how to run your own WCAG checklist and why you can’t trust a theme just because it looks clean—you actually have to verify the color contrast and the keyboard navigation yourself. If you skip these steps, you aren’t just inheriting a design; you’re inheriting a technical debt of exclusion that you’ll eventually have to pay for when a client’s site becomes unusable. Don’t let a pretty demo site fool you into thinking the underlying code is actually accessible.

At the end of the day, my job—and yours—is to ensure that the web stays functional for everyone, not just the people using a high-end mouse and a 4K monitor. A theme is a foundation, and if that foundation is built on poor accessibility choices, the whole structure is compromised from the start. Stop treating accessibility as an afterthought or a “plugin fix” and start treating it as a non-negotiable design requirement. When you take the time to audit these decisions upfront, you aren’t just being a better developer; you’re building a web that actually works for the people who use it.

About Rasheeda Volkov

A theme is a set of decisions somebody else made. I read them before installing.