ACCESSIBILITY STATEMENT

Introduction

 

We want everyone, including people with disabilities, to use our service easily. This document explains what we do to make it accessible and compliant with laws and standards such as the European Accessibility Act and the WCAG.

SCARPA is committed to accessibility and inclusivity. We want all our customers, including people with disabilities, to successfully use our service.

This document describes the accessibility features of https://scarpa.com, how we meet the requirements of the European Accessibility Act, EN 301 549, WCAG 2.2, the ADA and Section 508, and what we are doing to maintain and improve accessibility. This statement covers only https://scarpa.com

We review this information regularly as we improve https://scarpa.com

Overview

 

Service description

The site provides an online retail service, allowing users to browse the catalog, manage the shopping cart, and complete purchases via the e‑commerce platform.

 

How to use https://scarpa.com (Accessibility & Operability)

We strive to make https://scarpa.com simple for everyone. Here is an overview of how to navigate and use our service when assistive technologies or special configurations are used:

 

How to use https://scarpa.com

The service is accessible via a web interface from the main menu, which lets users navigate among product categories. Users can open product pages, add items to the cart, and complete the purchase through the guided checkout.
Customer support is available through the Contacts section of the site.

 

Accessibility of https://scarpa.com

The site uses the standard modes of interaction provided by the operating system and assistive technologies.

If you need additional explanations on using any part of https://scarpa.com, please contact our support team for personalized assistance. We aim to provide any further descriptions or explanations necessary for the correct use of the service.

 

 

Accessibility conformance 

(How we meet the requirements)

 

We evaluated https://scarpa.com against the requirements of the European Accessibility Act (and any applicable local implementation), the ADA, WCAG 2.2, and Section 508, and it is:

 

Perceivable

• No pre‑recorded video lacks captions.

• No synchronized media that requires it lacks descriptions or alternative versions.

• No video that requires it lacks audio description.

• Content is presented in an order that reflects logical and semantic structure, enabling assistive technologies to interpret it correctly.

• Instructions for understanding and operating content do not rely solely on sensory characteristics such as shape, color, size, visual location, orientation, or sound.

• Content adapts correctly to screen orientation, maintaining consistent display and operation.

• Where present, the purpose of input fields that accept specific data is correctly conveyed to assistive technologies and implemented accordingly.

• Content is adaptable, allowing users to customize text size while maintaining a fully usable interface.

• Content that does not require a two‑dimensional layout reflows correctly when the user agent’s viewport changes.

• Adjusting text spacing (line height, paragraph spacing, letter or word spacing) does not cause loss of content or functionality.

 

Operable

• No keyboard traps are present (it is possible to navigate freely into and out of all components).

• There is no interference with single‑character keyboard shortcuts (letters, numbers, or symbols).

• No time limits are imposed by content, or if present they are user‑controllable, adjustable, extendable, or justified by functional or regulatory needs.

• All moving content, if present, includes controls to pause and/or control playback.

• No flashing or blinking content at levels that could trigger seizures; content remains within safety limits.

• Skip links are implemented to allow quick navigation to the main content, improving accessibility and UX.

• Pages within the service flow have titles that describe their topic or purpose.

• In sequences where navigation order affects meaning or operation, focusable objects receive focus in an order that preserves meaning and operability.

• The purpose of links can be determined from the link text itself or from its context with adjacent content.

• Multiple ways exist to locate content within the environment.

• Headings and labels clarify content and functionality.

• The keyboard focus indicator is visible on all interactive elements.

• Elements that can receive keyboard focus are always at least partially visible within the viewport.

• No complex gestures are required to use any functionality.

• Functionalities do not trigger immediately on touch; they can be canceled before completion and do not require press‑and‑hold to operate.

• For UI components with labels that include text or images of text, the accessible name includes the text presented visually.

• All features are usable without relying solely on device or user motion.

• All features are usable without requiring drag gestures.

• Click/touch targets are sufficiently large to ensure comfortable interaction.

 

Understandable

• The language of each page is correctly defined and used consistently throughout the service.

• All language parts that require it can be determined programmatically.

• When keyboard focus moves to UI components, no unexpected context changes occur that could disorient the user.

• When UI components are activated via keyboard or assistive technologies, no unexpected context changes occur that could disorient the user.

• Navigation mechanisms are placed consistently throughout the service flow.

• Repeated interface elements are defined consistently to make them easy to identify.

• Within the environment, help/support request mechanisms are consistent.

