Accessibility compliance statement for ryzon.net

Last updated: 05/01/2026

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:

Perceptible

• There are no pre-recorded audio or video clips without alternatives.
• There are no pre-recorded videos without captions.
• For synchronized media, descriptions or alternative versions are provided when required.
• Audio descriptions are available for every video that requires them.
• Instructions for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual position, orientation, or sound.
• The content adapts correctly to screen orientation, while maintaining consistent presentation and functionality.
• The content is scalable, allowing users to adjust text size individually without the user interface losing functionality.
• Information is presented in text form, avoiding unnecessary and non-adjustable text images.
• Changes to text spacing (such as line height, spacing between paragraphs, letters, or words) do not result in the loss of information or content.

Operable

• There are no keyboard traps (free navigation to and from all components is possible).
• There is no interference with keyboard shortcuts consisting of individual letters, numbers, or symbols.
• No time limits dictated by the content are enforced; if present, they are controllable, adjustable, extendable, or subject to functional or legal restrictions.
• There is no conflict with keyboard shortcuts consisting of single letters, numbers, or symbols.
• No time limits dictated by the content are enforced; if present, they are controllable, adjustable, or extendable by the user, or justified by functional or legal requirements.
• No flashing or flickering content that could trigger seizures is used; safety thresholds are adhered to.
• The screens in the service flow have titles that describe their topic or purpose.
• There are multiple ways to identify content within the environment.
• Headings and labels provide clear information about content and functionality.
• Elements that can receive the focus during keyboard navigation are always at least partially visible in the viewport.
• All functions can be used without complex gestures.
• Functions are not activated immediately upon touch; they can be canceled before execution and do not need to be pressed to function.
• All functions can be used without having to rely exclusively on the movement of the device or the user.
• All functions can be used without dragging gestures.
• The clickable area of interactive elements is large enough to ensure easy interaction for users.

Understandable

• The language of each page is correctly set and used consistently throughout the service
• User interface components do not trigger unexpected context changes when the keyboard focus is acquired, which could confuse users.
• User interface components do not trigger unexpected context changes when activated by users via keyboard or assistive technologies that could lead to confusion.
• The existing navigation mechanisms are consistently positioned throughout the service
• Recurring user interface elements are designed uniformly to facilitate their recognition
• The mechanisms for requesting support or help are consistent throughout the environment.
• If an input error is automatically detected, the erroneous element is identified and the error is described in text form.
• Systems are in place to prevent errors, such as confirmation, cancellation, or undoing of sensitive actions.
• Where possible, we avoid requesting the same data multiple times.
• Where available, accessible alternatives exist for complex authentication systems.
• We write content in clear and simple language.

Robust

• We use standardized development technologies that can be interpreted by assistive technologies

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

Chapter 6: ICT with Two-Way Voice Communication

Chapter 7: ICT with video capabilities

Chapter 8: Hardware

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

According to WCAG 2.2 Conformance Level A

