Accessibility compliance statement for ryzon.net

Last updated: 18/12/2025

This document was provided by AccessiWay to meet the requirements of the European Accessibility Act (EAA) and the German Accessibility Strengthening Act (BFSG).

Each more complex section is introduced with a simpler explanation.

Introduction

We want everyone to be able to use ryzon.net well – including people with disabilities. In this statement we explain what we do to make ryzon.net accessible. We follow the rules of the European Accessibility Act (EAA) and the WCAG guidelines.

Ryzon is committed to inclusion and accessibility. Our goal is for all users – regardless of physical or technical limitations – to use our service independently and without barriers.

This conformance statement describes the features of ryzon.net. We show how we meet the requirements of the following laws and standards:

  • European Accessibility Act,
  • EN 301 549,
  • Web Content Accessibility Guidelines (WCAG) 2.2
  • Accessibility Strengthening Act (BFSG)

We review this statement regularly as we continue to improve ryzon.net.

Overview

Description of the service

This is a B2C e-commerce platform for purchasing premium sports apparel online.

How to use ryzon.net (Accessibility & operation)

We strive to make ryzon.net easy for everyone to use. Here is an overview of how to operate it, especially when using assistive technologies:

ryzon.net usage description

Users can browse the catalog, add products to the cart, create an account, and complete a purchase through the checkout process. When they purchase a voucher, they can also download it.

The accessibility of ryzon.net

Our service works with the standard interaction methods of the operating system and common assistive technologies.

If you need further explanations on how to use ryzon.net, you can find various instructions in our Help Center https://ryzon.net/pages/faq. You can also contact our support to receive personal assistance. We are committed to providing any additional descriptions or explanations you need for a smooth experience with our service.

Compliance with accessibility requirements (How we meet the requirements)

We have reviewed ryzon.net with respect to the following frameworks: European Accessibility Act, Accessibility Strengthening Act (BFSG), EN 301 549, and WCAG 2.2. We ensure the following principles are met:

This section will be supplemented once the accessibility review of ryzon.net that we have commissioned is completed.

We have tested ryzon.net with the most common assistive technologies in various combinations of operating systems and browsers:

  • Screen readers such as NVDA and JAWS (Windows) as well as VoiceOver (Mac and iOS) help us ensure that all interactive elements are read out correctly and can be operated.
  • We also check usage with screen magnification and in high-contrast mode.

Our goal is to be compatible with the current versions of common assistive tools. We follow best practices from WCAG 2.2 and the EN 301 549 standard to ensure accessibility remains intact even with future technological developments.

Standards: On this basis, we apply the criteria of WCAG 2.2 (AA level, current version) as well as EN 301 549. Compliance with these standards is considered proof of conformity with the EAA, the Accessibility Strengthening Act (BFSG), and other corresponding regulations.

Ongoing monitoring and maintenance

Accessibility is not a one-off project for us but an ongoing process. This is how we ensure that ryzon.net remains accessible over time:

This section will be supplemented once the accessibility review of ryzon.net that we have commissioned is completed.

Feedback and contact

Your feedback helps us further improve ryzon.net. If you encounter barriers or have suggestions, you can contact us at any time by email, phone, or post. Please describe the problem as precisely as possible so that we can help in a targeted way.

We especially appreciate feedback from users when something does not work as expected. If you have difficulty accessing content or functions of ryzon.net or discover a barrier, we welcome your message.

Contact options: Email: accessibility@ryzon.net Postal address: Maastrichter Straße 45, 50672 Cologne, Germany

When you contact us, please specify as precisely as possible:

  • the page or function concerned,
  • what happened,
  • which assistive technology you may be using.

We aim to respond to your feedback within 15 working days and will do our best to resolve the issue promptly or keep you informed of our progress.

Right to complain:

If you feel that your accessibility concern has not been adequately addressed, you can file a complaint with the responsible supervisory authority. However, we hope to clarify any issues with you beforehand.

Contact: MLBF c/o Ministry of Labour, Social Affairs, Health and Equality of Saxony-Anhalt Postfach 39 11 55 39135 Magdeburg Phone: 0391 567 6970 Email: MLBF@ms.sachsen-anhalt.de

Version history: This document was last reviewed and updated on 18/12/2025. We plan to review it at least once a year or when there are significant changes to the service.

EN 301 549 Technical Report

Chapter 5: General requirements

Criteria

Conformance level

Notes and explanations

5.1 Closed functionality Header cell – no entry required Header cell – no entry required
5.1.2 General

Header cell – no entry required

Header cell – no entry required
5.1.2.1 Closed functionality

See 5.2 to 13

See information in 5.2 to 13
5.1.2.2 Assistive technology

