Pro Every plan
A [scheduled check](/pro/page-checks#scheduled-checks) 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 ```bash wp lumtera-pro rendered status wp lumtera-pro rendered run --user=admin ``` `run` needs Chrome or Chromium. See [WP-CLI](/developers/wp-cli#wp-lumtera-pro-rendered) 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](https://playwright.dev/). Set `LUMTERA_URL`, `LUMTERA_USER` and `LUMTERA_PASS`. For example, in GitHub Actions: ```yaml 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 {#staging} 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](/manual-testing).