Description of the digital accessibility criteria outlined in the declaration

This chapter presents a list of user interface elements and functional solutions. They have been evaluated for compliance with the accessibility requirements specified in the Web Content Accessibility Guidelines (WCAG) version 2.1 at levels A and AA, which expand upon WCAG version 2.0. Each listed item corresponds to a specific WCAG success criterion and relates to commonly used components or behaviours found on websites. The purpose of the list is to ensure transparency regarding compliance with the European Accessibility Act and to identify key aspects that impact the digital accessibility of websites.

All images, icons, and graphical buttons have alternative text describing their meaning or function. In cases where the graphics are decorative, they have been properly marked as such [1.1.1].
Audio-only recordings (e.g., voice messages) or video-only recordings (e.g., instructional videos) have an alternative version in the form of text describing their content. [1.2.1]
Video materials have captions that reflect the spoken content and important background sounds. [1.2.2]
Multimedia content provides alternative versions in the form of audio description for blind users. [1.2.3, 1.2.5]
The structure of the website/application and the layout of the content are logical and enable understanding of the relationships between pieces of information. [1.3.1]
The order of interface elements and content as read by assistive technologies matches the visual order. [1.3.2]
Instructions for use do not rely solely on shape, colour, position, or sound. [1.3.3]
The application functions correctly in both portrait and landscape orientation. [1.3.4]
Form fields and other interactive elements are properly labelled and described using semantic attributes. [1.3.5]
Colour is not the only means of conveying information; for example, errors are not indicated solely by the colour red. [1.4.1]
Sound is not played automatically, or there is an option to stop or mute it immediately. [1.4.2]
Text and its background maintain a minimum contrast of 4.5:1 or 3:1 (for large text), ensuring readability for people with low vision and/or colour blindness. [1.4.3]
Content can be read at up to 200% zoom without loss of functionality. [1.4.4]
Actual text, scalable and accessible to screen readers, is used instead of images containing text. [1.4.5]
The application or website does not require scrolling in two directions on mobile devices at typical zoom levels. [1.4.10]
Icons, interface components, and other non-text content have a contrast of at least 3:1 against the background. [1.4.11]
The user can increase spacing between lines, paragraphs, and words without loss of functionality or content. [1.4.12]
Elements that appear on focus or hover can be easily accessed and closed by the user. [1.4.13]
The entire application is fully operable using only the keyboard, without the need for a mouse. [2.1.1]
There are no keyboard traps — the user can leave any element using the keyboard. [2.1.2]
Single-key keyboard shortcuts (if present) can be disabled or modified. [2.1.4]
The user can extend or disable session time limits unless required for security reasons. [2.2.1]
Moving banners, carousels, and updating content can be paused or hidden. [2.2.2]
The application does not contain elements that flash more than three times per second, which could trigger epileptic seizures. [2.3.1]
The user can skip repeated blocks of content, e.g., main navigation. [2.4.1]
Screen and view titles clearly indicate their content and purpose. [2.4.2]
Keyboard navigation occurs in a logical, intuitive order. [2.4.3]
Links and buttons are described so their purpose is clear, even out of context. [2.4.4]
The user can reach content in more than one way (e.g., search, menu, sitemap). [2.4.5]
Section headings and labels are understandable and accurately describe their purpose. [2.4.6]
Keyboard focus is always visible and well indicated. [2.4.7]
All functions are accessible without complex gestures, such as double-tapping or three-finger dragging. [2.5.1]
Any action requiring confirmation can be undone or cancelled before it is carried out. [2.5.2]
Interactive elements have text labels matching the name recognized by screen readers. [2.5.3]
Device control via motion (e.g., shaking) is not the only way to perform an action. [2.5.4]
The primary language of the application content is clearly specified in the code. [3.1.1]
Content segments in a language different from the default are properly marked. [3.1.2] (Here: individual issues)
Moving focus to an element does not cause unexpected changes, such as automatic page reloads. [3.2.1]
Changing data in a form does not change context without warning. [3.2.2]
Navigation mechanisms that repeat are presented in the same order on all screens. [3.2.3]
The same interface components (e.g., buttons) are identified consistently on every page. [3.2.4]
Form fields that contain errors are clearly marked and described. [3.3.1]
Fields and controls have understandable labels and instructions to assist in filling them out. [3.3.2]
The user receives suggestions for correcting entered erroneous data. [3.3.3]
The user has the ability to review, correct, and confirm data before submitting it. [3.3.4]
The application code is syntactically correct, allowing proper interpretation by assistive technologies. [4.1.1]
Interface elements have defined roles, names, and values that are accessible to screen readers. [4.1.2]
Status, error, and success messages are communicated in an accessible manner. [4.1.3]

InPost Italia is committed to provide its users with the best possible digital experience. However, we acknowledge that our websites https://www.inpost.it/ and www.resi.inpost.it do not yet fully meet the WCAG 2.2 criteria and that some of their content may not be fully compliant with accessibility standards.

