I check for missing alt text, unlabelled controls, broken heading structure and contrast failures — the accessibility problems that also happen to be the ones search engines and lawyers notice.
These are the situations this audit is built for. If more than one lands, the scan takes fifteen seconds.
A score you check once is trivia. These are the moments a diagnosis changes a decision.
One scan turns an unbounded worry into a finite, ranked list you can work through.
Produce current evidence of what has been checked and fixed, with dates, from your scan history.
Catch structural mistakes in a component before it is repeated across a thousand pages.
Accessibility issues arrive in the same ranked report as SEO and performance, so they compete for attention on equal terms instead of living in a separate tool.
All 28 of them, 0 rated critical. This list comes straight from my exam room — if a check is named here, I can find it on your site.
Without the dir attribute, RTL text (Arabic, Hebrew, Farsi, etc.) displays in the wrong direction, making content unreadable. Punctuation, numbers, and mixed-direction text become garbled. This affects all users viewing the page, not just assistive technology users.
When an image is the sole content of a link, the image's alt text serves as the link's accessible name. Without it, screen readers announce just 'link, image' with no context about the destination. This is both a WCAG 2.1 Level A violation and an SEO issue, as search engines receive no anchor text signal.
Low contrast text is difficult or impossible to read for users with low vision, color blindness, or in bright ambient lighting. WCAG 2.1 AA compliance requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Failing this criterion affects a large percentage of users.
WCAG 1.2.2 requires captions for all prerecorded audio content in synchronized media. Without captions, deaf and hard-of-hearing users cannot access spoken content in videos. Captions also benefit users in noisy environments, non-native speakers, and users who prefer reading.
WCAG 1.3.1 requires that page structure is programmatically determinable. Landmarks provide a way for screen reader users to quickly navigate to major page sections. Without landmarks, users must linearly traverse all content to find what they need, significantly increasing navigation time.
Without the lang attribute, screen readers may use the wrong pronunciation rules, making the content incomprehensible for visually impaired users. Search engines use the lang attribute as one signal for language targeting and serving the right version of your page to users in different regions. It is also a WCAG 2.1 Level A requirement (Success Criterion 3.1.1).
WCAG 2.4.7 requires a visible focus indicator for all interactive elements. :focus-visible provides focus styles only for keyboard users (not mouse clicks), offering the best balance between accessibility and visual design. Without it, keyboard users cannot tell which element is currently focused.
WCAG 2.3.3 requires that motion animation triggered by interaction can be disabled. Users with vestibular disorders, epilepsy, or migraine conditions can experience nausea, dizziness, or seizures from motion on screen. The prefers-reduced-motion media query allows respecting the user OS-level preference.
Buttons without accessible text are announced as just 'button' by screen readers, making them impossible to identify and use for visually impaired users. This is a WCAG 2.1 Level A violation (Success Criterion 4.1.2) and affects a significant portion of users who rely on assistive technology.
Screen readers rely on <th> elements to announce column and row headers as users navigate table cells. Without headers, screen readers read cells as isolated values with no context, making data tables completely unusable for visually impaired users. This is a WCAG 2.1 Level A requirement (Success Criterion 1.3.1).
Duplicate IDs cause label elements, aria-labelledby, aria-describedby, and fragment link targets to associate with the wrong element. Screen readers rely on ID-based relationships to provide context, so duplicate IDs make accessibility features unreliable. JavaScript targeting elements by ID also produces unpredictable results.
Positive tabindex values force elements to appear first in the tab order regardless of their position in the DOM. This creates a disjointed navigation experience where focus jumps unpredictably around the page, confusing keyboard users and screen reader users who expect a logical, document-order tab sequence.
Focus indicators are essential for keyboard navigation. Without them, keyboard users cannot tell which element is active, making the page essentially unnavigable without a mouse. This is a WCAG 2.1 Level AA violation (Success Criterion 2.4.7). Using outline:none or outline:0 without a replacement focus style is one of the most common and impactful accessibility issues.
Unlabelled form fields are unusable for screen reader users, who represent a significant portion of potential customers. This is a WCAG 2.1 Level A violation (Success Criterion 1.3.1 and 4.1.2) and a common cause of accessibility lawsuits. Beyond compliance, properly labelled forms improve usability for all users by making the clickable area larger (clicking a label focuses its associated input).
Screen reader users navigate pages by jumping between headings. Empty headings disrupt this navigation, as the screen reader announces a heading but provides no context about the section it introduces. This wastes the user's time and creates confusion about the page structure.
Icon-only buttons are extremely common in modern UIs (hamburger menus, close buttons, search icons), but without aria-labels, they are completely opaque to screen reader users. This is a WCAG 2.1 Level A violation and one of the most common accessibility issues on the web.
An invalid lang attribute is worse than a missing one because it actively misdirects screen readers and translation tools. Screen readers may apply completely wrong pronunciation rules, making content incomprehensible. Search engines may also misinterpret the page language, serving it to wrong-language audiences.
Links without accessible text are announced by screen readers as just 'link' with no context, making them unusable for visually impaired users. This is a WCAG 2.1 Level A violation (Success Criterion 2.4.4). It also means search engines get no anchor text signal from these links.
Autoplaying audio interferes with screen reader output, making the page essentially unusable for visually impaired users. It violates WCAG 2.1 Level A (Success Criterion 1.4.2). Browsers increasingly block autoplaying media with sound, and users generally find it intrusive, leading to immediate page abandonment.
WCAG 2.4.1 requires a mechanism to bypass repeated blocks of content. Without a skip link, keyboard users must tab through every navigation item on every page, which is tedious and frustrating. Screen reader users face similar challenges navigating past headers and menus.
Nested interactive elements produce unpredictable behavior across browsers and assistive technologies. Screen readers may announce confusing nested roles, and keyboard navigation becomes unreliable. The HTML specification explicitly forbids nesting interactive elements. Click events may not fire as expected, creating usability bugs.
WCAG 2.5.8 (Target Size) recommends a minimum target size of 44x44px. Small touch targets cause frequent mis-taps, especially for users with motor impairments, large fingers, or those using assistive devices. This directly impacts mobile usability and conversion rates.
WCAG 1.3.5 requires input purpose to be programmatically determined for inputs collecting user information. The autocomplete attribute helps browsers auto-fill forms, which is essential for users with cognitive disabilities, motor impairments, or anyone who benefits from reduced typing. It also improves form conversion rates.
Table captions help all users (including screen reader users) understand the purpose and context of the table before navigating its contents. Without a caption, users must examine the data to determine what the table is about. This is recommended under WCAG 2.1 (Success Criterion 1.3.1).
Positive tabindex values force elements to be focused before all other elements, regardless of their position in the DOM. This creates a confusing tab order where focus jumps around the page unpredictably. Screen reader users and keyboard-only users rely on logical tab order to navigate efficiently.
Without a title, screen reader users cannot determine the purpose of the iframe without navigating into it. The title attribute provides a concise description that helps users decide whether to explore the iframe content. This is a WCAG 2.1 Level A requirement (Success Criterion 2.4.1).
Without fieldset and legend, screen reader users hear individual radio buttons or checkboxes without understanding what group they belong to. For example, a user might hear 'Red, radio button' without knowing it is part of a 'Choose a color' group. This is a WCAG 2.1 Level A requirement.
Screen reader users rely on landmarks to jump between page regions efficiently. Without them, users must navigate through every element linearly, which is extremely time-consuming on content-rich pages. This is a WCAG 2.1 best practice (relates to Success Criterion 1.3.1 and 2.4.1). Proper semantic structure also helps search engines understand the purpose of different content sections.
No automated tool can. Automated checks catch a meaningful share of issues — missing alt text, labels, contrast, heading structure — but judgement-based criteria need a human. Treat this as the floor, not the ceiling.
The same structure that helps a screen reader helps a crawler: real headings, descriptive links, labelled controls, text alternatives. They are largely the same work.
One page is free and instant. Open an account and I'll take the whole site and keep every check-up on record, so you can prove what changed.