See 5.1.3 to 5.1.6

See information in 5.1.3 to 5.1.6
5.1.3 Non-visual access

Header cell – no entry required

Header cell – no entry required
5.1.3.1 Audio output of visual information Not applicable
5.1.3.2 Auditory output including speech Not applicable
5.1.3.3 Correlation of auditory output Not applicable
5.1.3.4 User control of speech output Not applicable
5.1.3.5 Automatic interruption of speech output Not applicable
5.1.3.6 Speech output for non-text content Not applicable
5.1.3.7 Speech output for video content Not applicable
5.1.3.8 Obscured input Not applicable
5.1.3.9 Private access to personal data Not applicable
5.1.3.10 Non-disruptive audio output Not applicable
5.1.3.11 Private volume listening Not applicable
5.1.3.12 Speaker volume Not applicable
5.1.3.13 Volume reset Not applicable
5.1.3.14 Spoken languages Not applicable
5.1.3.15 Non-visual error identification Not applicable
5.1.3.16 Receipts, tickets and transaction outputs Not applicable
5.1.4 Functionality closed to text magnification Not applicable
5.1.5 Visual output for auditory information Not applicable
5.1.6 Operation without a keyboard interface Header cell – no entry required Header cell – no entry required
5.1.6.1 Closed functionality See 5.1.3.1 to 5.1.3.16 See information in 5.1.3.1 to 5.1.3.16
5.1.6.2 Input focus Not applicable
5.1.7 Access without speech Not applicable
5.2 Activation of accessibility features Not applicable
5.3 Biometrics Not applicable
5.4 Preservation of accessibility information during conversion Not applicable
5.5 Operable parts Header cell – no entry required Header cell – no entry required
5.5.1 Means of operation Not applicable
5.5.2 Distinguishability of operable parts Not applicable
5.6 Controls for locking or toggling Header cell – no entry required Header cell – no entry required
5.6.1 Tactile or auditory status Not applicable
5.6.2 Visual status Not applicable
5.7 Key repeat Not applicable
5.8 Acceptance of a double key press Not applicable
5.9 Simultaneous user actions Not applicable

Chapter 6: ICT with Two-Way Voice Communication

Criteria

Conformance level

Notes and 

explanations

6.1 Audio bandwidth for speech Not applicable
6.2 Real-time text functionality (RTT functionality) Header cell – no entry required Header cell – no entry required
6.2.1.1 RTT communication Not applicable
6.2.1.2 Simultaneous voice and text communication Not applicable
6.2.2.1 Visually distinguishable display
6.2.2.2 Programmatically detectable send and receive direction Not applicable
6.2.2.3 Speaker identification Not applicable
6.2.2.4 Visual indicator for audio in RTT communication Not applicable
6.2.3 Interoperability Not applicable
6.2.4 Responsiveness of RTT Not applicable
6.3 Caller identification Not applicable
6.4 Alternatives to voice-based services Not applicable
6.5 Video communication Header cell – no entry required Header cell – no entry required
6.5.1 General (informative) Header cell – no entry required Header cell – no entry required
6.5.2 Resolution Not applicable
6.5.3 Frame rate Not applicable
6.5.4 Synchronization between audio and video Not applicable
6.5.5 Visual indicator of audio via video Not applicable
6.5.6 Speaker identification via video (sign language) communication Not applicable
6.6 Alternatives to video-based services Header cell – no entry required Header cell – no entry required

Chapter 7: ICT with video capabilities

Criteria

Conformance level

Notes and explanations

7.1 Technology for processing subtitles Header cell – no entry required Header cell – no entry required
7.1.1 Playback of subtitles Not applicable
7.1.2 Synchronization of subtitles Not applicable
7.1.3 Preservation of subtitles Not applicable
7.1.4 Properties of subtitles Not applicable
7.1.5 Spoken subtitles Not applicable
7.2 Audio description technology Not applicable
7.2.1 Playback of audio description Not applicable
7.2.2 Synchronization of audio description Not applicable
7.2.3 Preservation of audio description Not applicable
7.3 Controls for subtitles and audio description Not applicable

Chapter 8: Hardware

Criteria

Conformance level

Notes and explanations

