Accessibility of e-shops according to Act No. 424/2023 Coll.: Complete procedure

In June 2025, Act No. 424/2023 Coll. comes into force, which introduces the obligation of digital accessibility for e-shops and online services. This law is based on EU Directive 2019/882 and aims to ensure that digital services are accessible to everyone - including people with disabilities.

The law does not only affect the public sphere, as it used to, but it also affects commercial entities such as e-shop operators, which is why it may be important for you to pay attention to it. The law is set to take effect on 28 June 2025.

The Act introduces new obligations for e-shops, but:

• it does not provide for a specific technical solution, but only refers to the so-called harmonised standard (EN 301 549) and the principles of WCAG 2.2,
• accessibility does not mean changing the design or removing features, but ensuring that everyone can use them,
• it's not about heavy customization - if you know what to do, you can do it with a reasonable investment.

What are the risks of non-compliance?

In case of non-compliance with the requirements of Law 424/2023, the law foresees the possibility of sanctions. Threats:

• inspections by the CTIA on the basis of complaints,
• warnings and calls for remedial action,
• fines in case of non-compliance.

Checklist of requirements

To get to grips with accessibility, we have reviewed legal analyses, official interpretations and technical standards. Based on this, we have compiled a 13-point checklist that reflects the requirements of the harmonised standard EN 301 549 and the principles of WCAG 2.2 at level AA.

What your e-shop must comply with according to Law 424/2023:

We have studied, tested and deployed all web customizations ourselves on several projects using tools such as NVDA, JAWS, VoiceOver, TalkBack, Wave, LightHouse or axe DevTools. Here is an overview of the main areas of focus:

1. Keyboard accessibility - the entire site must be navigable without a mouse.
2. Compatibility with screen readers - the site must work with screen readers like NVDA, VoiceOver, and source code semantics like heading levels need to be checked.
3. Text alternatives for images and media - each image must have a meaningful alt caption.
4. Sufficient contrast - colours must be legible for people with visual impairments, i.e. a minimum contrast ratio of 4.5:1.
5. Text magnification and responsiveness - the site must be usable at 200% magnification, even on mobile devices.
6. Accessible forms - each field must have a correctly assigned label.
7. Logical content structure - headings, navigation and buttons must have a logical hierarchy.
8. Page language tagging - the language of the site must be correctly defined with the appropriate tag.
9. Visible and uncluttered focus of controls - active controls must always be clearly labeled.
10. Size of clickable elements - buttons must be comfortable even on a mobile phone with a minimum size of 24x24 px.
11. Non-drag control - drag & drop must have an alternative, for example in the form of control via keyboard buttons.
12. Consistent help and contact - navigation, contact and help must always be available.
13. Published accessibility statement - information about compliance and the tools and processes used to achieve this must be publicly displayed on a prominent separate sub-page or within the terms and conditions.

This article can serve as a guide for anyone who chooses to manage accessibility on their own. If you want to tackle the customisation of your e-commerce site yourself, we recommend following the checklist below, going through each area of the site and identifying what needs to be adjusted. This includes the obligation to draw up an accessibility statement, which has been required to be published on the website since 28 June. By law, this document is supposed to summarise how your e-shop meets the accessibility requirements and which tools or procedures you have used to implement them.

Procedure for addressing compatibility with the AccessibilityStatement

A basic summary of the process:

1. Begin auditing the site with the tools listed.
2. Review the requirements - test each point and correct if necessary.
3. Consult the screen reader and verify each change with an automated test.
4. Keep the Requirements Fulfillment page updated and indicate how specific points have been met.
5. Result: the website/e-shop is compliant with the law and you maintain it on an ongoing basis.

Testing with screen readers:

Screen readers

• NVDA (Windows, free)
  • NVDA website (Czech and English)
  • The most widely used screen reader on Windows, suitable for testing common websites.
  • With support for keyboard control.
• JAWS (Windows, paid but widespread)
  • JAWS website
  • Professional solution for the blind, supports complex web applications.
• VoiceOver (macOS/iOS, free)
  • Built-in reader in MacBook/iPhone/iPad.
  • Activation in accessibility settings.
• TalkBack (Android, free)
  • Built-in reader on Android phones
  • Activation in settings -> Accessibility.

Testing guides

• Web testing with NVDA (WebAIM)
• How to get started with VoiceOver on Mac

Accessibility testing tools:

• Used to quickly check for basic issues.
  • axe DevTools (Chrome/Firefox extension)
  • Lighthouse (tool in Chrome DevTools)
  • WAVE: Online check here

Check procedure and workarounds as required

1. Keyboard accessibility

• Task: All functions and navigation must be usable only via keyboard (Tab, Enter, Spacebar, Arrow keys).
• Implementation:
  • Test navigating (Tab/Shift Tab) through all controls.
  • Do not use non-standard widgets without proper ARIA labeling.
  • Set tabindex correctly where necessary.
  • Do not block users in modal windows.

