Web accessibility services make a website usable by people who navigate with a keyboard, a screen reader, magnification, voice input or other assistive technology. The target we build and remediate to is WCAG 2.2 Level AA, the current W3C recommendation. Where a service is offered to consumers in the European Union, the European Accessibility Act has applied since 28 June 2025, and a structured audit is how you learn whether the site you already have meets that bar.
Contents
At CodeWiz accessibility is part of building the site, not a PDF at the end. We audit templates against WCAG 2.2, fix them in the theme or front-end code, test with a keyboard and a screen reader, and write a statement that matches the site. The work covers WordPress, WooCommerce, Laravel, custom JavaScript front ends, online stores and the documents those sites hand to customers.
It is for shops and services sold into the EU, teams replacing a theme, products never tested with assistive technology, and anyone told a plugin would “make the site compliant” on its own. A fast site helps. Ours scores 100/100/100/100 on PageSpeed Insights, and that score is not an accessibility result.
Web Accessibility Audits Against WCAG 2.2
A web accessibility audit checks representative pages and components against WCAG 2.2 at Level AA, unless you have a written reason to aim higher. Tools find missing labels, empty buttons and some contrast failures. They do not know whether a menu works without a mouse, whether an error is announced, or whether the reading order matches the screen.
- A page sample that covers each template: home, a content page, listing, detail, search, forms, account, checkout and any modal or menu that those pages share.
- Automated passes with axe and Lighthouse, used to catch the mechanical issues and then triaged so false positives do not drown the report.
- Manual checks for keyboard use, visible focus, names of controls, headings, error handling and the new WCAG 2.2 criteria that scanners still miss.
- Zoom and reflow at 200 percent and at 400 percent, including whether content requires two-dimensional scrolling at a 320 CSS pixel width.
- Documents and media that are part of the service: PDF invoices, embedded video, and captions or transcripts where audio carries the information.
Each finding names the success criterion, the pages affected, who is blocked and the change in code or content. Severity follows user impact, not how often a scanner repeated one template bug.
WCAG 2.2 Remediation in Code and Templates
WCAG 2.2 became a W3C Recommendation on 5 October 2023. Level AA includes WCAG 2.1 AA and adds criteria that show up on real sites: focus hidden under a sticky bar, targets that are too small, drag-only actions, help that jumps around, forms that ask for the same data twice, and logins that fight password managers. 4.1.1 Parsing is obsolete and removed, so we do not chase it.
| WCAG 2.2 criterion (AA) | What it asks for | Where it usually fails |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | A focused item is not entirely hidden by other content the site created | Sticky headers, cookie banners and chat widgets covering the focus |
| 2.5.7 Dragging Movements | Anything you can do by dragging also has a single-pointer alternative | Kanban boards, sliders, maps, drag-and-drop upload |
| 2.5.8 Target Size (Minimum) | Pointer targets are at least 24 by 24 CSS pixels, or have enough spacing, with a few exceptions | Icon-only buttons, tight footer links, pagination |
| 3.2.6 Consistent Help | Help that repeats across pages stays in the same relative order | A contact or chat link that moves between templates |
| 3.3.7 Redundant Entry | Information already entered in the same process is not demanded again | Checkout that asks for the address a second time |
| 3.3.8 Accessible Authentication (Minimum) | Logging in does not depend on a memory or puzzle test unless there is another way, or a mechanism that helps | Paste and password managers blocked; a CAPTCHA with no alternative |
The full wording, including the exceptions, is in the WCAG 2.2 specification. Remediation then happens in the place that caused the failure:
- One fix in a shared template or component, so many URLs change together.
- Visible labels tied to inputs with
forandid, not placeholders used as labels. - Errors and status messages exposed so assistive technology can announce them.
- Contrast checked in the theme, including text on images and on the brand colour.
Keyboard Navigation and ARIA
Keyboard access sits under screen readers, switch devices and many power users. If a control cannot be reached and operated with Tab, Shift+Tab, Enter, Space and the arrow keys a widget expects, it is not done. ARIA does not repair a div that only has a click handler. We start with native elements and add ARIA only when no native element fits.
<a href="#main">Skip to content</a>
<main id="main"></main>
<button type="button" aria-expanded="false" aria-controls="site-nav">
Menu
</button>- A skip link visible on focus, moving focus to the main content.
- Menus and dialogs that hold focus only while open, then return it to the control that opened them.
- A visible focus indicator that meets contrast and is not removed by a CSS reset. “Focus not obscured” assumes that indicator exists.
- Widgets named correctly:
aria-expandedthat toggles, and norole="button"on a link that already navigates.
We test the path a person takes: skip link, menu, form and errors.
Screen Reader Testing on the Pages People Use
Screen reader testing checks that the name, role and value of each control match what a person hears, in an order that matches the screen. We use NVDA with Firefox or Chrome on Windows, and VoiceOver with Safari on macOS or iOS. TalkBack is added when the audience is mainly on Android. A browser extension is not a substitute.
- Headings form an outline, and they are not used only to make text big.
- Images that carry information have a text alternative; decorative images are hidden from the accessibility tree.
- Form fields have a persistent name, required state and an error that is announced when submission fails.
- Dynamic updates – a cart count, a search suggestion, a toast – are announced when they matter and silent when they would only interrupt.
The notes in the report quote what was heard, next to the markup that produced it, so a developer can see why “button, button” or “unlabeled graphic” showed up.
Accessibility Statements and an Honest Compliance Picture
An accessibility statement says how accessible the site is, how to get help, and which gaps remain. It is a public description, not a certificate. We draft it from the audit, in the languages the site already uses, and we date it so it cannot claim a state the site has left.
- The standard the site aims at (WCAG 2.2 Level AA) and the method used to evaluate it.
- Known limitations, with a short plan or a contact route, instead of a promise that every page is perfect.
- A way to reach a person: email, and the phone or Viber contact you already publish, in a form a screen reader can use.
- A review date, and an owner inside your team so the statement is updated when a template changes.
We are not a law firm and we do not certify legal compliance. Where a regulation asks for a statement, we align the page with what it expects, and we keep technical findings separate from legal advice.
The European Accessibility Act since 28 June 2025
The European Accessibility Act is Directive (EU) 2019/882. From 28 June 2025 a defined list of products and services offered to consumers in the EU must meet its accessibility requirements. On the web that means the online interfaces of those services – e-commerce, consumer banking, electronic communications and the others named in the directive – not every brochure site. The text is on EUR-Lex.
A presumption of conformity comes from harmonised standards cited in the Official Journal. For ICT that standard is EN 301 549, and its web clauses track WCAG. The directive text does not say “WCAG 2.2”. We remediate to WCAG 2.2 Level AA because it includes WCAG 2.1 Level AA and the newer criteria above. When you need the formal presumption, the report maps findings to the EN 301 549 version listed in the Official Journal at the time.
- Who is in scope. Operators who place the listed products on the EU market, or who provide the listed services to consumers in the Union. Croatia is in the EU. A firm in Bosnia and Herzegovina, Serbia or Montenegro that sells a covered service to EU consumers, such as a shop that delivers into the Union, should check whether it is in scope.
- Who is exempt. Microenterprises that provide services: fewer than 10 employees, and annual turnover or balance-sheet total not over EUR 2 million. The exemption covers services, not products, and it is not legal advice about your company.
- Transitions. Service contracts concluded before 28 June 2025 may continue unchanged until they expire, but not beyond 28 June 2030. Products a provider was already using have a transition too. New websites and new checkouts do not inherit it.
- A different law for the public sector. Directive (EU) 2016/2102 already covers public-sector websites and mobile apps in the EU. The European Accessibility Act does not replace it. Mixing the two up leads to the wrong deadline and the wrong statement.
Readable Content, Contrast and Forms
Many failures live in content and CSS, not in a missing ARIA attribute. We fix reading order, link text that says where it goes, instructions that do not rely on colour alone, and forms that work without a mouse.
- Body text that resizes, line length that stays readable, and spacing that is not the only thing separating a clickable control from its neighbour.
- Contrast of text, icons that convey state, and focus rings, checked in the real theme rather than in a design file.
- Captions for video that carries speech, and a transcript where the audio is the content.
- Error text next to the field, associated programmatically, that says how to correct the value.
Speed is part of the same experience: timeouts and stalled pages cut off anyone who needs longer to read or type. codewizdev.com scores 100/100/100/100 on PageSpeed Insights. How that result is produced, and where Varnish fits a dynamic site, is already explained in how we reach 100/100 page vitals and in the Varnish cache write-up. Clear headings also help search engines; for measurement, see SEO analytics and competitive intelligence.
Common Web Accessibility Mistakes
- An overlay or “accessibility widget” sold as compliance. These widgets often clash with the assistive technology people already use, and they do not fix the template.
- A placeholder used as the only label, so the name disappears as soon as someone types.
- Menus and dialogs that open only on hover or click, with no keyboard path and no focus move.
- Icon buttons with no accessible name, so a screen reader says “button” and nothing else.
- A CSS reset that sets
outline: noneand never draws a focus style back. - Brand colours that fail contrast for small text, then get justified as “on brand”.
- PDF invoices or manuals that are photographs of text, with no tags and no text alternative.
How We Work
- Discovery: we learn who uses the site, which flows matter (browse, account, checkout, documents) and whether the European Accessibility Act or a public-sector rule is the reason for the project.
- Audit: we sample templates, run and triage automated checks, and test with a keyboard and screen readers.
- Plan: you get findings grouped by template, with the criterion, the impact and the effort, so shared components are fixed once.
- Remediate: we change the theme, components, forms and content, on staging first.
- Retest: we repeat the keyboard and screen reader passes on the flows that failed, and we re-run the automated checks to catch regressions.
- Statement and support: we publish an accessibility statement that matches the retest, and we can keep an eye on new templates after launch.
Why CodeWiz
- Fixes in the codebase. We edit WordPress themes, Laravel views and front-end components ourselves, so the audit does not end as a list nobody implements.
- WCAG 2.2, stated carefully. We aim at Level AA, explain what the European Accessibility Act does and does not require, and we do not sell a certificate we cannot issue.
- The rest of the stack. Hosting, performance and markup stay with one team. Our own site scores 100/100/100/100 on PageSpeed Insights, which removes one barrier and still leaves the accessibility work to be done properly.
- No overlay product. Open-source checks and real assistive technology, rather than a widget layered on top of an inaccessible template.
- Fair pricing, from Banja Luka. Premium development without premium prices, working remotely with clients locally and internationally. More about CodeWiz.
Frequently Asked Questions
Does the European Accessibility Act apply to my company?
It applies to specific products and services offered to consumers in the EU, including e-commerce, not to every website. Service microenterprises under the employee and turnover thresholds are exempt, and contracts signed before 28 June 2025 may continue until they expire, but not past 28 June 2030. Scope is a legal question; we implement the technical side.
Is WCAG 2.2 Level AA the same as complying with the Act?
No. WCAG 2.2 Level AA is the technical target we build to, and it is how EN 301 549’s web requirements are generally met. The Act has its own scope, exemptions and a presumption of conformity through the harmonised standard in the Official Journal. Meeting WCAG 2.2 AA is the engineering work, not a legal opinion.
How much does a web accessibility audit cost?
It follows the number of templates, widgets such as checkout and menus, and whether remediation is included. A small site is a compact project; a store with accounts and a custom checkout takes longer. We estimate after seeing the site.
Will an accessibility overlay make us compliant?
No. A one-click widget does not repair headings, labels, keyboard paths or contrast, and it can interfere with a screen reader someone already runs. We remove that dependency and fix the interface.
Can you fix a site you did not build?
Yes. Most of this work is on an existing WordPress, WooCommerce, Laravel or custom front end. We change the theme in place, or coordinate with your developers if you prefer to ship the fixes.
Do automated scanners replace manual testing?
They cover a minority of issues: labels, some contrast failures and empty controls. Keyboard behaviour, screen reader output and the WCAG 2.2 rules on focus, dragging and authentication still need a person.
Ready to Make the Site Usable for More People?
Tell us which flows matter and whether you sell to customers in the EU. We will run a web accessibility audit of the templates against WCAG 2.2 and, where the European Accessibility Act applies, separate the technical gaps from the legal questions. Contact us to start, or see the full list of CodeWiz services.