Check a page for accessibility basics
Paste a page address. You get the list of WCAG failures that are visible in its HTML, with the elements that cause them and how to fix each one.
One page per check. The page is read once and nothing is stored.
Result
What this check cannot see
These need a browser and a person, so they are not in the result above. A page can pass every line here and still fail on them.
- Colour contrast between text and its real background.
- Whether every control works from the keyboard, and whether you can see which one has focus.
- Whether the page still reads at 200% zoom and on a 320 pixel wide screen.
- Captions and transcripts for video and audio.
- Whether an alt text describes its image, and whether a label describes its field.
- Anything the page adds with JavaScript after it loads.
Pages that pass without the checklist
BeeRanked publishes your blog, docs and guides as a section of your own site. Its page templates are tested against WCAG 2.1 level AA with automated scans, structure checks and a keyboard, so the items in this report are handled before you write a word. Each site also gets an accessibility statement, written and kept current for you.
- Text keeps a contrast of at least 4.5 to 1 on your brand colours, and custom styling that falls short is corrected when the page is built.
- Images, tables, forms, video players and code blocks come out with the markup a screen reader needs.
- The editor asks for a description on every image you add.
What this checker reads
It fetches one page, once, and reads the HTML the server sent. Eighteen checks run on that HTML in your browser. Each one has a yes or no answer in the markup: an image has an alt attribute or it does not, a form field has a label or it does not.
Every failed check lists how many elements fail and shows the first five, so you can find them in your source. Elements that are not rendered (hidden, inside a template, inside noscript) are left out, and decoration hidden from screen readers with aria-hidden is not asked for a name.
Which rules apply to a website
The reference is the same on both sides of the Atlantic: the Web Content Accessibility Guidelines 2.1 at level AA.
In the United States, the Department of Justice set it for public bodies under the ADA. Its fact sheet on the rule says: "The Web Content Accessibility Guidelines (WCAG) Version 2.1, Level AA is the technical standard for state and local governments' web content and mobile apps." The compliance dates are April 26, 2027 for governments serving 50,000 people or more and April 26, 2028 for smaller ones.
Businesses open to the public are covered by the ADA too, with no technical standard written into a regulation. The Department's web guidance says they "can currently choose how they will ensure that the programs, services, and goods they provide online are accessible to people with disabilities", and names WCAG among the standards that "provide helpful guidance".
In the European Union, Directive 2019/882 (the European Accessibility Act) applies to services provided to consumers after 28 June 2025, online shops among them. The directive does not name WCAG. The European standard used to show conformity, EN 301 549, takes its web requirements from WCAG 2.1 level AA. A microenterprise that provides services is exempt: the directive defines it as a business "which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million".
None of this is legal advice. Whether a rule applies to you depends on what you sell and to whom.
What a clean result means
A clean result covers the failures a program can see in HTML, and conformance to WCAG takes more than that. The W3C puts it this way in its evaluation overview: "no tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required to determine if a site is accessible."
Contrast, keyboard use, zoom and captions are the common failures this checker cannot see. To cover them, tab through the page with the mouse unplugged, zoom the browser to 200%, and run a browser extension that measures contrast on the rendered page.
How to work through the list
Start with what blocks a task. An unlabeled field in a checkout or a sign-up form stops a screen reader user from finishing. A menu button with no name hides the whole navigation.
Then fix what repeats. A missing alt on a logo or an unnamed icon link in the header fails on every page of the site, and one change in the template clears all of them.
Heading order and vague link text come last. They slow a reader down without stopping them.