Cyprus e-commerce accessibility law: a practical 2026 audit

Decide whether the online service is covered

Start with the transaction, not the appearance of the website. The Cyprus law defines an e-commerce service as one supplied at a distance through a website or mobile service, electronically and at a consumer's individual request, with a view to concluding a consumer contract. A product listing, account registration, basket and checkout can therefore form one covered service. A page that merely describes a company without a route to a consumer contract raises a different scope question. Record which journeys actually lead to a consumer order, subscription or booking.

Article 4(2) includes e-commerce among the services supplied to consumers from 28 June 2025. A business should not assume that an older website is exempt simply because it launched before that date. The date attaches to covered services supplied after it. The law has specific exclusions for certain older recordings and office files, online maps under conditions, uncontrolled third-party content and genuine archives. These are content exclusions, not a blanket exemption for an established shop or an outdated checkout.

Document the business model carefully. A pure business-to-business portal does not automatically have the same consumer-service profile, but a mixed portal may still allow individual consumers to contract. A marketplace, booking service or app may also involve several parties controlling separate parts of the journey. Identify who operates the interface, who controls the payment step and which entity contracts with the customer. This produces a scope record that can be revisited when a new sales channel launches.

For a separate check of the information shown before purchase, use the online-shop disclosures guide. Accessibility review should include those disclosures without replacing the consumer-law review.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); Directive (EU) 2019/882 on accessibility requirements for products and services

Check the microenterprise exemption with evidence

Cyprus Article 5(5) exempts microenterprises that provide services from the accessibility requirements in Article 5(3) and associated compliance obligations. This is a genuine statutory exemption, but it should be established from the applicable definition and the facts of the entity providing the service. The directive defines a microenterprise by fewer than ten persons and annual turnover or annual balance-sheet total not exceeding EUR 2 million. Examine headcount and the relevant financial measure rather than using the marketing label 'small business'.

Keep a dated note of the evidence and the legal entity assessed. A founder may operate one shop personally while another company in a group operates the actual contracting service. A provider may grow beyond the threshold or restructure. Recheck the position at least with annual accounts and material staffing changes, and when the consumer contract is transferred to a different entity. Do not publish an unqualified claim that every small Cyprus shop is exempt. The exemption is tied to a defined class of service provider, not to turnover alone.

Even if the exemption applies, removing basic barriers is commercially and operationally useful. A keyboard-accessible basket and readable error messages reduce abandoned orders and support customers with temporary or permanent impairments. The statutory exemption should not be converted into a claim that inaccessible design is good practice or that no other legal duties can apply. Keep the exemption conclusion separate from the technical accessibility assessment so future growth does not require rediscovering what is broken.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); Directive (EU) 2019/882 on accessibility requirements for products and services

Map every step from discovery to confirmation

Test a real purchase path rather than only the homepage. Begin with navigation and search, then a product or service detail, option selection, basket, account or guest choice, address form, terms, payment authentication and confirmation. Include cancellation and recovery from errors. List each step, its owner, the device or browser used, and the critical action a customer must complete. A shop can pass a homepage scanner yet fail at an inaccessible size selector or a payment challenge embedded near the end.

Include the content that enables an informed choice: price, delivery conditions, product variants, accessibility information supplied by the relevant economic operator and the terms accepted at checkout. Annex I of the Cyprus law includes specific e-commerce requirements for information about the accessibility of goods and services when that information is provided by the responsible operator. It also addresses identification, security and payment functions supplied as part of the service. This makes a checkout-only audit too narrow.

Run the journey for both a first-time and a returning customer. Cookie dialogs, saved addresses, autofill, failed card attempts and account recovery alter the path. Where the merchant relies on a platform template, payment provider or external widget, record the integration and the controls available to the merchant. Supplier ownership can explain who fixes a defect, but it does not make the customer-facing barrier disappear. Agree a tested workaround or escalation rather than closing an issue because it sits in third-party code.

If the purchase flow contains optional tracking, coordinate this review with the cookie-consent audit, including whether the consent controls themselves can be operated accessibly.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text)

Test keyboard operation, focus and readable structure

