WCAG Radar

What WCAG Radar shows

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 (200%)

  The Radar sets all text to 200%, the way a visitor with low vision would. Check whether text disappears, overlaps or falls off screen, and whether everything still works.

• 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 (200%)

  The Radar sets all text to 200%, the way a visitor with low vision would. Check whether text disappears, overlaps or falls off screen, and whether everything still works.

• 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.