• When an input error is automatically detected, the error is identified and described with text.

• When an input error is identified and suggestions are known, those suggestions are provided unless prohibited by regulations.

• Mechanisms are in place to prevent errors, such as confirmation, undo, or reversibility for sensitive actions.

• Where possible, users are not asked to provide the same data more than once.

• When present, complex authentication systems have accessible alternatives.

• We write content in clear and simple language.

 

Robust

• We use standard development technologies that can be interpreted by assistive technologies.

 

We have tested https://scarpa.com with common assistive technologies across a wide range of OS–browser configurations:

• Screen readers (such as NVDA and JAWS on Windows, VoiceOver on Mac and iOS) to confirm that all interactive elements are announced correctly and are operable.

• We also test screen magnification and high‑contrast modes.

 

We aim for compatibility with current versions of major assistive technologies. Our code follows best practices outlined in WCAG 2.2 and EN 301 549 for robust implementation, which means it should remain accessible as technology evolves.

Standards. Based on the above, we apply the latest WCAG 2.2 AA and EN 301 549 criteria to ensure accessibility. Compliance with these standards creates a presumption of conformity with EAA, ADA, and other regulations based on the same technical standards.

 

Continuous monitoring and maintenance

 

Accessibility is not a one‑time effort, but an ongoing process. Here is how we ensure https://scarpa.com remains accessible over time:

 

• Our accessibility coordinator, who oversees the accessibility of https://scarpa.com can be reached at accessibility@scarpa.net

• With AccessiWay’s support, on October 10, 2025 we conducted an external expert‑led manual audit to verify our accessibility compliance. We maintain a cycle of continuous testing and improvements, with recurring support to ensure comprehensive audits— including manual testing by professionals using assistive technologies—at least once a year.

• We use automated testing tools integrated into our development process to promptly identify common accessibility issues (such as missing alt text or form labeling). Each code update passes through these checks.

 

 

Feedback and contacts

 

We welcome your suggestions to make https://scarpa.com better. If you find issues or have suggestions, contact us by email, phone, or mail. Please explain the problem in detail so we can assist you.

We value user feedback, especially when you tell us something isn’t working. If you have difficulty accessing any part of https://scarpa.com encounter an accessibility issue, or have suggestions for improvement, please let us know.

Email: accessibility@scarpa.net

Company address: Calzaturificio SCARPA — Viale Enrico Fermi 1, 31011 Asolo (TV), Italy

When you contact us, please include as many details as possible (which page or feature, what happened, and which assistive technology you used, if any). We will strive to acknowledge your feedback within 15 business days and will do our best to resolve the issue quickly or keep you informed of progress.

Enforcement. If you believe your accessibility concerns have not been properly addressed, you have the right to escalate your complaint. We sincerely hope to resolve any issues with you before it reaches that stage.

Document history. This document was last reviewed and updated on October 10, 2025. We plan to review it at least annually, or whenever significant changes to the service occur.

 

EN 301 549 — Technical report

 

Chapter 5: General requirements

 

 

 

 

Chapter 6: ICT with two‑way voice communication

 

 

 

Chapter 7: ICT with video functionality

 

 

 

Chapter 8: Hardware

 

 

 

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

 

Corresponding to WCAG 2.2 Level A

Corresponding to WCAG 2.2 Level AA

 

Criteria	Conformance level(s)	Notes
1.2.5 Audio Description (Pre‑recorded)	Supported
1.3.4 Orientation	Supported
1.3.5 Identify Input Purpose	Supported
1.4.3 Contrast (Minimum)	Partially supported	The visual presentation of text and images of text does not always meet the minimum contrast ratio, except where allowed (e.g., logos).
1.4.4 Resize Text	Supported
1.4.5 Images of Text	Partially supported	In some cases images of text are used instead of text alone and are neither customizable nor essential to the information conveyed.
1.4.10 Reflow	Supported
1.4.11 Non‑text Contrast	Partially supported	For some essential components, including in different states, the contrast with adjacent colors does not exceed 3:1.
1.4.12 Text Spacing	Supported
1.4.13 Content on Hover or Focus	Partially supported	In some cases where hover or keyboard focus shows/hides content, there is no mechanism to dismiss the additional content without moving pointer/focus; the pointer cannot be moved onto the additional content without it disappearing; or the content does not remain visible until hover/focus is removed, the user dismisses it, or it becomes irrelevant (with standard exceptions).
2.4.5 Differenti modalità	Supported
2.4.6 Intestazioni ed etichette	Supported
2.4.7 Focus visibile	Supported
2.4.11 Focus Not Obscured (Minimum)	Supported
2.5.7 Dragging Movements	Supported
2.5.8 Target Size (Minimum)	Supported
3.1.2 Language of Parts	Supported
3.2.3 Consistent Navigation	Supported
3.2.4 Consistent Identification	Supported
3.3.3 Error Suggestions	Supported
3.3.4 Error Prevention (Legal, Financial, Data)	Supported
3.3.8 Accessible Authentication (Minimum)	Supported
4.1.3 Status Messages	Partially supported	In some cases status messages are not presented so that assistive technologies can interpret them without moving focus.

 

