How to audit a theme for accessibility and Core Web Vitals

01Why accessibility and speed are one audit

Most people treat accessibility and Core Web Vitals as separate chores. They're really two views of the same question: can a real person, on a real device, actually use this page? Auditing them together is faster and catches problems each would miss alone.

There are three reasons to care, and they reinforce each other rather than compete.

• Legal and ethical baseline — accessibility is now standard practice for any public site, and in many places an expectation rather than a nice-to-have. Building for it is simply how professional sites get built today.
• SEO — Core Web Vitals are a confirmed Google ranking signal, and a clean, semantic, accessible page structure is also the structure search crawlers parse most reliably. Good accessibility and good SEO pull in the same direction.
• User experience and conversion — a fast page that everyone can navigate keeps more visitors and converts more of them. A slow or unusable page leaks both, quietly, on every visit.

The point isn't a perfect score on a dashboard. It's a site that works for the widest set of people on the widest set of devices — which happens to be exactly what Google is trying to reward.

02Auditing Core Web Vitals

Core Web Vitals are three metrics Google uses to score real-world page experience. You measure them with free tools, then read which numbers your theme is responsible for.

The tools: PageSpeed Insights and Lighthouse

PageSpeed Insights is the quickest start — paste a URL and it runs a lab test plus, where available, real-user field data from the Chrome User Experience Report. The field data is what Google actually grades you on. Lighthouse, built into Chrome DevTools, runs the same lab audit locally so you can test staging or password-protected pages.

Run both on your homepage and at least one inner page — a post, a product, a contact page. Themes often behave very differently on a content-heavy template than on the homepage, and a single test hides that.

LCP — Largest Contentful Paint

LCP measures how long until the largest visible element — usually a hero image or headline block — finishes rendering. The target is under 2.5 seconds. It's heavily influenced by your theme: a giant unoptimized hero image, a render-blocking stylesheet, or a slow web font all push LCP up.

INP — Interaction to Next Paint

INP measures responsiveness — how quickly the page reacts when someone taps or clicks. The target is under 200 milliseconds. Heavy JavaScript is the usual culprit: a theme that loads a bulky framework, a sliding mega-menu, or a dozen scripts makes the main thread sluggish and inputs feel laggy.

CLS — Cumulative Layout Shift

CLS measures visual stability — how much the page jumps around as it loads. The target is under 0.1. Images without set dimensions, late-loading ads or banners, and web fonts that swap and reflow text are the common causes, and most of them trace back to how the theme markup is built.

Read the audit this way: each metric points at a category of theme decision. LCP is about your largest asset and render-blocking, INP about script weight, CLS about reserved space. That mapping tells you where to fix.

03Auditing accessibility

Automated tools can catch roughly a third to half of accessibility issues — the measurable, rule-based ones. That's a genuinely useful chunk, and it's where to start before any manual checking.

The tools: Lighthouse, axe DevTools, and WAVE

Lighthouse includes an accessibility audit alongside its performance one, so you get a first pass for free in the same run. axe DevTools (a browser extension from Deque) gives more detailed, lower-noise findings tied to WCAG criteria. WAVE (from WebAIM) overlays icons directly on the page so you can see exactly which element each issue sits on. Running two of them catches more than any one alone.

Tools find the rule-based problems. The rest — does keyboard navigation actually flow sensibly, do focus states stay visible — needs a few minutes of manual testing, covered below.

The common theme-level issues

• Color contrast — text that's too light against its background fails WCAG and is hard to read for everyone, not just low-vision users. Themes love subtle grey-on-white; the audit flags it instantly.
• Focus states — keyboard users need a visible outline showing where they are. Many themes strip the default focus ring for looks, leaving keyboard navigation invisible. This is one of the most common and most overlooked failures.
• Heading order — headings should descend logically (one H1, then H2s, then H3s) without skipping levels. Themes that pick heading tags for size rather than structure break this and confuse screen readers.
• Alt text — every meaningful image needs descriptive alt text; decorative images need empty alt so screen readers skip them. This is mostly content-level, but the theme's image fields and templates can help or hinder it.
• Keyboard navigation — every link, button, menu, and form control must be reachable and operable with the Tab and Enter keys alone. Custom dropdowns and sliders are frequent offenders.
• ARIA and landmarks — proper roles and landmark regions (header, nav, main, footer) let assistive tech jump around the page. Misused or missing ARIA is worse than none, and themes vary wildly here.

Spend two minutes doing the manual test the tools can't: unplug your mouse and navigate the whole page with Tab, Enter, and the arrow keys. If you can't reach a menu, can't see where focus is, or get trapped somewhere, you've found a real issue no automated scan reported.

04How a theme helps or hurts both

The theme is the single biggest lever on both audits because it sets the ceiling. You can optimize content all day, but you can't out-tune a theme that ships heavy and inaccessible by default.

A well-built theme helps on both fronts at once. Lean, modern markup loads fast and gives assistive tech clean structure to read. Semantic HTML — real heading tags, proper landmarks, native buttons and links — is good for screen readers and for crawlers in the same stroke.

