Index

An MX Audit, On Your Desk

When we deliver an audit, the document in your hand reads as one piece of work. Cover, contents, findings, recommendations. Nothing else competing for attention. The format is deliberate and consistent: same evidence behind every report, same scoring vocabulary, same clean delivery surface.

One scoring language

The Balanced Scorecard at the top of the report grades each dimension on a four-band scale: Excellent, Good, Could Be Better, Needs Improvement. Each band has a letter grade alongside it (A through D) so the scan is fast. The column comparing your scores to the curated benchmark dataset speaks the same language. The peer comparison reads "A (median)" or "D", never a raw number. One vocabulary across the row, one scan to find where your site stands against the cohort.

Cover, contents, report, each on its own page

An audit report opens with a cover page carrying your title, the MX Compatible badge, and the conformance line that names the standards the file meets. The contents page follows separately. The body follows on its own page after that. Each in its own space, each easy to print or to share as a tear-off.

The MX Compatible badge on the cover is more than a logo. It has a QR code that resolves to an interactive PDF inspector at /tools/pdf-inspector.html; a regulator or buyer who scans the cover can verify the file's evidence chain end-to-end without leaving the browser. A reader who wants the short version of what each badge signal means can read the explainer at /learn/mx-for-pdfs.html.

Reviewer notes belong to the reviewer

Every audit goes through automated checks before a human reviewer signs it off for delivery. The checks catch the kind of thing a tired writer might miss. A claim that the site has "no schema markup" when actually it has a small set. A sentence written in the present tense that should be past. A scope phrase that mixes per-page numbers with site-wide language.

Those checks generate working notes for the reviewer. The notes don't belong inside the report you receive. They live in a companion file that travels alongside it, named after the report itself (for example, dkd-de-de-report-findings.md next to dkd-de-de-report.pdf). Same prose, same evidence. The reviewer reads the companion before sign-off; you read the report. If you ever want to see the reviewer's working, the file is right there alongside the deliverable, and we're happy to walk you through it.

Why this shape matters

The audit is a written argument for what's working on your site and what isn't. The argument lands harder when the writing is clean. One scoring language is easier to read than two. A contents page on its own spread is simpler to navigate than one bleeding under the cover. A report that's yours, with reviewer working set aside, is easier to share with the colleague who needs to act on it.

The format doesn't change what the audit measures. Your scores, the schema you carry, the discovery files we found, the accessibility instances we counted: those are what they are. What it does is keep the deliverable focused on the conversation it's meant to have with you, and place everything else, including the reviewer's working and the regulator-facing evidence chain, in clearly named companion files alongside.