Navigate every critical step using a keyboard alone. The customer should reach controls in a sensible order, see where focus is, open and close menus, change product options, submit forms and recover from an error without a mouse. Check that a modal does not trap focus permanently or return it to an unrelated point after closing. A visual button built as a non-interactive element may respond to a pointer but not to keyboard activation. Record the exact page, control and failed action for each finding.

Inspect page structure with a screen reader as well as visually. Headings should describe sections, form fields need clear names and instructions, and status changes should be announced. A price update after a variant change or a basket confirmation should be discoverable without hunting through the page. Check that images conveying purchase information have meaningful text alternatives and that decorative images do not produce noise. A screen reader should not have to read a meaningless file name to identify the product.

The W3C's WCAG 2.2 is a useful technical testing framework for these checks, but this guide does not claim that a single WCAG badge by itself proves compliance with every requirement of Cyprus Law 57(I)/2024. Use the legal annex to define the obligation, then use testable criteria and assistive-technology checks to verify the experience. Automated scans can catch missing labels or contrast problems; they cannot reliably judge whether a checkout instruction is understandable or a complete purchase remains possible.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); W3C Web Content Accessibility Guidelines (WCAG) 2.2

Follow forms, authentication and payment to completion

Forms often create the most consequential barriers. Enter invalid data deliberately and check whether the error identifies the affected field, explains what must change and can be found by keyboard and assistive technology. Do not rely solely on red borders or an icon. Verify that required fields are announced and that the form retains previously entered information where practicable. Test address lookup, country selection, delivery method, coupon and terms checkbox because each can block completion.

Authentication deserves its own test. Password entry, one-time codes, anti-bot checks and account recovery must be considered as part of the consumer journey when supplied in the service. The Cyprus law expressly addresses accessible identification, security and payment functions. A merchant should test the actual provider integration, including a failed challenge and retry, rather than assuming a supplier's compliance statement covers the embedded implementation. A separate mobile app may use different controls and need separate evidence.

Payment is complete only when the customer can understand the amount, select the payment method, pass any required verification and receive a usable outcome. Test declines, timeouts and duplicate-submit protection. An inaccessible error may leave a customer unsure whether money was taken; a confirmation without order details can make it hard to obtain support. Keep a test order identifier and screenshots or recordings that avoid exposing real payment details. If production testing is impractical, use a representative staging flow and verify that production uses the same component and configuration.

The separate electronic-signatures guide addresses signed documents; it should not be confused with accessibility of a purchase or payment screen.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); W3C Web Content Accessibility Guidelines (WCAG) 2.2

Check mobile layouts, documents and customer support

Repeat the buying journey on a narrow screen with enlarged text. Menus, cookie choices, sticky purchase buttons and payment overlays can obscure focus or hide information when the viewport changes. Check portrait and landscape where relevant, zoom and text spacing, and whether a person can complete the same essential task without precise gestures. A desktop audit cannot establish that a mobile service works. Record the tested versions of the site and app because small interface releases can change the result.

Look at downloadable material used in the transaction: terms, invoices, instruction sheets and confirmation files. A law may exclude certain office files published before 28 June 2025, but do not treat that limited content exclusion as permission to issue inaccessible new documents. Identify which documents are necessary to understand or complete the service and offer a usable presentation. If a product's accessibility information is provided by its responsible economic operator, determine how it will be displayed in a way a customer can perceive before purchase.

Support channels matter when something fails. Tell customers how to report a barrier and give staff a route to resolve an affected order. An alternative telephone or email route can help a customer immediately, but it should not be treated as a permanent substitute for fixing the covered digital service. Track the reported step, assistive technology if volunteered, severity, owner and resolution. Avoid collecting more disability or health information than is necessary for the support request.

For the data collected through support and account flows, review the retention-schedule guide alongside the accessibility work.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); W3C Web Content Accessibility Guidelines (WCAG) 2.2

Keep a compliance record that survives the next release

Article 14 requires covered service providers to design and provide accessible services, prepare the information described in Annex III explaining how applicable requirements are met, make that information available in accessible forms, and maintain procedures for ongoing compliance. A generic 'we care about accessibility' footer sentence is not equivalent to an explanation grounded in the actual service. Identify the service, applicable requirements, relevant features, known limitations, contact route and date of review in the public information and supporting internal record.