A poorly built theme hurts both at once, too. Bloated page builders inject layers of nested divs that slow rendering and bury meaning. Decorative-first design strips focus rings and leans on low-contrast greys. Script-heavy menus and sliders tank INP and break keyboard access together.

That's why the two audits belong together: the same theme traits that wreck your Vitals tend to wreck your accessibility, and the same good traits fix both.

05Fixing the findings

An audit is only useful if it ends in fixes. Sort every finding into the layer that owns it — some are content-level and quick, some are theme-level and deeper — and work the quick wins first.

Content-level fixes (you control these directly)

• Add alt text to every meaningful image and empty alt to decorative ones — done in the media library and editor, no code needed.
• Fix heading order in your posts and pages so levels descend without skipping. Most of this is editing how you tagged your own content.
• Compress and resize images and serve WebP or AVIF. Oversized hero images are the most common LCP killer and a pure content fix.
• Remove unused plugins and embeds that load scripts you don't need — third-party widgets are a frequent INP and weight problem you can simply cut.

Theme-level fixes (the theme's structure or your child theme)

• Color contrast lives in the theme's design — adjust it in the Customizer or Site Editor, or override with a small rule in your child theme's CSS or the Additional CSS box.
• Restore focus states with a visible :focus outline in your child theme if the parent stripped it. Never remove focus styling for aesthetics.
• Set image dimensions so the browser reserves space and CLS drops — partly content, partly how the theme templates output images.
• Render-blocking and script weight are deeper theme issues. A caching and optimization plugin, or a host's built-in optimization, can defer scripts and inline critical CSS without editing the theme.

Make structural edits in a child theme, never the parent's files directly, so an update can't wipe them. And test fixes on a staging copy — managed hosts like Cloudways let you clone the live site, change things safely, and only push the working result live. Re-run the audit after each batch of fixes to confirm the number actually moved.

06Choosing a theme that's strong on both from the start

The cheapest fix is the one you never need. Picking a theme that's fast and accessible by default saves you the entire remediation cycle, because both qualities are extremely hard to retrofit onto a theme that lacks them.

Before you commit to any theme, audit its live demo exactly the way you'd audit your own site — it costs nothing and tells you almost everything.

• Run the demo through PageSpeed Insights. If the showcase demo, built by the author with ideal content, already struggles on mobile, your real site will be worse.
• Run the demo through axe or WAVE. A pile of contrast and ARIA errors on the demo means the theme's bones are bad, and you'll inherit them.
• Tab through the demo. No visible focus ring or an unreachable menu on the demo is a red flag you can spot in thirty seconds.
• Prefer lightweight, block-friendly themes. Themes built on clean semantic markup and the native block editor tend to score well on both audits without a fight.

A theme that passes its own demo audit gives you a high ceiling to build under. One that fails it is a project you'll be fighting for as long as you run the site.

07The audit checklist

Work top to bottom on your homepage and one inner page. It's a calm half-hour, not a research project.

• Run PageSpeed Insights on two page types and note LCP, INP, and CLS (prefer the field data where it exists).
• Run Lighthouse locally for the lab view and the accessibility score in the same pass.
• Run axe DevTools or WAVE for detailed accessibility findings and sort them by severity.
• Check color contrast on body text, links, and buttons against their backgrounds.
• Tab through the whole page — confirm every control is reachable and focus is always visible.
• Verify heading order descends logically with a single H1.
• Spot-check alt text on meaningful images and empty alt on decorative ones.
• Confirm images have set dimensions and the largest one is compressed and modern-format.
• Triage findings into content-level (fix now) and theme-level (child theme or host optimization).
• Re-run the audit after fixes to confirm each number actually improved.

08FAQ

Do I need paid tools to audit a theme?

No. PageSpeed Insights, Lighthouse, the free tier of axe DevTools, and WAVE cover the vast majority of what you need. Paid tools add convenience and bulk scanning, but you can run a thorough audit on free software alone.

What's a good Core Web Vitals score to aim for?

Aim to pass all three thresholds on mobile: LCP under 2.5s, INP under 200ms, CLS under 0.1. Passing matters more than a perfect Lighthouse number, because Google grades you on real-user field data, not the lab score.

Can automated accessibility tools find everything?

No — they catch roughly a third to half of issues, the rule-based ones. Things like sensible keyboard flow, meaningful alt text, and clear focus order need a short manual check. Use the tools to find the obvious failures, then test by hand for the rest.

My theme fails the audit badly — fix it or switch?

If the failures are content-level (alt text, image weight, heading order), fix them — that's normal upkeep. If the theme itself ships bloated markup, broken focus handling, and contrast problems baked into its design, switching to a stronger theme is usually less work than fighting the one you have.

Where do these fixes live — theme or content?

Alt text and heading order are content. Contrast, focus states, and render-blocking assets are theme-level — handle them in a child theme or via host-level optimization. Sorting each finding to the right layer is half the work of fixing it cleanly.

This is an honest how-to written from hands-on experience, not legal, accessibility-compliance, or financial advice — accessibility requirements vary by jurisdiction and situation, so treat this as a practical starting point and confirm anything binding for your own case.