8.1.1 General requirements Header cell – no entry required Header cell – no entry required
8.1.2 Standard connectors Not applicable
8.1.3 Color Not applicable
8.2 Hardware products with speech output Header cell – no entry required Header cell – no entry required
8.2.1.1 Speech output volume range Not applicable
8.2.1.2 Incremental volume control Not applicable
8.2.2.1 Fixed-line devices Not applicable
8.2.2.2 Wireless communication devices Not applicable
8.3 Stationary ICT Header cell – no entry required Header cell – no entry required
8.3.2.1 Unobstructed high forward reach Not applicable
8.3.2.2 Unobstructed low forward reach Not applicable
8.3.2.3.1 Clear floor space Not applicable
8.3.2.3.2 Obstructed forward reach (< 510 mm) Not applicable
8.3.2.3.3 Obstructed forward reach (< 635 mm) Not applicable
8.3.2.4 Width of knee and toe clearance Not applicable
8.3.2.5 Toe clearance Not applicable
8.3.2.6 Knee clearance Not applicable
8.3.3.1 Unobstructed high side reach Not applicable
8.3.3.2 Unobstructed low side reach Not applicable
8.3.3.3.1 Obstructed side reach (≤ 255 mm) Not applicable
8.3.3.3.2 Obstructed side reach (≤ 610 mm) Not applicable
8.3.4.1 Height changes Not applicable
8.3.4.2 Clear floor or ground space Not applicable
8.3.4.3.2 Forward approach Not applicable
8.3.4.3.3 Parallel approach Not applicable
8.3.5 Visibility Not applicable
8.3.6 Mechanically operable components Not applicable
8.4 Mechanically operable components Header cell – no entry required Header cell – no entry required
8.4.1 Numeric keys Not applicable
8.4.2.1 Operability of mechanical parts Not applicable
8.4.2.2 Actuation force of mechanical parts Not applicable
8.4.3 Key cards, tickets, and travel passes Not applicable
8.5 Tactile indication of speech mode Not applicable

Chapter 9: Web (also applies to 10, 11, and 12)

This section will be supplemented once the accessibility review of ryzon.net that we have commissioned is completed.

Chapter 10: Non-web documents

Criteria

Conformance level

Notes and explanations

10.0 General (informative) Header cell – no entry required Header cell – no entry required
10.1.1.1 to 10.4.1.3 See Chapter 9, according to WCAG 2.2 criteria See Chapter 9, according to WCAG 2.2 criteria
10.5 Positioning of subtitles Not applicable
10.6 Timing for audio description Not applicable

Chapter 11: General

Criteria

Conformance level

Notes and explanations

11.0 General (informative) Header cell – no entry required Header cell – no entry required
11.1.1.1 to 11.4.1.3 See Chapter 9, according to WCAG 2.2 criteria See Chapter 9, according to WCAG 2.2 criteria
11.5 Interoperability with assistive technology Header cell – no entry required Header cell – no entry required
11.5.1 Closed functionality Header cell – no entry required Header cell – no entry required
11.5.2 Accessibility services Header cell – no entry required Header cell – no entry required
11.5.2.1 Support for platform accessibility services for user interface software See 11.5.2.5 to 11.5.2.17
11.5.2.2 Support for platform accessibility services for assistive technologies See 11.5.2.5 to 11.5.2.17
11.5.2.3 Use of accessibility services See information in 11.5.2.5 to 11.5.2.17
11.5.2.4 Assistive technologies Not applicable
11.5.2.5 Object information Not applicable
1.5.2.6 Row, column, and header information Not applicable
11.5.2.7 Values Not applicable
11.5.2.8 Relationships between labels and controls Not applicable
11.5.2.9 Relationships between parent and child elements Not applicable
11.5.2.10 Text Not applicable
11.5.2.11 List of available actions Not applicable
11.5.2.12 Execution of available actions Not applicable
11.5.2.13 Tracking of focus and selection attributes Not applicable
11.5.2.14 Change of focus and selection attributes Not applicable
11.5.2.15 Change notifications Not applicable
11.5.2.16 Changes in states and properties Not applicable
11.5.2.17 Changes in values and text Not applicable
11.6 Documented use of accessibility features Header cell – no entry required Header cell – no entry required
11.6.1 User control of accessibility features Not applicable
11.6.2 No disruption of accessibility features Not applicable
11.7 User preferences Not applicable
11.8 Authoring tools Header cell – no entry required Header cell – no entry required
11.8.1 Content technology Header cell – no entry required Header cell – no entry required
11.8.2 Creation of accessible content See Chapter 9, according to WCAG 2.2 criteria See Chapter 9, according to WCAG 2.2 criteria
11.8.3 Preservation of accessibility information during transformations Not applicable
11.8.4 Repair support Not applicable
11.8.5 Templates Not applicable

Chapter 12: Documentation and support services

Criteria

Conformance level

Notes and explanations

