Vouchlog – Accessibility Logbook, Scanner & Color Contrast Checker

Vouchlog keeps the record. Every scan, every fix you switch on or off, and every manual test you note is written to a dated, tamper-evident evidence log. When a customer, an auditor or somebody’s lawyer asks what you have done about accessibility, you print the report — with dates — instead of starting from nothing.

It is a website accessibility checker, a color contrast checker, a set of safe fixes, and an accessibility statement generator, built around that log.

How this is different

• Evidence, not promises. Each log entry stores the SHA-256 hash of the entry before it. The Evidence screen re-checks the whole chain every time you open it and names the first entry that no longer matches, so an edit after the fact shows up. Download the log to keep a copy outside the site.
• The report and the statement come from real data. The dated evidence report and the accessibility statement are generated from your actual scans and fixes, not from a form you fill in by hand.
• It checks the page your visitors get. The WCAG 2.2 scanner opens each page in your own browser — theme, header, footer, widgets and all — at desktop width AND at phone width, so it finds phone-only problems: pages that scroll sideways, tap targets under 24 × 24 pixels, pinch zoom switched off.
• Fixes change the HTML, not an overlay. The safe fixes change the HTML and CSS your server sends (the markup through WordPress core’s own HTML tag processor), so screen readers get them with JavaScript turned off. Every fix is off until you turn it on, and every switch is logged.
• Nothing leaves your site. No account, no API key, no external service.

The WCAG 2.2 accessibility scanner

Click “Scan my site now” and it checks your home page and your newest pages and posts (you choose how many), plus any addresses you add. It also checks the templates people complaining about accessibility usually test first: the search results page, a “page not found” page, one archive of each kind (a category, a tag…) and, with WooCommerce, the shop, the newest product, the cart, the checkout and the account page. For every problem it shows the WCAG success criterion, the exact element (a CSS selector and the HTML), and how to fix it. Checks include:

• images with no alt text (1.1.1) — an alt text checker for the pages visitors actually see
• links and buttons with no text a screen reader can announce (2.4.4, 4.1.2)
• form fields with no label (1.3.1)
• color contrast of the text on each page, with the nearest color that passes (1.4.3)
• pinch zoom disabled on phones (1.4.4)
• pages that scroll sideways at phone width (1.4.10)
• tap targets smaller than 24 × 24 pixels (2.5.8, new in WCAG 2.2)
• keyboard focus that can end up hidden under a sticky header or footer (2.4.11, new in WCAG 2.2)
• fields for a visitor’s own details with no valid autocomplete value, so browsers cannot fill them in (1.3.5)
• misspelled or invalid ARIA attributes, values and roles (4.1.2)
• heading levels that skip a step, and menus or regions a screen reader user cannot tell apart (1.3.1)
• parts of a page marked with a language code that is not one (3.1.2)
• missing page language, missing page title, no way to skip to the content, positive tabindex, untitled iframes, keyboard-reachable content hidden from screen readers, empty headings, moving text, and videos that may need captions

Some things only a person can judge, so the scan asks you to check them and note the result: anything moved by dragging needs a single-tap alternative (2.5.7, new in WCAG 2.2), and a log-in form must let people paste a password and use a password manager, with no puzzle or memory test (3.3.8, new in WCAG 2.2). These reminders are never listed as problems in your public statement.

Issues are tracked over time: when a later scan no longer finds one, it is marked resolved with the date. The Scan screen says how many days ago the last scan was, and if you switch it on in Settings, your site e-mails you a reminder when 30 days have passed since the last scan — at most once a month, through your site’s own mailer.

Check a post while you write it

In the block editor, the “Accessibility check” panel checks the post you are writing, from its preview, at desktop and phone width — missing alt text, low contrast, empty links and the rest — without leaving the editor. It lists the problems in the post itself and says how many more belong to the theme.

Color contrast checker

A contrast checker for any two colors: the ratio, pass or fail for WCAG AA and AAA at normal and large text sizes and for icons, and the nearest text color that passes — one click to use it. The scan also lists every low-contrast text it found on your pages, with its real colors, its ratio and a suggested color.

Safe fixes you switch on one by one

• let visitors pinch-zoom on phones
• declare the page language
• add a “Skip to content” link (only where the theme has none)
• always show keyboard focus
• announce links that open a new tab
• restore the natural keyboard order
• fill missing alt text from the alt text already saved in the media library — never invented
• give placeholder-only form fields an accessible name
• respect the visitor’s “reduce motion” setting
• underline links inside text

Dated evidence report and accessibility statement

The report shows what was tested and when, open issues by WCAG criterion, what was fixed and when, your manual test notes, and the verification of the log with its current hash. Print it, or save it as a PDF, from a laptop or a phone.

The accessibility statement page is created as a draft for you to review and publish. It lists known problems in plain language, what you have done, how the site was checked and how to report a problem — and it updates itself after each scan. It never claims full conformance, because automated checks cannot establish that.

Report an accessibility barrier

The statement page ends with a short form where a visitor can report something they could not use, and on which page. Each report is written to the evidence log with its date and listed in the dated report, and you get it by e-mail. The visitor’s IP address and browser are not recorded; an e-mail address given for a reply is sent to you and not kept in the log. Spam is stopped with a hidden field, a minimum fill-in time and an hourly limit — no CAPTCHA, no outside service. The toolbar links to the form, and [a11ylogbook_barrier_form] places it on any other page.

Visitor accessibility toolbar

A small button lets each visitor choose larger text, high contrast, underlined links, readable text spacing, paused animations, a keyboard focus highlight and a reading guide. Choices are kept in that visitor’s own browser; no cookies are set. Link to #a11y-preferences from any menu to open it. The toolbar changes how the site looks for one visitor; it does not make a site accessible on its own, and it says so.

Privacy

This plugin does not connect to any external service. It makes no outbound requests of any kind — no telemetry, no analytics, no fonts or scripts from a CDN. It stores no IP addresses and no browser details. The only visitor data it keeps is what a visitor chooses to write in the barrier report form; an e-mail address given there is e-mailed to you by your own site and not stored. Suggested wording for your privacy policy is added under Settings → Privacy.