We are actively working to make our websites fully accessible by implementing the necessary changes to address any remaining issues that do not yet meet the required standard.

Current state of digital accessibility for our website inpost.it

Our website inpost.it is accessible to people with disabilities; the detailed scope of fulfilled WCAG criteria is listed below.

Most images, icons, and graphical buttons have alternative text describing their meaning or function. In cases where the graphics are decorative, they have been properly marked as such. 1.1.1].
Multimedia content provides alternative versions in the form of audio description for blind users. [1.2.3, 1.2.5]
The order of interface elements and content as read by assistive technologies matches the visual order. [1.3.2]
Instructions for use do not rely solely on shape, colour, position, or sound. [1.3.3]
The application functions correctly in both portrait and landscape orientation. [1.3.4]
Most icons, interface components, and other non-text content have a contrast of at least 3:1 against the background. [1.4.11]
Elements that appear on focus or hover can be easily accessed and closed by the user. [1.4.13]
There are no keyboard traps — the user can leave any element using the keyboard. [2.1.2]
Moving banners, carousels, and updating content can be paused or hidden. A permanent stop option is not yet available for such elements. [2.2.2]
The application does not contain elements that flash more than three times per second, which could trigger epileptic seizures. [2.3.1]
The user can skip repeated blocks of content, e.g., main navigation. [2.4.1]
Screen and view titles clearly indicate their content and purpose. [2.4.2]
The user can reach content in more than one way (e.g., search, menu, sitemap). [2.4.5]
Any action requiring confirmation can be undone or cancelled before it is carried out. [2.5.2]
Most interactive elements have text labels matching the name recognized by screen readers. 2.5.3]
The primary language of the application content is clearly specified in the code. [3.1.1]
Navigation mechanisms that repeat are presented in the same order on all screens. [3.2.3]
The same interface components (e.g., buttons) are identified consistently on every page. [3.2.4]
Most fields and controls have understandable labels and instructions to assist in filling them out. [3.3.2]
Status, error, and success messages are communicated in an accessible manner. [4.1.3]

Current state of digital accessibility for our website resi.inpost.it

Our website resi.inpost.it is accessible to people with disabilities; the detailed scope of fulfilled WCAG criteria is listed below.

The order of interface elements and content as read by assistive technologies matches the visual order. [1.3.2]
Instructions for use do not rely solely on shape, colour, position, or sound. [1.3.3]
The application functions correctly in both portrait and landscape orientation. [1.3.4]
Form fields and other interactive elements are properly labelled and described using semantic attributes. [1.3.5]
Colour is not the only means of conveying information; for example, errors are not indicated solely by the colour red. [1.4.1]
Content can be read at up to 200% zoom without loss of functionality. [1.4.4]
The application or website does not require scrolling in two directions on mobile devices at typical zoom levels. [1.4.10]
The user can increase spacing between lines, paragraphs, and words without loss of functionality or content. [1.4.12]
Elements that appear on focus or hover can be easily accessed and closed by the user. [1.4.13]
There are no keyboard traps — the user can leave any element using the keyboard. [2.1.2]
The application does not contain elements that flash more than three times per second, which could trigger epileptic seizures. [2.3.1]
Keyboard navigation occurs in a logical, intuitive order. [2.4.3]
Interactive elements have text labels matching the name recognized by screen readers. [2.5.3]
The primary language of the application content is clearly specified in the code. [3.1.1]
Content segments in a language different from the default are properly marked. [3.1.2]
Moving focus to an element does not cause unexpected changes, such as automatic page reloads. [3.2.1]
Navigation mechanisms that repeat are presented in the same order on all screens. [3.2.3]
The same interface components (e.g., buttons) are identified consistently on every page. [3.2.4]
The user receives suggestions for correcting entered erroneous data. [3.3.3]

Contact regarding accessibility

You can contact us:

- electronically: by email [email protected]

Complaints about lack of accessibility

If you have questions about the accessibility of our services or notice a lack of accessibility, please let us know. You can do this email. We will respond to your inquiry and do our best to find a solution accessible to you.

You can also file a complaint about the lack of accessibility of our services.

How to file a complaint?

In the complaint, you must include:

- Your first and last name,
- Your mailing address, email address, or phone number, and your preferred contact method,
- The name of the service or product the complaint concerns, along with a detailed description of the barrier that hinders or prevents accessibility,
- Your request for us to ensure the accessibility of the service or product.

When we will review your complaint?

We will review the complaint as quickly as possible – [email protected] from the date of receipt.
If the complaint regarding accessibility concerns a particularly complex case, we may respond later. In such a case, we will send information about:

- the reason for the delay,
- the expected date by which we plan to review the complaint and provide a response (this deadline will not exceed 60 calendar days from the date the complaint was received).

When will we send our response?

We will deliver our response through the channel you specify in the complaint.

This accessibility statement was created on June 26, 2025.