12.1 Product documentation Header cell – no entry required Header cell – no entry required
12.1.1 Accessibility and compatibility features Not applicable
12.1.2 Accessible documentation See Chapter 9, according to WCAG 2.2 criteria See Chapter 9, according to WCAG 2.2 criteria
12.2 Support services Header cell – no entry required Header cell – no entry required
12.2.2 Information on accessibility and compatibility features Not applicable
12.2.3 Effective communication Not applicable
12.2.4 Accessible documentation See Chapter 9, according to WCAG 2.2 criteria See Chapter 9, according to WCAG 2.2 criteria

Chapter 13: ICT with access to relay or emergency services

Criteria Conformance level Notes and explanations
13.1 Requirements for relay services Header cell – no entry required Header cell – no entry required
13.1.2 Text relay services Not applicable
13.1.3 Sign language relay services Not applicable
13.1.4 Lip-reading relay services Not applicable
13.1.5 Captioned telephone services Not applicable
13.1.6 Speech-to-speech relay services Not applicable
13.2 Access to relay services Not applicable
13.3 Access to emergency services Not applicable

Web accessibility

Disability is defined as any limitation of activity or participation in social life that a person experiences due to a significant, long-term, or permanent impairment of one or more physical, sensory, mental, cognitive, or psychological functions, multiple disabilities, or a health-related limitation.

Web accessibility means making online public communication services accessible to people with disabilities. It is based on four fundamental principles:

Perceivable:

Information and user interface components must be presented so they can be perceived by users. For example, by providing text alternatives for all non-text content, which can then be output in other forms depending on user needs: large print, Braille, speech output, symbols, or simplified language.

Operable: User interface components and navigation must be operable. For example, through complete keyboard control.

Understandable: 

Information and the use of the user interface must be understandable. Text content must be readable and navigation consistently designed.

Robust: 

Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies.

Test environments

Operating systems

  • Apple macOS (latest version)
  • Microsoft Windows (latest version)
  • Apple iOS (latest version)
  • Google Android (latest version)

Linux was not used because it is currently very rarely used by people with disabilities.

Browsers and client software

Used in the latest versions on the listed operating systems:

  • Google Chrome
  • Microsoft Edge (Windows)
  • Safari
  • Adobe Acrobat Reader / Preview on Mac (PDFs only)

Screen readers and assistive technologies

For the most standardized assessment possible, initial testing is carried out without adjustments. For a realistic assessment, the following adjustments are additionally considered:

  • Graphic system adjustments (colors, contrasts, captions, etc.)
  • Mouse emulations, magnification functions, on-screen keyboards, or advanced keyboard settings on all systems
  • VoiceOver – only on Apple systems
  • TalkBack – only on Android systems
  • NVDA (latest version) and Freedom Scientific JAWS (previous version) – only on Windows PCs

Methodology

Manual and semi-automated review with objective methodology

Content is analyzed with various automated and semi-automated tools. The results are compared to ensure the most complete and objective assessment possible. Unless otherwise requested, the standard is always the latest version of WCAG 2.2 to ensure accessibility in all countries from which the touchpoint (website, app, etc.) can be accessed.

Our reviews therefore meet the requirements of WCAG 2.2, Level AA, as well as the specifications of the UNI EN 301 549 standard or its implementation, e.g., the French RGAA.

The results produced by the tools are then reviewed by our experts. Therefore, not all results may be listed—especially if they were classified as false negatives.

Automated tools for syntax checking
  • W3C Markup Validation Service: Validates the generated code (HTML, XHTML, MathML, etc.)
  • W3C CSS Validation Service: While CSS validity does not directly affect accessibility, incorrect interpretation can have an impact.
  • PAC PDF Checker: Tool for checking the accessibility of PDFs
Automated and semi-automated tools for color checking
  • Color Contrast Analyser (CCA): For targeted testing of color contrasts
  • WCAG Color Contrast Checker: Initial check of color contrasts in CSS
  • Text-on-Background-Image A11y Check: Testing text overlay on images
  • Color Contrast Accessibility Evaluator: Additional control for online pages
Automated and semi-automated tools for accessibility testing

Some online validators used as examples on pages:

  • AccessScan
  • WAVE

Other local tools:

  • Web Developer Toolbar: Supports manual review (e.g., missing ALT texts, fields without labels)
  • AXE & Lighthouse for Chrome: Provide precise hints on HTML errors and WAI-ARIA attributes (important for web applications and interactive elements)

Definitions

The terms used in the “Conformance level” section are defined as follows:

Conformant: The functionality of the product meets the criterion without known errors or meets it with equivalent facilitation.

Partially conformant: Some functions of the product do not meet the criterion.

Non-conformant: Most of the product functions do not meet the criterion.

Not applicable: The criterion is not relevant for the product.

Not evaluated: The product has not been evaluated against this criterion. (This is only permitted for WCAG Level AAA criteria.)