WCAG Radar
A free button in your bookmarks bar, or an extension for Chrome and Firefox, that shows how any page is doing on accessibility. Headings, alt text, contrast, focus, ARIA and tab order, visible right on your own screen. The radar runs entirely in your browser: nothing is sent and nothing is stored.
How to get the radarHow to get the radar
Three ways, the same radar. The bookmarklet needs no install: you drag it to your bookmarks bar and it works in any browser. The extension goes into Chrome or Firefox once and then sits in your toolbar.
Bookmarklet
Works in any browser, with nothing to install. Also on a machine where you are not allowed to.
Drag this button to your bookmarks bar:
WCAG RadarCan't drag it? Create the bookmark manually
- Create a new bookmark with the star icon or with Ctrl + D, on a Mac Cmd + D.
- Give the bookmark a name, for example “WCAG Radar”.
- Paste the code below into the bookmark's URL field.
Extension for Chrome
Also for Edge, Brave and Vivaldi, since they run the same extensions. The radar gets its own button in your toolbar, so you do not need a visible bookmarks bar.
Install in ChromeTakes you to the Chrome Web Store.
Extension for Firefox
For Firefox on Windows, macOS and Linux. Here too the radar gets its own toolbar button, and it works on pages behind a login and on localhost.
Install in FirefoxTakes you to addons.mozilla.org.
The radar finds possible problems, you judge them
Use the radar to see where something might be going wrong. What lights up is a starting point, not a verdict. Exceptions and complicated components are yours to judge afterwards.
A small tap target can still pass. Alt text can be present and still not match the image. Whether something is really a problem depends on context, and no tool knows the context. No tool replaces human judgement.
What you can expect from the radar
Nothing is stored
The radar runs entirely in your own browser. Your page, your text and your images never leave your computer. We store no URLs and keep no record of what you check.
Safe in protected environments
You can use the radar behind a login, on a staging environment and on localhost. Nothing goes out, so you never have to expose a test environment to an external scanner.
100% European
The script is served from within the European Union. No US cloud service, no tracking, no cookies. The rest of this website runs on European infrastructure too.
Actively developed
We add checks regularly and sharpen existing ones. Your bookmark updates by itself, so you never need to drag it again. Within a day you are on the latest version.
The version you are running is shown at the bottom of the radar panel itself.
What WCAG Radar shows
At the top of the panel you switch between three tabs, tuned to what you do. Each tab holds the checks that belong to that role, so you never scroll past things you do not use.
When a check finds something, previous and next buttons appear in the panel. Use them to jump along every finding on the page instead of hunting for them yourself.
Editors tab
Page language
See whether the page language is set and which parts have their own language. The right language makes a screen reader pronounce words correctly.
Page title
Shows the title of the page. A clear, unique title helps visitors tell tabs and search results apart.
Styles off (reading order)
One click turns off all styling. You then see the bare order in which a screen reader reads the page. Does your story still flow?
Reading order (overview)
The page as a clickable list, the way assistive software walks through it: headings, landmarks, links, buttons and fields in document order. See whether the story makes sense, and click straight through to any element.
Show hidden elements
See which elements are hidden and why (display:none, visibility:hidden, the hidden attribute or aria-hidden). Handy for spotting content that is accidentally invisible, or read out twice.
Headings and structure
The Radar draws every heading with its level and warns when you skip a level. A logical heading structure helps everyone who scans the page or reads it with a screen reader.
Heading quality
Marks empty headings and headings with uninformative text such as “Go to” or “Read more”. Anyone navigating by headings should be able to tell from the heading what the section is about.
Sensory references
Marks references to position, colour or shape, such as “on the left”, “top right” or “the red button”, including inside alt text. Someone who cannot see the page gets nothing from those. Check that the instruction works without them.
List structure
Marks real lists, so you can see whether bullet points are actually marked up as lists rather than loose lines with dashes.
Tables
Marks tables without header cells or a caption. Header cells tell assistive software which row or column a cell belongs to. A caption gives the table a title.
Images and alt text
See which images have alt text, which have an empty alt attribute (alt="") and which have none. Visible svg images join in too: you see their title and desc. The Radar warns about redundant words like “image of” in alt text, but leaves the judgement to you: you decide whether an image carries meaning.
Images off
Images are dimmed. Check whether the page still makes sense without imagery and whether the text can carry the story on its own.
Clickable images
Links and buttons containing an image show their accessible name. That name should describe the destination or function, not what the image looks like. Clickable images without a name are marked as errors.
Show accessible name
Every interactive element (links, buttons, form fields) shows its accessible name: the name a screen reader announces. Elements without a name are marked as errors.
Link text
Marks vague links such as “read more” and links without text. Good link text tells you on its own where you will end up.
All links
All links on the page in a single list in the panel, the way a screen reader announces them: just the link text, without surrounding context. Empty and vague texts stand out. Click a row to jump to that link on the page.
Titles of embedded frames (iframes)
Marks embedded frames (iframes), such as a video or a map, without a title. A title tells a screen reader user what is inside the frame.
Autocomplete on personal data
Fields asking for personal data, such as name, email address or phone number, should have an autocomplete attribute. The browser can then fill them in, which helps people with motor or cognitive disabilities, among others. The Radar shows the value and warns when it is missing or unknown.
Accessible names of form fields
Marks input fields without an accessible name and fields that only have a placeholder. Note: visible text next to a field only counts as its accessible name when it is linked to the field via <label for>, aria-label or aria-labelledby. A placeholder disappears as soon as you type and never counts.
Error messages on form fields
The Radar looks for visible error messages (via role=alert, aria-live, or a class like error/invalid) and checks whether they are linked to an input via aria-describedby or aria-errormessage. Unlinked messages are an error: a screen reader will not announce them.
Text contrast
Automatically marks text on a solid background with insufficient contrast. For text on a photo or gradient you measure two colours yourself with the two pickers. You immediately see the contrast ratio and whether it meets the requirement for normal and large text.
Designer tab
Text contrast
Automatically marks text on a solid background with insufficient contrast. For text on a photo or gradient you measure two colours yourself with the two pickers. You immediately see the contrast ratio and whether it meets the requirement for normal and large text.
Contrast of borders and focus
Measures the contrast of input field borders and of the focus style (WCAG 1.4.11). The Radar briefly focuses each element and warns below 3:1, or when a visible focus style is missing entirely.
Links by colour alone
Finds links in running text that are distinguished from the text by colour alone (no underline) and shows the colour difference with the surrounding text. Underlining is the safest fix.
Grayscale (colour-blindness check)
One click turns the page grey. Check that information such as links or error messages is still recognisable without colour.
Dark mode
Force-applies the site's own dark mode (the prefers-color-scheme: dark styles), so you can check contrast and readability in dark mode. If the site has no dark mode styles, the Radar says so honestly.
Make focus visible
The Radar forces a clear focus outline. Tab through your design to see whether every interactive layer has visible focus.
Target size (24px)
Every clickable element shows its dimensions; elements smaller than 24 by 24 pixels get an orange mark. Note: a small target can still pass, for example a link within a sentence or a target with enough space around it. Use the marks as a starting point.
Gestures and mouse-only controls
Marks elements that can only be operated with a mouse or touch: script-clickable elements without keyboard focus, drag and drop without a clear alternative, and fake buttons with only a mouse cursor.
Resize text only (200%)
The Radar sets all text to 200% and keeps your viewport as it is, like the “Zoom text only” setting in Firefox. Check whether text disappears, overlaps or falls off screen, and whether everything still works.
Page zoom 200% (640 px)
Opens the page in a 640 pixel wide window. That is the same layout you get at 1280 pixels with 200% browser zoom, with the same media queries and the same collapsed components. Then zoom that window yourself to also see the text size.
Text spacing (1.4.12)
Applies the WCAG text spacing values. Check whether text disappears, overlaps or is cut off when a visitor increases the space between letters and lines.
Reflow (320 px)
Checks for horizontal scrolling at page level, marks the elements extending off screen, and opens the page in a 320 pixel wide window (WCAG 1.4.10).
Images off
Images are dimmed. Check whether your design still makes sense without imagery and whether the text can carry the story on its own.
Automatic motion
Finds motion that starts by itself and lasts longer than 5 seconds: CSS animations, autoplay videos and marquees. The Radar also watches script-driven motion, such as carousels and tickers, for 5 seconds.
Ruler and guides
A horizontal and vertical guide follow your mouse and show the x and y position in pixels, so you can verify alignment and distances precisely.
Developer tab
Element info on hover
Move your mouse over the page and see tag, id, class, role, accessible name, size, focusability and (where measurable) colour and contrast of each element. Also works in embedded frames from the same domain. Faster than opening the inspector for a quick check.
Show accessible name
Every interactive element (links, buttons, form fields) shows its accessible name: the name a screen reader announces. Elements without a name are marked as errors.
ARIA roles and attributes
Shows all roles and aria attributes and marks four kinds of errors: broken references to non-existent ids, unknown roles (typos), roles missing a required attribute (such as checkbox without aria-checked), and aria-hidden on focusable content.
Iframes (title)
Iframes without a title or aria-label stand out. A title is needed so a screen reader user knows what is inside the frame.
Autocomplete on personal data
Fields asking for personal data should have an autocomplete attribute with a valid value (WCAG 1.3.5). The Radar shows the value per field and warns about missing or unknown values.
Groups and visible labels
Fieldsets without a legend and groups (role=group) without a name are marked as errors. You also see which fields only have an aria-label and no visible label. That is sometimes fine, for example a magnifying glass icon on a search field, but usually visible text belongs there.
Accessible names of form fields
Marks input fields without an accessible name and fields that only have a placeholder. Visible text next to a field only counts when it is linked to the field via <label for>, aria-label or aria-labelledby.
Required fields
Shows which fields are marked as required for assistive software (required or aria-required) and warns about fields with an asterisk or 'required' in the label that lack this marking.
Error messages on form fields
The Radar looks for visible error messages (via role=alert, aria-live, or a class like error/invalid) and checks whether they are linked to an input via aria-describedby or aria-errormessage. Unlinked messages are an error: a screen reader will not announce them. Linked messages without aria-invalid="true" on the field get a warning.
Paste blocked
Marks elements that block pasting, copying or dragging via inline code (onpaste, oncopy, oncut, ondrop). Blocked pasting forces retyping and is a barrier, for example with passwords and email confirmations. Blocks added through scripts are invisible to the Radar; also test pasting yourself.
Make focus visible
The Radar forces a clear focus outline on every element. Tab through the page to see whether focus is always visible and moves logically.
Tab order
Every focusable element gets a number in the order you reach it with Tab. Positive tabindex values jump ahead of the rest and are marked as errors, because they disturb the logical keyboard order.
Target size (24px)
Every clickable element shows its dimensions; elements smaller than 24 by 24 pixels get an orange mark. A small target can still pass, for example a link within a sentence.
Gestures and mouse-only controls
Marks elements that can only be operated with a mouse or touch: script-clickable elements without keyboard focus, drag and drop without a clear alternative, and fake buttons with only a mouse cursor.
Resize text only (200%)
The Radar sets all text to 200% and keeps your viewport as it is, like the “Zoom text only” setting in Firefox. Check whether text disappears, overlaps or falls off screen, and whether everything still works.
Page zoom 200% (640 px)
Opens the page in a 640 pixel wide window. That is the same layout you get at 1280 pixels with 200% browser zoom, with the same media queries and the same collapsed components. Then zoom that window yourself to also see the text size.
Text spacing (1.4.12)
Applies the WCAG text spacing values: line height, letter and word spacing and paragraph spacing. You immediately see whether text disappears, overlaps or is cut off.
Reflow (320 px)
Checks for horizontal scrolling at page level, marks the elements extending off screen, and opens the page in a 320 pixel wide window (WCAG 1.4.10).
Text contrast
Automatically marks text on a solid background that drops below 4.5:1 (normal text) or 3:1 (large text). For text on an image or gradient you measure two colours yourself with the two pickers.
Contrast of borders and focus
Measures the contrast of input field borders and of the focus style (WCAG 1.4.11). The Radar briefly focuses each element and warns below 3:1, or when a visible focus style is missing entirely.
The checks you run every week, in one click
As an editor you work in the CMS, not in the code. Yet your work decides a large part of the accessibility: the alt text, the heading structure, the link text, the tables. That is exactly where things go wrong most often.
Our ambition for the Editors tab is straightforward: make the checks you should be doing anyway so easy that you actually do them. No source code to read, no developer to ask. You click the radar and see at once which image has no alt text, where a heading level is skipped and which link is called “read more”.
The radar does not judge for you. With alt text it shows you what is there; you decide whether it fits the image. That is precisely the part an automated scanner can never do for you.
Check contrast, focus and target size without a plugin
In your design tool everything looks fine. In the browser it comes down to the real colours, the real fonts and the real behaviour when someone zooms. You want to get at that, including on a page that is not finished yet.
Our ambition for the Designer tab is to bring the checks you normally spread across three tools into one place. Measure contrast with the two eyedroppers, drop the page to greyscale, force a visible focus ring, mark tap targets smaller than 24 pixels and push the text to 200% to see whether your layout holds.
There is nothing to install and your design does not have to be online. The radar works just as well on a staging environment or on localhost.
Faster than opening the inspector
You know what to look for. What costs time is the digging: which button exactly has no accessible name, does that aria-controls point at an id that exists, and in what order does focus actually travel?
Our ambition for the Developer tab is to answer those questions before you open the inspector. The radar numbers every focusable element in tab order and flags positive tabindex values as an error. It shows every role and aria attribute and reveals which references point at nothing. On hover you get the tag, id, class, role, accessible name and size of any element.
Useful while building, and useful when resolving an audit finding: you see straight away whether your fix had the effect you wanted.
Why a radar, not a scanner?
An automated scan finds at most a third of accessibility problems. It tells you what breaks a rule, but not whether your page makes sense to a visitor.
WCAG Radar turns that around. It shows what is really on your page: which headings you have, what your alt text says, where focus jumps to. You judge with your own eyes whether it holds up. That way you get to know your own site, which beats a list of error codes.
The radar does not replace a full audit. It helps you find and fix the most common problems yourself, so less is left over when an audit does happen.
Get clarity on your digital accessibility — without stress
Schedule a introductory meeting. No commitments — just valuable insight into your risks and opportunities.
Schedule an introduction
