Pagina Axessibly
Lingua: en
Percorso interno nei file ai-model (.txt).
–––

[pages.accessibilityAudit.cta.h2]
Want a truly accessible website?

–––

[pages.accessibilityAudit.cta.portfolio]
See accessible projects we’ve built

–––

[pages.accessibilityAudit.cta.primary]
Get in touch

–––

[pages.accessibilityAudit.cta.subhead]
Get in touch if you want real accessibility , no half-measures — we build sites for everyone, with deep checks: manual review, keyboard, and screen readers, not a superficial scan alone.

–––

[pages.accessibilityAudit.hero.eyebrow]
After launch

–––

[pages.accessibilityAudit.hero.h1]
How we run an accessibility audit

–––

[pages.accessibilityAudit.hero.subhead]
A clear path to check whether a site is genuinely usable for everyone: automated checks, manual review, keyboard testing, screen readers, and more. Aligned with WCAG 2.1 Level AA and European practice, including EN 301 549 .

–––

[pages.accessibilityAudit.intro.h2]
Why one online tool isn’t enough

–––

[pages.accessibilityAudit.intro.p1]
Automated tests only catch part of the issues (often around 30–40%). They’re invaluable early on, but they don’t replace how many people actually use the site: keyboard-only, with a screen reader, or with different contrast needs.

–––

[pages.accessibilityAudit.intro.p2]
The audit we describe here is meant to be transparent and repeatable : what we check, in what order, and how we document it.

–––

[pages.accessibilityAudit.perimeter.b1]
Home and representative inner pages

–––

[pages.accessibilityAudit.perimeter.b2]
Every page with forms (contact, search, sign-up, checkout…)

–––

[pages.accessibilityAudit.perimeter.b3]
Pages with video, audio, or galleries

–––

[pages.accessibilityAudit.perimeter.b4]
Data tables, search results, error pages (e.g. 404)

–––

[pages.accessibilityAudit.perimeter.b5]
Shared pieces: header, footer, modals, dropdowns

–––

[pages.accessibilityAudit.perimeter.h2]
What we actually review

–––

[pages.accessibilityAudit.perimeter.p]
We don’t test random URLs: we cover every page pattern users really meet.

–––

[pages.accessibilityAudit.phase1.body]
We use built-in browser tools or specialised extensions to surface obvious issues (contrast, missing roles, unlabelled controls). It’s the fastest way to spot hotspots, but every finding is confirmed manually.

–––

[pages.accessibilityAudit.phase1.title]
1. Automated scan

–––

[pages.accessibilityAudit.phase2.body]
We check the page has a logical structure (headings in order, one clear main area, obvious navigation), images have meaningful alternative text, and forms have proper labels and understandable error messages—not colour alone.

–––

[pages.accessibilityAudit.phase2.title]
2. Manual structure and content review

–––

[pages.accessibilityAudit.phase3.body]
Everything clickable must be reachable with Tab and operable with keys like Enter or Space. Focus must stay visible, order must make sense, and you must never get stuck inside dialogs or menus.

–––

[pages.accessibilityAudit.phase3.title]
3. Keyboard-only navigation

–––

[pages.accessibilityAudit.phase4.body]
A screen reader speaks what’s on screen and shows whether links, buttons, and alerts still make sense out of context. It’s the check closest to many blind and low-vision users’ experience.

–––

[pages.accessibilityAudit.phase4.title]
4. Screen reader testing

–––

[pages.accessibilityAudit.phase5.body]
We check text and controls stay readable against their background and that zooming the page doesn’t break the layout in confusing ways.

–––

[pages.accessibilityAudit.phase5.title]
5. Contrast and layout

–––

[pages.accessibilityAudit.phase6.body]
Small screens, touch, and on-screen keyboards change behaviour: we check tap targets are large enough and nothing important is hidden under overlapping elements.

–––

[pages.accessibilityAudit.phase6.title]
6. Mobile devices

–––

[pages.accessibilityAudit.phase7.body]
If the site offers downloadable documents, those need review too (structure, headings, text that isn’t only an image)—accessibility doesn’t stop at the HTML page.

–––

[pages.accessibilityAudit.phase7.title]
7. PDFs and downloads

–––

[pages.accessibilityAudit.phases.h2]
Phases of the audit

–––

[pages.accessibilityAudit.phases.lead]
The steps in plain language: automated and manual checks to find issues first, fixes next, then publishable documentation for the site.

–––

[pages.accessibilityAudit.report.h2]
Report and accessibility statement

–––

[pages.accessibilityAudit.report.p]
When the build is done and fixes are in place, we prepare two documents for your site: a report summarising what we checked and the test outcomes, and the accessibility statement — the page some laws require you to publish to explain your commitment and level of conformance in plain terms.