Test live pages Free
Whole-page review
Check a page the way visitors see it — theme, header, menus, footer and page-builder output — with {page_checks} checks for contrast, target size, keyboard and widgets.
Updated for Lumtera 1.2.2 and Lumtera Pro 1.1.1.
Overview
Whole page is the second tab of the review panel you open from the Accessibility item in the admin bar. It checks everything your browser draws for that address: the theme's header and navigation, sidebars, the footer, cookie and chat widgets, and page-builder sections. It starts on its own once the browser is idle, and Check again runs it after you change something. Your server also runs the content checks on the page's markup, so a problem in a menu or footer is found together with the part it comes from.
Because it runs on the finished page, it can measure what content checks cannot. Text contrast is worked out from the colors the browser paints, including theme styles, global styles, page-builder CSS, gradients and text over images, and a low-contrast finding names the closest passing color in your theme palette where there is one. Text over a video, or over an image from another site that the browser will not let Lumtera read, is listed for you to check by eye. It also checks controls, icons and focus indicators that are hard to see, links told apart only by color, small crowded targets, and sticky bars that could hide keyboard focus.
It reads the page as a whole: the page title and language, blocked zoom, sideways scrolling, main landmarks and their names, the skip link, the heading outline, and items shown in a different order from the HTML. Tick Also test text spacing to apply wider spacing for a moment and find text that is cut off. The Keyboard tab adds the keyboard walk, which numbers every Tab stop and finds invisible focus, focus that jumps back up the page, focus that changes the page and possible traps, and widget tests that open and close menus, disclosures, dialogs, tabs and carousels from the keyboard, then put the page back.
Why does it matter?
Many barriers never appear in a post: a menu with pale links, a footer full of tiny icon links, a sticky header that covers the keyboard focus, a theme that blocks pinch-zoom. They repeat on every page, and no content check can see them, because they live in the theme, the page builder and the CSS.
What do you get?
- Real color contrast, measured from the colors your browser draws, including gradients and text over images, plus the contrast of controls, icons and focus indicators.
- The page title and language, landmarks, the skip link, the heading outline of the whole page, reflow, text spacing and reading order.
- WCAG 2.2 checks that need a rendered page: target size (2.5.8) and focus hidden behind sticky headers or cookie bars (2.4.11).
- A keyboard walk that numbers every Tab stop, and widget tests that operate menus, dialogs and tabs from the keyboard, then put the page back.
- Each finding says where it comes from — the post, a template part, a menu, a widget area or the theme — with a link to fix it there.
How does it work?
-
Open a page in review mode
Visit any post, page, product, archive or search page while logged in and choose Accessibility in the admin bar.
-
Check the page and the keyboard
The Whole page tab starts once the browser is idle. In the Keyboard tab, choose Check keyboard access or Test menus and pop-ups.
-
Fix it at the source
Each finding names the part it comes from and links to where that part is edited. Press Check again after a change.
Who is it for?
-
Site owners on a ready-made theme
Find out whether the theme has a skip link, visible focus and readable menu colors before blaming the content, and see which part to change in the Customizer or Site Editor.
-
Designers and page builders
Check the contrast of buttons, hero text and footer links in the real design, including colors set in Elementor, Kadence or Spectra global styles.
-
Stores with sticky headers and cookie bars
See when a fixed header, cookie notice or chat button could cover the keyboard focus, a WCAG 2.2 requirement that content checks cannot see.
Good to know
How it behaves, what it needs, and where its limits are.
- One page, when you open it
- It checks the page in front of you, in your browser. Results are saved to your reports only when you tick Save results to reports; saved results appear in the Overview, the editor sidebar and the coverage meter. Lumtera Pro's page checks cover many pages on a schedule.
- As you see it, logged in
- The page is checked the way it renders for you, at your window size, with the admin bar ignored. Content shown only to logged-out visitors, such as a cookie banner, can differ.
- Dismiss once, for every page
- A finding from a shared part, such as the header, counts as one issue on many pages. Dismiss it with an optional reason on every page it appears on, or on this page only. A dismissal never hides a more serious finding.
- The keyboard tests are scripted
- They run only when you ask, because they move focus. The walk stops after 300 Tab stops or when its time runs out, and Escape stops it. Scripted key presses are not a real keyboard, so press Tab through the page yourself to confirm.
- Reflow needs a narrow window
- Sideways scrolling is judged at your current window width. To check reflow properly, make the window 320 pixels wide or zoom to 400%, then press Check again.
Checks you will see here
-
WCAG 1.4.3 · AAError
Text has low contrast on the live page
-
WCAG 2.4.2 · AError
Page title is missing or generic
-
WCAG 3.1.1 · AError
Page language is missing or not valid
-
WCAG 2.4.1 · ANeeds review
No working way to skip to the main content
-
WCAG 1.3.1 · ANeeds review
Page landmarks are missing or share a name
-
WCAG 1.3.1 · ANeeds review
Page headings are missing an H1 or skip levels
-
WCAG 2.4.7 · AANeeds review
No visible keyboard focus
-
WCAG 2.4.11 · AANeeds review
Sticky bar hides the keyboard focus
-
WCAG 2.4.7 · AAError
Keyboard focus goes somewhere invisible
-
WCAG 2.4.3 · ANeeds review
Tab order jumps back up the page
-
WCAG 3.2.1 · AError
Focusing an element changes the page
-
WCAG 1.4.13 · AANeeds review
Pop-up content on focus does not close with Escape
-
WCAG 2.1.2 · ANeeds review
Possible keyboard trap
-
WCAG 1.4.11 · AANeeds review
Controls or icons are hard to see
-
WCAG 1.4.11 · AANeeds review
Focus indicator has low contrast
-
WCAG 1.4.1 · AError
Links look the same as the text around them
-
WCAG 2.5.8 · AANeeds review
Small, crowded click target
-
WCAG 4.1.2 · AError
Menu or disclosure toggle does not work as announced
-
WCAG 2.1.1 · ANeeds review
Submenu opens on hover only
-
WCAG 2.4.3 · ANeeds review
Dialog or pop-up is hard to use with a keyboard
-
WCAG 4.1.2 · AError
Tabs do not work as tabs
-
WCAG 2.2.2 · ANeeds review
Carousel to test with the keyboard
-
WCAG 1.4.10 · AANeeds review
Page scrolls sideways at this width
-
WCAG 1.4.4 · AAError
Zooming is disabled
-
WCAG 1.4.12 · AANeeds review
Text is cut off or overlaps when text spacing is increased
-
WCAG 1.3.2 · ANeeds review
Items are shown in a different order from the page's HTML
Questions
Something else on your mind? Contact support
Is this the same as Lumtera Pro's page checks?
No. Whole-page review checks the one page you are looking at, when you open it, and you can save its results to your reports. Lumtera Pro checks many pages on a schedule, at desktop and phone width, as a logged-out visitor, and keeps their history.
Does it load anything for visitors?
No. The checks run only in the browser of a logged-in user who has opened review mode: someone who can edit the post, or, on archives and other listing pages, see reports.
How many whole-page checks are there?
33, each listed in the check library with its WCAG criterion. They run in the Whole page and Keyboard tabs, alongside the 69 content checks the This post tab runs.
Why is a finding marked Needs review instead of Error?
Some results depend on what a person sees. Text over a photo, a small target that has a larger twin elsewhere on the page, or a sticky bar that only covers focus at some scroll positions all need a quick look before you change anything.
Does it test with a keyboard or a screen reader?
With a keyboard, yes: the keyboard walk and the widget tests operate the page with scripted key presses. The Screen reader tab is a preview of what screen readers may list and announce, not a real screen reader. Confirm with your own keyboard, and with NVDA or VoiceOver.
More in “Test live pages”
-
Free
Keyboard walk and widget tests
Review mode's Keyboard tab numbers every Tab stop on the page, flags focus you cannot see, and opens menus, dialogs and tabs from the keyboard.
-
Free
Screen reader preview
See roughly what a screen reader lists on a page: headings, landmarks, links and form fields, plus the whole page in reading order.
-
Free
Contrast everywhere, with a palette fixer
Contrast measured on gradients, images, text shadows, controls and focus rings, plus a block editor fix that suggests the nearest passing color from your palette.
Start with the free plugin today
All 69 content checks and 33 whole-page checks, fixes you approve with undo, and the site report — free, with no account and no page limits.