Chapter 10: Non‑web documents

 

 

 

Chapter 11: Software

 

 

 

Chapter 12: Documentation and support services

 

 

 

Chapter 13: ICT that provides relay or access to emergency services

 

Web Accessibility

 

Disability is defined as any limitation of activity or restriction of participation in society experienced by a person as a result of a substantial, long‑lasting, or permanent impairment of one or more physical, sensory, mental, cognitive, or psychological functions, multiple disabilities, or a disabling health condition.

Web accessibility means making online public‑communication services accessible to people with disabilities, based on four fundamental principles:

• Perceivable: Information and UI components must be presented to users in ways they can perceive. For example, providing text alternatives for all non‑text content so it can be rendered in other forms as needed (large print, braille, speech, symbols, or simplified language).

• Operable: User interface components and navigation must be operable. For example, making all functionality available from a keyboard.

• Understandable: Information and operation of the UI must be understandable. Text content should be readable and navigation consistent.

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

• Microsoft Windows (latest)

• Apple iOS (latest)

• Google Android (latest)

We did not use Linux as it is currently little used among users with disabilities.

 

Browsers and user software

(latest versions available across operating systems)

 

• Google Chrome

• Microsoft Edge

• Safari

• Adobe Acrobat Reader / Preview on Mac (for PDFs only)

 

Screen readers and assistive technologies

To ensure the most standard evaluation possible, we test everything with the default configuration of assistive technologies. To make the assessment more realistic, we also test:

• Built‑in visual adaptations across systems (colors, contrast, captions, etc.)

• Mouse emulations, magnifiers, on‑screen keyboards, or advanced keyboard settings across systems

• VoiceOver — Apple platforms only

• TalkBack — Android only

• NVDA (latest) and Freedom Scientific JAWS (previous major version) — Windows only

 

Methodology

 

Objective manual and semi‑automated verification methodology

We analyze content with various automated and semi‑automated systems and compare results across tools to achieve the most complete and objective verification. Unless otherwise requested, we reference the latest standard (WCAG 2.2) to ensure compliance in all countries from which the touchpoint (site, app, etc.) can be accessed.

Our verification therefore conforms to WCAG 2.2 Level AA and the requirements of EN 301 549 or their expression in the French RGAA. Each tool produces results that are then reviewed by our experts; not all tool findings may appear here, where judged false negatives.

 

Automated syntax tools

• W3C Markup Validation Service: official validator for HTML, XHTML, MathML, etc. 

• 3C CSS Validation Service: although CSS correctness does not directly affect accessibility, it can impact related aspects if misinterpreted due to errors. Validation performed at https://jigsaw.w3.org/css-validator/

• AC PDF Checker

 

Automated and semi‑automated color tools

• Color Contrast Analyser (CCA): used selectively for borderline contrasts

• CAG Color contrast checker: first‑pass check for CSS color contrasts in pages

• Text on background image a11y check: validates cases where text overlays images

• Color contrast accessibility evaluator: additional online checks

 

Automated and semi‑automated accessibility tools

• Accescan

• Wave

And other tools:

• Web Developer Toolbar: supports manual verification (finds images without alt text, inputs without labels, etc.) — 

• Axe and Lighthouse for Chrome: provide precise indications on HTML accessibility defects and WAI‑ARIA attributes, essential for web apps and interactive components. 

Terminology

 

Terms used in the Conformance column are defined as follows:

• Supported: The product has at least one method that meets the criterion with no known defects, or meets it with an equivalent facilitation.

• Partially supported: Some product functionality does not meet the criterion.

• Not supported: Most product functionality does not meet the criterion.

• Not applicable: The criterion is not relevant to the product.

• Not evaluated: The product was not evaluated against the criterion. (May be used only for WCAG Level AAA criteria.)