Criteria	Conformance Level	Notes and Explanations
1.1.1 Non-text Content	Partially Conformant	For some non-text content presented to you, there is no text alternative that serves the equivalent purpose;
1.2.1 Audio-only and Video-only (Prerecorded)	Conformant
1.2.2 Captions (Prerecorded)	Conformant
1.2.3 Audio Description or Media Alternative (Prerecorded)	Conformant
1.3.1 Info and Relationships	Partially Conformant	In some cases, information, structure, or relationships conveyed through the presentation of pages cannot be programmatically determined (or are not available in text);
1.3.2 Meaningful Sequence	Partially Conformant	In some cases where the sequence in which content is presented affects its meaning, this is conveyed visually only and not structurally;
1.3.3 Sensory Characteristics	Conformant
1.4.1 Use of Color	Partially Conformant	In some cases, color alone has been used to convey a purpose or to distinguish information or a function;
1.4.2 Audio Control	Conformant
2.1.1 Keyboard	Partially Conformant	Some features cannot be activated via the keyboard (or a similar input interface);
2.1.2 No Keyboard Trap	Conformant
2.1.4 Character Key Shortcuts	Conformant
2.2.1 Timing Adjustable	Conformant
2.2.2 Pause, Stop, Hide	Partially Conformant	Some animations, blinking, scrolling, or auto-updating content starts automatically, lasts more than five seconds, or is presented alongside other content, with no mechanism to pause or hide it;
2.3.1 Three Flashes or Below Threshold	Conformant
2.4.1 Bypass Blocks	Partially Conformant	There is no mechanism to skip blocks of content that are repeated across multiple web pages;
2.4.2 Page Titled	Conformant
2.4.3 Focus Order	Partially Conformant	On some web pages that can be navigated sequentially and where the navigation order affects meaning and operation, some focusable components do not receive focus in an order that preserves their meaning and operability;
2.4.4 Link Purpose (In Context)	Partially Conformant	The purpose of certain links cannot be determined from the link text alone or from the link text together with its surrounding content;
2.5.1 Pointer Gestures	Conformant
2.5.2 Pointer Cancellation	Conformant
2.5.3 Label in Name	Partially Conformant	For some user interface components with labels that include text or images of text, the accessible name read by assistive technologies does not contain the text that is visually presented;
2.5.4 Motion Actuation	Conformant
3.1.1 Language of Page	Conformant
3.2.1 On Focus	Conformant
3.2.2 On Input	Conformant
3.2.6 Consistent Help	Conformant
3.3.1 Error Identification	Conformant
3.3.2 Labels or Instructions	Partially Conformant	In some cases, labels or instructions are not provided when content requires user input;
3.3.7 Accessible Authentication (Minimum)	Conformant
4.1.1 Parsing	Conformant
4.1.2 Name, Role, Value	Partially Conformant	In some cases, user interface components (including: form elements, links, and script-generated components...), the name, role, state, properties, and values are not correctly set or not set at all, or the user and their assistive technologies are not notified when these change;

According to WCAG 2.2 Conformance Level AA

Criteria	Conformance Level	Notes and Explanations
1.2.4 Captions (Live)	Conformant
1.2.5 Audio Description (Prerecorded)	Conformant
1.3.4 Orientation	Conformant
1.3.5 Identify Input Purpose	Partially Conformant	The purpose of certain input fields that accept specific data is not correctly communicated to the user or has not been correctly implemented;
1.4.3 Contrast (Minimum)	Partially Conformant	The visual presentation of text and images of text does not always meet the required minimum contrast ratio, apart from the exceptions provided in the regulations (e.g. logos);
1.4.4 Resize Text	Conformant
1.4.5 Images of Text	Conformant
1.4.10 Reflow	Partially Conformant	Content that does not require two-dimensional layout (e.g. data tables or maps) is not reflowed when resized;
1.4.11 Non-text Contrast	Partially Conformant	For some essential components, even in various states, the color contrast compared to adjacent elements does not exceed a ratio of 3:1;
1.4.12 Text Spacing	Conformant
1.4.13 Content on Hover or Focus	Partially Conformant	In some cases where hover or keyboard focus triggers content to appear and disappear, there is no mechanism to dismiss the additional content without moving the pointer or keyboard focus, the pointer cannot be moved over the additional content without it disappearing, or the additional content remains visible until the hover or focus event is removed, the user dismisses it, or its information is no longer valid, except in certain exceptional cases;
2.4.5 Multiple Ways	Conformant
2.4.6 Headings and Labels	Conformant
2.4.7 Focus Visible	Partially Conformant	For some interactive elements, the focus indicator is not visible;
2.4.11 Focus Not Obscured (Minimum)	Conformant
2.5.7 Dragging Movements	Conformant
2.5.8 Target Size (Minimum)	Conformant
3.1.2 Language of Parts	Partially Conformant	In some cases where passages of text are written in a different language, this is not indicated in the code;
3.2.3 Consistent Navigation	Conformant
3.2.4 Consistent Identification	Conformant
3.3.3 Error Suggestion	Partially Conformant	If an input error is detected and suggestions for correction are available, they are not communicated to the user, unless provided for in the regulations;
3.3.4 Error Prevention (Legal, Financial, Data)	Conformant
3.3.8 Accessible Authentication (Minimum)	Conformant

Chapter 10: Non-web documents

Chapter 11: General

Chapter 12: Documentation and support services

Chapter 13: ICT with access to relay or emergency services

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.)