Use a practical issue register. For each barrier, record the affected journey, legal or technical criterion, reproduction steps, customer impact, owner, fix and retest evidence. Prioritise blockers that prevent a consumer from ordering, paying or obtaining essential information. Keep evidence of tests performed with real assistive technology and human judgment, not just a score from an automated scanner. When a third-party provider owns the component, add its ticket and the merchant's interim customer-support path.

Put accessibility into release control. A new promotion popup, subscription option or payment provider can reintroduce barriers after an initial audit. Add a keyboard path, mobile layout and error-flow check to acceptance testing for changes to the checkout. Revisit the published accessibility information when the service changes. The law expects procedures that continue to work as service features and technical specifications evolve. Assign one person to sign off remediation and record exceptions rather than leaving findings in an unowned spreadsheet.

This workflow can sit next to the DPIA review process when a redesign also creates significant personal-data risks; the two assessments address different questions.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text)

Treat exceptions and transition dates narrowly

Article 15 recognises limits where meeting a requirement would fundamentally alter the basic nature of a service or impose a disproportionate burden. It does not give a general opt-out for an inconvenient redesign. The operator must assess the relevant criteria in the law, document the analysis and retain it for five years, subject to the specific provisions. A service provider relying on disproportionate burden must revisit its assessment when the service changes, when the authority asks and at least every five years. Record which requirement is affected and what still can be improved.

Article 45 contains transitional provisions concerning certain products used to provide similar services and service contracts agreed before 28 June 2025. Those provisions should not be flattened into a claim that any pre-2025 website can wait until 2030. If a merchant believes a transition applies, identify the exact product or contract, the date, the relevant paragraph and the legal effect. A checkout widget updated in 2026 should be evaluated on its own facts rather than shielded by an unrelated historical supplier agreement.

The microenterprise service exemption and a documented disproportionate-burden assessment are also different routes. The former depends on provider size and the statutory rule; the latter concerns particular requirements and an evidence-based burden analysis. Keep the reasoning distinct in the file. If size, ownership, technology or contract terms change, review the conclusion. That discipline prevents an old decision from being repeated as a universal answer years later.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); Directive (EU) 2019/882 on accessibility requirements for products and services

Build a measured remediation plan

In the first stage, settle scope, entity and exemption questions; map all purchase journeys; collect existing supplier contracts and accessibility statements; and run baseline tests. Do not wait for a perfect inventory before fixing a keyboard-blocked order button. Preserve the failing state so the team can show what changed. Ask people with relevant accessibility expertise to test complex interactions, especially payment and authentication. A good audit combines legal scoping, engineering evidence and user experience.

Next, fix blockers before cosmetic defects: navigation, form labels, validation, authentication, payment and confirmation. Assign each issue a named owner and a target release. Retest the entire journey after a component changes, because a local fix can break another interaction. Publish accurate service information once it reflects what has actually been tested and what limitations remain. Avoid a blanket declaration of full compliance based on a single plugin, overlay or machine score.

Finally, create a recurring check tied to releases and support reports. Review analytics for abandonment as a signal to investigate, not as proof of accessibility. Keep the legal scope note, test matrix, issue log, supplier correspondence and public information together. If a customer reports an inaccessible route, provide practical assistance, investigate the specific barrier and update the backlog. This makes the programme useful both to customers and to the business if a regulator later asks how the service was assessed.

Basis and guidance: Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text); W3C Web Content Accessibility Guidelines (WCAG) 2.2

Primary sources and scope

Sources checked: October 7, 2026. This guide concerns the Republic of Cyprus. Examples are hypothetical, not client case studies. Check current official requirements before making a filing.

• Cyprus Law 57(I)/2024, Accessibility of Products and Services (consolidated text)
• Directive (EU) 2019/882 on accessibility requirements for products and services
• W3C Web Content Accessibility Guidelines (WCAG) 2.2
• European Commission AccessibleEU: Cyprus Accessibility of Products and Services Act