Web accessibility in Switzerland: requirements, WCAG and action plan

A visitor should be able to read your information, choose a service and send an enquiry using their preferred tools: a keyboard, screen reader, zoom or voice control. Web accessibility means identifying barriers that prevent these tasks and correcting the content, interface and code.

For a Swiss organisation, start with two decisions: identify the requirements that apply to your activity and select the journeys to test. WCAG provides a technical reference. The legal framework depends on your organisation, the service you offer and the markets you serve.

Which requirements apply to your organisation?

Federal administration

Starting point — The Swiss Federal Bureau for the Equality of People with Disabilities presents eCH-0059 version 3 and WCAG 2.1 Level AA as the reference for federal digital accessibility.

Action to plan — Include applicable requirements in the specification and plan a documented assessment.

Canton, municipality or organisation performing a public function

Starting point — Check applicable cantonal, sectoral and contractual requirements.

Action to plan — Ask your legal adviser or commissioning authority which standard, scope and evidence they require.

Private business offering services to the public in Switzerland

Starting point — Article 6 of the Disability Discrimination Act prohibits disability discrimination. It does not, by itself, introduce mandatory WCAG AA certification for every private website.

Action to plan — Examine barriers to accessing your services and define an appropriate technical target.

Business offering a covered service to consumers in the EU

Starting point — Examine the European Accessibility Act and its national implementation in the relevant countries.

Action to plan — Check the service category, exemptions and national requirements before setting the scope.

Sources: Swiss federal accessibility guidance, Disability Discrimination Act on Fedlex and EU Directive 2019/882.

Services sold in the European Union

Since 28 June 2025, national provisions implementing the EAA cover, among other categories, e-commerce services for consumers. Certain banking, transport and communications services also fall within its scope. European visitors to a Swiss website do not provide enough information to describe your legal situation: examine what you sell, to whom and in which country.

The directive exempts microenterprises providing services. It defines a microenterprise as a business employing fewer than ten people and whose annual turnover or annual balance sheet total does not exceed EUR 2 million. Rules for products differ. Check your situation and national provisions with a qualified adviser. EAA, Articles 2, 3, 4 and 31.

Set an explicit WCAG target

The Web Content Accessibility Guidelines describe testable criteria. The W3C groups them under four principles: making information perceivable, enabling people to operate the interface, making it understandable and ensuring compatibility with assistive technologies.

For a new project, you can set WCAG 2.2 Level AA as a technical target, subject to applicable requirements. Record the version and level in the contract: “accessible” without a defined scope gives you no clear way to assess delivery. The W3C recommends WCAG 2.2 for new work while maintaining earlier versions. Level AA includes criteria at both Level A and Level AA. WCAG 2.2, W3C.

WCAG 3.0 remains a working draft. Do not present it as an adopted conformance standard for your website. WCAG 3.0 status.

Audit complete journeys

Start with tasks that provide access to your service: finding information, choosing an offer, booking, paying or contacting your team. Checking the homepage does not describe the difficulties in a modal form or a payment process supplied by a third party.

Prepare a sample covering page templates, reusable components, error states and connected steps. Include both FR and EN versions. Add documents needed to complete the task, such as a price-list PDF or a downloadable form.

Combine assessment methods

An automated tool helps your team detect code issues and some colour combinations. A high score does not prove conformance with the full standard. The W3C recommends combining tools with human assessment; no tool can establish website accessibility on its own. Evaluating accessibility, W3C.

Organise checks around observable questions:

Keyboard

can you reach controls, see the focus, open and close dialogs, then complete the task?

Screen reader

can you hear labels, required fields, errors and the confirmation?

Zoom and narrow layouts

can you read and operate controls without hiding essential content?

Content

do headings describe sections? Do links identify their destination? Do informative images have appropriate alternatives?

Media

do people who cannot perceive the audio or visuals have the required alternatives to understand the content?

Include people with disabilities when assessing usability. Their observations complement technical testing; a few user sessions do not replace a conformance assessment of the stated scope. Use our keyboard navigation checklist to prepare your initial checks.

Example: a booking enquiry in French and English

This fictional scenario concerns an SME with a bilingual form, date selection and confirmation. The table shows how to turn a barrier into a verifiable task. These are not findings from an EWM client project.

