Web Accessibility and WCAG 2.2 Compliance

We make sure your site can be used with a keyboard, with a screen reader and in low-vision conditions, and get it technically ready for the legal requirements of the EU market.

WCAG 2.2 AA European Accessibility Act Manual and Automated Testing Code Remediation
AddressAtaşehir, Istanbul
Phone+90 850 335 10 87
E-mailinfo@360-soft.com
Web Accessibility and WCAG 2.2 Compliance

A site everyone can use

Web accessibility means a site can be used by everyone, including people with visual, hearing, motor or cognitive disabilities. In practice it means that someone who cannot use a mouse can navigate the site with a keyboard alone, that a screen reader user can hear what a product image shows and what a form field expects, and that someone with colour blindness does not have to understand an error message from the colour red alone. The same changes also make life easier for a user shopping on their phone in bright sunlight, someone with an arm in a cast, or an older user.

The international technical reference for this is the WCAG (Web Content Accessibility Guidelines) published by the W3C. The current version is WCAG 2.2, and its success criteria are defined at three levels, A, AA and AAA; legislation and corporate tenders usually target level AA.

Why is it on the agenda now?

The European Accessibility Act (EAA) has applied since 28 June 2025. It requires services offered to consumers in the EU, such as e-commerce, banking services, e-books and passenger transport ticketing, to be accessible. In practice the European standard EN 301 549 is used as the technical reference, and the web section of that standard is based on the WCAG criteria. Enforcement and penalties are set by each member state’s own national legislation.

Who should prioritise it?

  • E-commerce sites selling directly into the EU: companies selling to EU consumers through a German, French, Dutch or English-language store.
  • Software and digital service providers with corporate customers in the EU: SaaS and software companies whose customers ask suppliers for an accessibility statement for their own compliance.
  • Companies bidding for public sector and large enterprise tenders: projects whose technical specification requires WCAG AA compliance.
  • Any site with a broad user base: even where there is no legal obligation, accessibility problems mean lost conversions; a checkout form that cannot be completed with a keyboard loses sales.

Audit and remediation scope

Each finding is reported with the relevant WCAG success criterion, the user group it affects and the remediation method.

Automated scanning

Using axe-based tools and Lighthouse on pages selected per template to extract the issues a machine can detect.

Keyboard and focus testing

Checking that every interactive element is reachable with Tab, that the focus order is logical, and that the focus indicator is visible and not hidden under other elements (WCAG 2.2 - 2.4.11).

Screen reader testing

Testing critical flows by ear with NVDA (Windows), VoiceOver (macOS and iOS) and TalkBack (Android): menu, search, product page, basket, checkout and account sign-up.

Visual and content checks

Colour contrast, text resizing and reflow at 320 pixels wide, alternative text, heading hierarchy, link text and language declarations.

Forms and error handling

Label-to-field association, required field indication, error messages announced to screen readers, no repeated requests for the same information (3.3.7), and accessible authentication (3.3.8).

Component and ARIA fixes

Bringing custom components such as dropdown menus, modals, tabs, accordions, sliders and date pickers in line with WAI-ARIA patterns, and cleaning up unnecessary ARIA.

Touch targets and motion

Bringing small mobile buttons up to the 24x24 CSS pixel minimum (2.5.8), alternatives to dragging actions (2.5.7), and respecting motion and animation preferences.

Media and documents

Captions and transcripts for videos, control over auto-playing media, and accessibility checks of downloadable PDFs.

From audit to lasting compliance - Web Accessibility and WCAG 2.2 Compliance

From audit to lasting compliance

01

Scope and sampling

We identify your site’s page templates (home, category, product, content, form, basket, checkout, account) and critical user flows. For sites with thousands of pages, sampling is done per template.

02

Audit

Automated scanning, keyboard testing, screen reader testing and visual checks are carried out against the WCAG 2.2 AA criteria.

03

Findings report and prioritisation