2. Compatibility with screen readers

• Task: Verify that the site is properly readable and navigable with screen readers, and correct if necessary according to accessibility guidelines
• Implementation:
  • Semantic HTML tags (<h1>, <nav>, <main>, <button>, <label>, etc.) are used.
  • Each image has a meaningful alt attribute.
  • All form elements have an associated <label>.
  • Graphic elements and icons are not used without a textual description; hidden text or ARIA labels are added where needed.
  • Headings use the correct level (<h1>, <h2>, ... without skipping levels).
  • Dynamic content (modal windows, dialogs) is marked using ARIA attributes (e.g. role="dialog", aria-live).
  • Page language is set correctly (e.g. <html lang="en">).
  • The menu is in <nav> and is described for screen readers (aria-label="main navigation").
  • The navigation links have descriptive names.

3. Text alternatives for images and media

• Task: Each image must have a meaningful alt attribute. Decorative images should have empty alt="" (visual separators, repeating illustration icons, graphic backgrounds, etc.)
• Implementation:
  • Review HTML/templates, check images.
  • Add or edit alt attributes.
  • Caption or transcribe videos.

4. Sufficient colour contrast

• Task: Text and controls must be clearly legible (minimum contrast ratio 4.5:1).
• Implementation:
  • Check the main colours via WebAIM Contrast Checker.
  • Adjust the colours in the CSS as needed.

5. Text enlargement and responsiveness

• Challenge: The website must work with text magnification up to 200% and on all devices.
• Implementation:
  • Use relative units (em, rem, %) rather than px (to ensure maximum compatibility across devices, browsers and assistive technologies).
  • Test zoom in the browser.
  • Test behaviour on mobile/tablet (responsive design).

6. Accessible forms

• Task: Each input element has an assigned <label>, and error messages are understandable.
• Implementation:
  • Review all forms.
  • Each field must have a visible label.
  • Error messages to be made available to readers (aria-live, role="alert").

7. Logical structure of content

• Challenge: Proper use of tags (header, nav, main, footer, button, label, etc.), user can easily navigate the content, navigation elements are clear and predictable.
• Implementation:
  • Go through the HTML, check the correct hierarchy of headings (<h1>, <h2>, ...).
  • Using <button> tags.
  • Menu is in <nav> and described for readers (aria-label="Main navigation")
  • Validate code: W3C Validator

8. Page language designation

• Task: The entire page declares the main language using <html lang="en">.
• Implementation:
  • Check the page template.
  • In case of foreign language content, mark the change.

9. Focus - visible, sufficiently noticeable

• Task: The focus of the controls must always be visible and must not be overlaid and must be sufficiently visible (e.g. frame, colour change).
• Implementation:
  • Verify focus visibility on all interactive elements (buttons, links, forms). Ensure that the focus is not overlaid on other elements
  • Modify CSS to make the focus look distinct (outline, box-shadow or border).
  • Verify with keyboard-only control (Tab/Shift Tab).

10. Minimum target size

• Task: Buttons and controls should be at least 24×24 px so that they can be operated comfortably on touch devices.
• Implementation:
  • Check that each clickable element (buttons, icons, menu links...) has:
    • either the size itself is at least 24×24 px
    • or sufficient padding to extend the resulting clickable space
  • Test on touch devices (mobile, tablet) that the element can be comfortably pressed without risk of error.
  • If it is not technically possible to enlarge (e.g. due to design), it is recommended to enlarge the active area of the control.
• It does not have to be fulfilled when:
  • The function can be achieved using another control on the same page that meets this criterion.
  • The target is in a sentence or its size is otherwise limited by the height of a line of text that is not the target.
  • All exceptions

11. Control without dragging

• Purpose: Functions on the site must not depend solely on drag & drop. The user must be able to control these functions in other ways - for example, by clicking or using the keyboard.
• Implementation:
  • Verify functionality without a mouse, using only the keyboard and in a screen reader environment.
  • If no alternative is available, the function needs to be rethought or redesigned.

12. Help, navigation, contact options

• Task: If a site offers contact or support options (e.g., email, help, chat), they must be accessible and placed consistently on all pages. Likewise navigation, help, etc.
• Implementation:
  • Ensure that supporting elements (navigation, contacts...) are present:
    • visible, accessible and functional
    • positioned consistently across all pages of the site
  • Verify when operated by keyboard only.

13. Accessibility information in public documents

• Task: Publish information on meeting accessibility requirements in the general terms and conditions or on the web.
• Implementation:
  • Provide a description of how the service meets accessibility requirements in the terms and conditions or on a separate page.
  • Provide information in audio form on request.
  • Ensure that the information is in an accessible format (readable text, not just a picture).