Paste HTML or choose a local file to get a list of accessibility findings. Check two colors separately; keyboard behavior and rendered layout require an interactive review.
Runs locally in your browserThis source-level audit cannot inspect computed layout, keyboard behavior, dynamic states, or the real accessibility tree in a running application.
Use the findings as a review checklist, then test the rendered interface with a keyboard, browser accessibility tree, and people who use assistive technology.
Paste an HTML document or a fragment into the editor, or choose a local file, and press Audit locally. The report is built from the markup alone: duplicate ids, a missing or empty lang attribute, a missing main landmark, missing or repeated H1 headings, heading levels that skip a step, images without an alt attribute, form controls without a label or accessible name, buttons and links without a name, generic link text, data tables without header cells, empty headings and iframes without a title.
The panel on the right answers a different question: the contrast ratio between two colours, calculated the way WCAG defines it. Both panels run inside this browser tab, so the page works offline and no markup, file or colour is uploaded.
REVIEW items are defects that can be proved from the text: an id that appears twice, an image with no alt attribute, a form control without a label, aria-label, aria-labelledby or a usable title, a button or a link without an accessible name, an empty heading, an iframe without a title, and a role=button element that cannot receive keyboard focus. A wrapping label, the default name browsers give a submit or reset input, and the alt text of an image input all count as names, so valid markup is not reported.
INFO items depend on context: a document without a main landmark, a heading order that skips a level, a link whose whole text is a phrase such as "click here", and a table without th cells. They are worth a look but they are not always wrong. When no REVIEW item is left, the report says so; that is a statement about this checklist, not a claim that the page conforms to WCAG.
Each colour is converted to relative luminance with the sRGB formula WCAG uses (channel divided by 255, then / 12.92 or ((c + 0.055) / 1.055) ^ 2.4) and the ratio is (L1 + 0.05) / (L2 + 0.05), so black on white is 21:1 and a colour on itself is 1:1. The order of the two values does not matter.
The tiers shown are the WCAG thresholds: 4.5:1 for normal text (AA), 3:1 for large text and for user-interface components and graphics (AA), and 7:1 for normal text at AAA. Font size, weight and the rendered result are not part of the calculation, so the page reports the tier the ratio reaches rather than a verdict. Only 3- or 6-digit hex values are accepted; rgb(), HSL and colour names are answered with a hint instead of a ratio.
The audit reads markup and never renders the document. Contrast as rendered, focus order, keyboard traps, hover and focus states, live regions, ARIA state changes, captions and anything that only exists in a running application are outside its reach. Automated rules also cover only part of WCAG: keyboard and screen-reader testing, zoom and text spacing still have to be done by hand.
The colour panel checks one pair at a time and does not know the font size, so treat the tier as a prompt to inspect the real element. If a colour cannot be parsed, the contrast row in the summary returns to an em dash and the message under the fields names the expected format.