What a website accessibility audit covers
An audit measures your site against WCAG 2.2 Level AA and answers three questions about every barrier it finds: which task it stops, where it lives in the code, and what it will take to remove. You get a fixed price before testing starts, a ranked report your team can act on, the fixes made in the code rather than papered over, and a retest that shows they worked. A senior member of the Loco team leads every audit.
The proof is on a live site. After our 2026 audit and fixes on the Just Transition Commission website, axe-core reported no WCAG 2.1 A or AA violations on any template tested. We never install an overlay toolbar in place of a fix.
Audits and fixes are part of our web development work in Dublin.
Which accessibility rules apply to your website?
That depends on who you are and what the site does. A business that sells or takes bookings from consumers online is likely to be covered by the European Accessibility Act, which Ireland applies through S.I. No. 636/2023, while public sector bodies come under S.I. No. 358/2020. Micro-enterprises providing services are exempt from the Act. Our guide to web accessibility laws in Ireland sets out who is covered, who enforces the rules and what the penalties are.
The audit tests your site against the standard those rules point to, so the same evidence serves whichever regime applies to you.
Which standard the audit tests against
We test to WCAG 2.2 Level AA and map every finding to EN 301 549, Europe’s ICT accessibility standard, whose web clauses are built on WCAG. A site that meets WCAG 2.2 AA also meets 2.1, apart from one criterion that 2.2 removed, which we report separately when a tender asks for it. The criteria 2.2 added, such as target size and focus not obscured, are the ones that trip up customers on a phone, so every journey in scope is also tested on a phone-sized screen.
How the audit runs, from scope to retest
- Scope and price. We list your templates and the journeys that matter most, such as checkout, booking, sign-up and contact, and fix the price before testing starts.
- Automated pass. axe-core and Lighthouse run across every distinct template, catching missing labels, contrast failures and broken structure quickly.
- Manual pass. The checks no tool can make, listed below.
- Report. Every finding ranked by what it blocks, with its fix.
- Fixes. Template faults fixed once in code, and content faults handed to your editors with publishing rules.
- Retest and statement. The same tools and journeys run again, and the accessibility statement is drafted from the result.
The quote sets a date for each stage, so you know when the report lands and when the fixes ship.
The manual pass covers what tools cannot judge:
- Keyboard only. Every menu, form, modal and cookie banner operated without a mouse, with focus visible at each step.
- Screen readers. Where a journey needs it, checkout, booking, sign-up and contact are completed with a screen reader, priced in the plan.
- Zoom and reflow. Text enlarged to 200% and the layout checked on a narrow screen with no sideways scrolling.
- Content. Headings, link text, alt text, captions and error messages read in context.
A prioritised report you can act on
Each finding names the WCAG success criterion it fails, where it occurs, how severe it is for a user, and the fix. Findings are ranked by what blocks a task, so the defect that stops someone paying sits above a cosmetic one. The report separates template faults, fixed once in code, from content faults that editors fix page by page. It is yours to keep and to share with any developer.
Accessibility fixes built into the code
We fix template faults in the code: focus order, form labels, landmarks, contrast tokens, component states and media controls. On WordPress we ship the fixes as one plugin of our own that changes no core, theme or third-party file, so an update cannot overwrite them and they switch off in one step if needed. Content fixes come with short publishing rules for your editors, so new pages do not bring the same faults back.
For an online shop, checkout is the first journey we test and fix, and new stores from our ecommerce development in Dublin are designed to WCAG 2.1 AA from the start. When the audit shows the platform itself is the limit, a website redesign in Dublin fixes accessibility at the root while protecting the search visibility you have built.
Retesting, and the statement you publish
After the fixes ship, we retest with the same tools and journeys, so before and after are measured the same way. The accessibility statement is then drafted from the retest, listing any known limitations and claiming only the conformance level the results support.
A public body’s statement follows the EU model format, is updated regularly and gives people a way to report a problem. A business covered by the Accessibility Act publishes information on how its service meets the requirements, in an accessible format. We draft either one.
The Just Transition Commission, audited and fixed
We designed and built the Commission’s website, which launched in February 2026 with an Irish-language version, and came back to it in June and July 2026 to audit and fix accessibility on the live site, using automated testing, manual keyboard testing and template review.
What changed for the people using it:
- A keyboard user’s first Tab stop is now a skip link to the main content.
- The home page film has a labelled pause control that works from the keyboard.
- Links that open a new tab or a PDF say so to a screen reader.
- The amber used for text measures 4.98:1 on white, above the 4.5:1 AA bar.
Measured on 19 September 2026, axe-core reported no WCAG 2.1 A or AA violations on any template tested, and Lighthouse gave it an accessibility score of 100. The Commission’s own accessibility statement describes the site as partially compliant, with its PDFs out of scope. See the full Just Transition Commission case study.
Accessibility from the first design
On a new build, contrast, focus states and form errors are settled in the design system before a page is coded, which costs far less than fixing them after launch. Our web design in Dublin and UX design in Dublin projects work this way.
