A checkout button can look perfect while its accessible name says nothing useful. A form can contain every required field yet leave a screen-reader user guessing what to enter. Accessibility work starts with whether someone can complete a task, not with the color of a score.
Use Sitelemetry to identify likely barriers in the delivered HTML of a page you own or are authorized to assess. Keep the report beside a browser: the two provide different evidence, and neither a green result nor a short issue list establishes full WCAG conformance.
What this audit covers
What can be measured
- Delivered HTML for the requested page, with the final URL and assessment status.
- Markup signals for images, page language, titles, labels, headings, landmarks and interactive names.
- Selected inline foreground/background color pairs and structural review signals.
What it cannot prove
- No browser rendering, computed accessibility tree or complete accessible-name calculation.
- No automated proof of keyboard navigation, visible focus, responsive reflow or dynamic behavior.
- One assessed page does not establish site-wide accessibility or WCAG certification.
Accessibility audits are included in Starter, Professional and Enterprise. Report formats and monitoring depend on the selected plan; the Free security scan does not include this audit.
Start with a task that matters
Choose one journey before scanning: request a quote, create an account, find a product specification or send a support message. Record the exact URL, page language, expected outcome and whether the page is public or requires authentication. A public HTML audit does not automatically enter a signed-in workflow.
Start with a representative page, then inspect other templates separately. A shared navigation defect may affect many pages, but one successful homepage result says little about checkout errors or a modal loaded later. Prioritize barriers that prevent completion of an important task over cosmetic consistency. A finding's severity is a useful starting point; actual impact depends on the component and its use.
Understand what was measured
The current Sitelemetry accessibility engine fetches one requested page and examines static HTML. It looks for missing image alt attributes, page language and title, likely unlabeled form controls, unnamed links or buttons, heading issues, landmarks, positive tabindex, iframe titles and table-header signals. Some checks are heuristics rather than a full browser interpretation.
It can flag clear problems in selected inline color pairs. It cannot evaluate all CSS, inherited colors, overlays or interactive states, so a clean inline check is not a contrast pass. A failed fetch, challenge page, truncated response or non-HTML resource must be read as unavailable or not applicable, not as an accessible page. W3C explains why evaluation tools require human judgment.
Read the evidence before assigning work
For each finding, capture the affected URL, the observed element or example, the behavior to verify and the task it could obstruct. “Three images lack an alt attribute” is more actionable than “improve accessibility.” Yet an existing attribute does not prove that its words communicate the image's purpose.
Review likely false positives too. A static label check may miss a valid wrapping label or accept an ARIA reference whose target is unsuitable. Inspect the rendered accessibility tree and test the actual control. Treat heading-level warnings as requests to examine the document's organization, not as an automatic conclusion about every WCAG requirement. Group repeated defects by the shared component that produces them.
| Observation | Contextual priority | Evidence to confirm | Next action |
|---|---|---|---|
| A required field has no usable name | High when it blocks a key task | Inspect its computed name and complete the form | Repair the label relationship, then repeat the journey |
| An image lacks an alternative | Depends on its purpose | Decide whether it informs, acts or decorates | Write a suitable alternative or use empty alt for decoration |
| Heading order warning | Review in context | Read the document outline and content | Correct the shared structure when it obscures meaning |
Repair the source component
Prefer native, visible relationships. Connect a form label to the control using matching for and id values; a placeholder disappears during entry and is not a dependable replacement. W3C's form-label guidance explains explicit and implicit associations. Give icon-only buttons names that describe their action, such as opening a menu, rather than describing the icon.
For images, decide whether the image informs, performs an action or only decorates. Write alternatives that preserve its purpose; use alt="" for genuinely decorative images. Do not apply empty alternatives to every failing image to raise a score. Follow the W3C images tutorial for context. Repair the component or content model so the next page does not reproduce the same defect.
Complete the browser review
- Use only the keyboard to reach controls, activate them and move back. Check that focus remains visible and that dialogs release focus appropriately.
- Use a screen reader to inspect headings, names, instructions and error messages. Confirm that the completed task is understandable, not merely that text is spoken.
- Check contrast in normal, hover, focus, disabled and error states with the rendered colors. Include text over images and overlays.
- Zoom and use a narrow viewport. Check whether content, controls or instructions disappear or require impractical scrolling.
These are follow-up activities, not capabilities claimed for the static scan. Use W3C's first-review checks to organize them, and involve people with relevant access needs when the journey warrants it.
Retest and describe the remaining scope
After publishing a fix, rerun the same URL and compare the specific evidence. Confirm that the intended component changed and that no new naming or structure problem appeared. Repeat the affected journey manually; removing a warning while breaking keyboard activation is not a successful repair.
Record the date, page, changes, static result and manual results together. For an agency handover, say which templates and interactions were reviewed and which remain outside scope. A score summarizes this scan's findings; it is not a percentage of users supported or proof of legal compliance. Keep unresolved manual checks visible, and add the component to future release checks so the repair lasts.
Common questions
Does a high score mean the website meets WCAG?
No. It summarizes a limited static assessment of one page. Conformance requires a defined scope and broader evaluation, including behavior the scanner does not render.
Should every image have descriptive alt text?
Every meaningful image needs an appropriate alternative. Purely decorative images normally use an empty alt attribute; the correct choice depends on context and purpose.
Can the audit test a dialog that appears after a click?
It can inspect relevant markup already delivered in the response, but it does not open the dialog or verify focus, keyboard interaction or announcements.
Sources & further reading
- W3C: selecting accessibility evaluation toolswww.w3.org
- W3C: labeling form controlswww.w3.org
- W3C: image alternatives tutorialwww.w3.org
- W3C: first accessibility reviewwww.w3.org
Written by the Sitelemetry team, checked against the product’s audit scope and linked primary sources. Examples are illustrative unless an observed case is explicitly identified.
