Seven structural accessibility checks that take minutes to run and minutes to fix — and catch a surprising share of the issues that actually block real users.
Accessibility work can feel bottomless — WCAG 2.2 alone has dozens of success criteria across three conformance levels. But most of the issues that actually block real users come from a handful of basics that take minutes to check and minutes to fix. Here are seven worth running on every page before it ships.
1. Does the page declare a language?
A missing lang attribute on <html> means screen readers can’t reliably choose the right pronunciation rules. Fix: <html lang="en">. One attribute, done. (WCAG 3.1.1)
2. Does the page have a descriptive title?
Browser tabs, search results, and screen reader announcements all lean on <title>. “Home” or a blank title tells a user precisely nothing about where they are. (WCAG 2.4.2)
3. Is there exactly one H1?
Zero H1s leaves screen reader users without a page landmark to jump to. Multiple H1s muddy the outline and confuse anyone navigating by heading structure. One clear, descriptive H1 per page. (WCAG 1.3.1)
4. Does every image have alt text?
Every <img> needs an alt attribute — a real description for meaningful images, or alt="" for purely decorative ones. Missing alt isn’t a style choice; it’s a wall for anyone using a screen reader. (WCAG 1.1.1)
5. Are form controls labelled?
A placeholder is not a label — it disappears the moment someone starts typing, and most screen readers don’t reliably announce it anyway. Every input, select and textarea needs a real <label for>, an aria-label, or an aria-labelledby. (WCAG 1.3.1 / 3.3.2)
6. Do buttons have an accessible name?
An icon-only button with no text, aria-label, or aria-labelledby reads as “button” to a screen reader — no indication of what it does. If it’s an icon, give it an aria-label. (WCAG 4.1.2)
7. Are there page landmarks?
Elements like <main>, <nav>, <header> and <footer> (or their ARIA role equivalents) let screen reader users jump straight to the section they want instead of tabbing through the whole page linearly. A page built entirely out of generic <div>s has no landmarks at all. (WCAG 1.3.1)
Automating the first pass
None of these seven checks require a specialised tool — they’re all things you can grep for in your own markup. But running them by hand, on every page, before every deploy, doesn’t scale. AccessibilityForge runs exactly these seven checks (and a couple more) against a URL or pasted HTML, in your browser, and gives you a pass/warn/fail breakdown with the specific WCAG reference for each one.
It’s worth being honest about what automated checks can and can’t catch: they’re a fast, free first pass that catches the structural basics, not a replacement for testing with an actual screen reader or with real keyboard-only navigation. Treat a clean scan as a floor, not a ceiling.