The calendar works only with a mouse.

Effect on the visitor — A keyboard user cannot choose a date.

Correction and acceptance check — The developer enables keyboard operation; the tester checks selection, closing and focus return.

The form indicates errors only in red.

Effect on the visitor — A visitor may not identify the affected field or understand the required correction.

Correction and acceptance check — The developer associates a text message with the field; the tester checks its announcement and retention of other entered values.

A button uses very pale grey text.

Effect on the visitor — A visitor with low vision struggles to read the action.

Correction and acceptance check — The designer adjusts colours and checks text contrast across the button’s states.

The English page retains a French language declaration.

Effect on the visitor — A screen reader may pronounce the text using the wrong language rules.

Correction and acceptance check — The developer corrects HTML lang; the tester checks both versions.

Submission displays only a small tick.

Effect on the visitor — The visitor cannot tell whether the enquiry succeeded.

Correction and acceptance check — The team adds an explicit confirmation and checks its perception with assistive technologies.

For ordinary text, WCAG AA generally requires a contrast ratio of at least 4.5:1, or 3:1 for large text as defined by the criterion. Exceptions apply; components and graphical information have separate requirements. Do not assess the whole interface against a single threshold. W3C explanation of Criterion 1.4.3.

Declare content language with lang, for example <html lang="fr"> and <html lang="en">. Identify passages in another language where the criterion requires it. SEO hreflang annotations do not replace this declaration. Declaring language in HTML, W3C.

Prioritise and budget for corrections

First address barriers that prevent essential tasks: signing in, ordering, booking or making contact. Then examine shared components, since fixing a menu or form field can affect several pages. Allocate editorial work to text alternatives, documents and multimedia content.

For each issue, record the page, tested state, reproduction steps, relevant criterion, user impact and responsible person. Add an acceptance check. “Improve the form” remains vague; “announce the email-field error and allow correction without losing other values” gives your team a task.

Cost depends on templates, components, journeys, documents and integrations. A third-party calendar may require a supplier change; a shared-component issue may need one correction followed by several checks. Separate the quotation into assessment, corrections, content remediation and verification after changes. Ask for scope assumptions rather than treating one certification price as universal.

Check third-party tools and feedback channels

Include consent banners, calendars, payments and chat tools in your tests. Before selecting a supplier, request assessment results, the versions covered and its correction procedure. An unusable booking process remains a barrier for your customer even when your team does not develop the calendar. Include responsibilities and replacement options in the contract.

Provide an accessible way to report difficulties. Explain which details help: the page, task, problem encountered and contact method. If your organisation must publish an accessibility statement, check the required content and format. The Swiss federal bureau publishes a statement describing known limitations and contact details on its own website. Federal bureau example.

Prevent regressions after launch

Assign ongoing responsibilities. The designer specifies focus and error states. Developers check components and interactions. Content publishers maintain useful alternatives and documents. The product owner keeps the list of journeys to retest after changes.

Include checks that you can automate in your releases, then retest sensitive journeys when forms, navigation or suppliers change. Train editors using examples from their CMS. Someone can undermine a clear component by replacing its label with “click here” or publishing an unusable document.

Frequently asked questions

Should we target Level AAA?

Choose the target according to your audience, service and applicable requirements. You can adopt useful AAA criteria without claiming full AAA conformance. Ask the evaluator to distinguish requirements within the scope from additional improvements.

Is an accessibility extension enough?

Before choosing a tool, check which problems it fixes and which remain in the code, content and journeys. Do not treat installation as proof of conformance. Assess the resulting service with the same methods as the rest of your website.

Can we claim conformance after a partial audit?

Describe the assessed scope, date, method and limitations. WCAG conformance requirements include complete pages and complete processes. A sample review helps organise corrections; it does not justify a claim broader than its findings. WCAG 2.2 conformance requirements.

Does accessibility improve SEO and conversions?

Clear headings, descriptive links and understandable content help visitors. Measure enquiries, abandonment and difficulties before and after changes, accounting for other website changes. WCAG conformance alone does not establish a percentage gain or an improvement in rankings.

Prepare your next audit

Gather your priority journeys, languages, external suppliers and applicable constraints. You can then decide which corrections belong in the existing website and which to include in a redesign. Our UI/UX design and website development services help plan this work alongside design and development.