Findings are ranked by criterion, template, user impact and remediation effort. Points where a fix in a single template improves hundreds of pages are moved to the front.

04

Code remediation

Fixes are made in the theme, the component library or the application code; if you prefer, your team receives remediation instructions with code examples.

05

Verification testing

The fixed criteria are retested using the same methods, and any remaining known limitations are documented.

06

Statement and continuity

A draft accessibility statement is prepared. To prevent regressions in new content and features, an editor checklist is provided and automated accessibility testing is added to the CI pipeline.

What you receive at the end of the work

Deliverable Contents Who is it for?
WCAG 2.2 AA audit report Pass / fail / not applicable assessment per criterion, with evidence for each finding (screenshot, code snippet) Management, legal adviser, corporate customers
Prioritised remediation list Findings grouped by template, effort estimates, code examples Development team
Remediated code Fixes made in theme, component and application code (if remediation is in scope) Site owner
Verification report Retest results after remediation and remaining limitations Management, auditors
Draft accessibility statement Assessment standard, limitations, feedback channel Site visitors, regulators
Content editor checklist What to watch for when publishing images, headings, links, tables and PDFs Content and marketing team
How is it priced? - Web Accessibility and WCAG 2.2 Compliance

How is it priced?

Pricing

There is no fixed price published on the site for accessibility audits and remediation. The cost depends on the number of page templates, how many custom components there are, the number of languages, and whether the fixes are made by us or by your team. Once you share your site’s address we carry out an initial review, and a fixed-price quote specific to your project is sent within 24 hours.

If you are planning a new site

Adding accessibility after the fact is always more expensive than designing it in from the start. If you are planning a new project, we set up the colour palette, typography and component library to WCAG 2.2 AA during the UI/UX Design and Product Discovery phase. We use the same foundation in our Corporate Web Design and E-Commerce projects. For details on the front-end code itself, see our Frontend Development page.

The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to certain products and services offered to consumers in the EU market, and e-commerce services are among them. What matters is not where a company is established but whether it offers services to consumers in the EU, so businesses in Turkey, the Gulf or elsewhere can fall within scope. There is an exemption for microenterprises providing services. We recommend getting your legal adviser’s opinion to confirm your company’s position; we take care of the technical compliance side.

WCAG 2.2 keeps all the criteria of 2.1 (except 4.1.1 Parsing, which has been removed) and adds new ones. The key additions at level AA are: the focused element must not be hidden under a sticky header or cookie banner, drag-and-drop actions must have a single-pointer alternative, click targets must be at least 24x24 CSS pixels, and login screens must not require a puzzle or memory test. At level A, help links must appear in a consistent place and users must not be asked for the same information again and again.

No. A JavaScript widget added to the page may offer buttons to change text size or contrast, but it does not fix missing form labels, a broken heading hierarchy, menus that cannot be reached by keyboard or meaningless link text at the source. Screen reader users report that these tools sometimes make the experience even harder. Compliance is achieved by fixing the HTML, CSS and JavaScript code.

Automated tools (such as axe, Lighthouse and WAVE) quickly find the issues a machine can detect, such as missing alternative text or insufficient contrast; but a large share of WCAG criteria require human judgement. For example, a tool can tell whether an image has alternative text, but not whether that text is meaningful. In our audits we combine automated scanning with keyboard testing and screen reader testing.

Not as a direct ranking factor, but the two disciplines rest largely on the same foundations: a meaningful heading structure, descriptive link text, image alternative text and clean HTML semantics. An accessible site is also easier for search engines and AI systems to understand.

Yes. After the audit and remediation, we prepare a draft accessibility statement covering the standard the site was assessed against, known limitations and the contact channel for accessibility feedback. For services within the scope of the EAA, we recommend finalising how this information is presented together with your legal adviser.

The next success story
is yours.

The first consultation is free. We prepare a tailored proposal within 24 hours.

Get a free quote