Rendered checks

Pro Every plan

A scheduled check runs on your server, which has no browser. It reads each page's markup, so it can't measure painted contrast, focus, spacing or layout. Those need a real browser. Lumtera Pro never sends your pages to a cloud to do this: the measures run in a browser you control, and the results go only to your own site.

See what each page has had

The Rendered checks card is on Lumtera → Checks → Page checks. It counts Pages in scheduled runs, Had a rendered check, With the keyboard walk and Server check only, and shows the Last rendered check. Every page in the results says what it has had:

Label	Meaning
Server check only	Markup only. Painted contrast, focus and layout not measured yet.
Rendered check, without the keyboard walk	A background pass measured contrast, size, spacing and order.
Rendered check	A full pass, with the keyboard walk.

Check pages again after (days) sets when a checked page is due again.

If scheduled checks are off, no pages are waiting, and the card says so.

Four ways to run them

In the background of an admin session

Turn on Finish them in the background of my admin sessions. While an administrator uses the dashboard, lists or Lumtera screens, pages due load one at a time out of sight. It never runs in an editor, pauses when the tab is hidden and never moves focus, so the keyboard walk isn't part of it.

Whoever pauses it for their own sessions sees You paused this in your own sessions until…, with Resume now.

With a button

Run rendered checks now on the card runs the full pass, with the keyboard walk, while you wait.

With WP-CLI and Chrome on the server

wp lumtera-pro rendered status
wp lumtera-pro rendered run --user=admin

run needs Chrome or Chromium. See WP-CLI for the options. Its one-time pass works once, for two minutes, and doesn't appear in the process list or server logs. If the browser can't reach the site, it stops within a minute with a plain error.

Some shared hosts can't run a browser at all. On a server without a display, try chrome-headless-shell. If neither works, use a scheduled job.

With a scheduled job elsewhere

The plugin's tools/rendered-check.mjs runs the same pass from another machine, using Playwright. Set LUMTERA_URL, LUMTERA_USER and LUMTERA_PASS. For example, in GitHub Actions:

name: Rendered accessibility checks
on:
  schedule:
    - cron: '0 3 * * 1'
  workflow_dispatch:
jobs:
  rendered:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: |
          mkdir job && cd job
          npm init -y && npm i playwright
          npx playwright install --with-deps chromium
          curl -fsSL "${{ vars.SCRIPT_URL }}" -o rendered-check.mjs
          node rendered-check.mjs
        env:
          LUMTERA_URL: ${{ vars.LUMTERA_URL }}
          LUMTERA_USER: ${{ secrets.LUMTERA_USER }}
          LUMTERA_PASS: ${{ secrets.LUMTERA_PASS }}

SCRIPT_URL is where you keep your copy of the script. Use an account made for this job, and rotate its password like any other credential. The runner sees pages as that administrator does.

A staging site behind a password

Open Is this a staging site behind a password? on the card and enter the User name and Password. Scheduled checks then use them to reach your pages. The password is stored encrypted, sent only to this site and never shown again. It's tried when you save, so a wrong one tells you straight away. Forget it removes it.

Limits

• All of these run logged in, unlike scheduled checks, so banners and content for logged-out visitors can differ.
• wp lumtera-pro rendered run has been tested with Chromium and chrome-headless-shell on macOS. It hasn't been tested on Linux or on every host.
• A rendered check measures what automation can. It doesn't replace testing by a person.