This document presents a technical accessibility evaluation based on the documented checks and stated limitations. Automated checks cover only part of the WCAG criteria and do not replace human evaluation. It is not an EAA certification, a legal assessment, a guarantee of regulatory compliance, or protection against penalties; EAA applicability has not been assessed. The accessibility statement and the compliance of the service remain the responsibility of the owner of the digital service.

Technical accessibility evaluation of the website https://www.actiafleet.com/

ACTIA ITALIA S.R.L.

Reference standard: WCAG 2.1 level AA • Evaluation date: 23/09/2026 • Pages in the sample: 36

WCAG 2.1 AA technical result: PARTIALLY CONFORMING • EAA applicability: not assessed WCAG 2.1 level AA criteria: 17 criteria not satisfied, 10 with no violations detected by the automated tools, 19 satisfied in the manual review, 0 not assessed, 4 not applicable, out of 50.

1. Introduction

Summary for stakeholders and management

Technical quality indicator

63%
Synthetic, non-normative indicator, calculated at scan time as 29 criteria passed (no violations detected or satisfied at the manual check) ÷ 46 applicable criteria assessed.

Urgency of interventions

High
10 issues classified as critical

WCAG criteria not satisfied

17
out of 50 assessed

Recommendations for management:

  • Priority 1: fix first the issues classified as critical (10), which can block access
  • Planning: include in the development roadmap the fix of 17 WCAG criteria not satisfied, listed in this document
  • Training: raise awareness of accessibility principles among the development and content teams
  • Value: accessibility improves the experience for all users

This document is a technical evaluation of the accessibility of the website https://www.actiafleet.com/, carried out with automated tools and with a manual review on the WCAG 2.1 level AA success criteria. Web accessibility is a fundamental right that ensures all people, regardless of their physical, sensory or cognitive abilities, can access information and digital services fairly and without discrimination.

This evaluation is part of the broader inclusive digital transformation promoted by the European Union through Directive (EU) 2019/882, known as the European Accessibility Act (EAA), which sets mandatory accessibility requirements for digital products and services. The analysis presented here identifies the criteria not satisfied and gives guidance for a path of continuous improvement towards full digital accessibility.

The document combines the results of several automated tools, normalized and aggregated, and accompanies them with operational guidance for remediating the issues identified. Each section of the document is designed to be useful both to company management and to the technical teams responsible for implementing the solutions.

1.1 Purpose of the document

This technical accessibility evaluation was generated from analyses carried out with automated validation tools and a manual review. It describes the technical state of the website https://www.actiafleet.com/ against the WCAG 2.1 level AA success criteria checked. Conformance with the EN 301 549 standard and the applicability of the European Accessibility Act (EAA) are not assessed.

1.2 Regulatory framework

The regulatory framework for digital accessibility includes:

European legislation

Italian legislation

1.3 Scope of the audit

The analysis covered the website https://www.actiafleet.com/ and was carried out by checking conformance with the WCAG 2.1 level AA success criteria. The automated audit is an essential baseline for identifying technical issues, but it should be complemented by manual audits and testing with users with disabilities to ensure a complete evaluation.

Languages of the pages in the sample, as declared by the lang attribute of the html element when the pages were identified:

The attribute is read from the served HTML, before scripts run: a language set by a script does not appear here, and the result for WCAG criterion 3.1.1 is the one detected by the automated tools. The list describes the analyzed sample, not the website: the language versions of the website were not enumerated.

2. Metadata

The metadata of this report provide the essential information to put the analysis carried out into context and to trace the evaluation process. These identifying data document the scope and the time of the analysis.

Together, this information identifies the assessed party, the time of the analysis and the tools used, and is the starting point for planning the interventions.

3. Methodology

The methodology adopted for this accessibility evaluation is based on a multi-level approach that combines the most advanced automated testing technologies with analysis protocols established internationally. The coverage of the WCAG 2.1 success criteria is reported in the executive summary, and the list of the criteria not satisfied and not assessed in §5.

The testing architecture uses several specialized scanners at the same time, each optimized to identify specific types of accessibility barriers. This diversity of analysis tools makes it possible to offset the intrinsic limits of each individual scanner.

It is important to stress that, while automation provides a solid basis for systematically identifying technical issues, some aspects of accessibility necessarily require expert human evaluation. For this reason, the results presented in this report must be considered part of a broader evaluation process that includes manual testing with real assistive technologies and, ideally, the direct involvement of users with disabilities in the review.

3.1 Automated tools used

The audit was carried out using the automated tools listed below, each with specific detection capabilities. The criteria not satisfied and not assessed are listed in §5.

Accessibility scanners used:

Aggregation methodology: the results of the tools are normalized into a common format; findings of the same rule of the same tool are grouped, including across different pages, and their instances added up. There is no deduplication across different tools: the same defect reported by two tools appears twice, and the occurrences by criterion add up the reports of all the tools. Violations are the findings that demonstrate a failure of a WCAG 2.1 A/AA criterion; the others are findings to be verified.

3.2 Sampling criteria

The sample consists of the pages listed below, chosen for this evaluation.

The sample of this evaluation includes 36 pages of the website. The sample is not representative by construction: its size is the one requested for the scan, and the coverage of the website as a whole is not measured. The pages of the sample are:

The pages of the sample were chosen by whoever carried out the evaluation, among those identified automatically or added manually. The system does not check that the sample includes all page templates, the interactive features or the complete processes of the website.

3.3 Methodological note

Important: This automated analysis provides an objective and reproducible evaluation of the technical issues that can be detected automatically. However, some aspects of accessibility require human evaluation and testing with real users. This document should therefore be considered part of a broader evaluation process that includes manual audits and testing with assistive technologies.

4. Executive summary

Technical evaluation outcome

29
WCAG criteria with no violations detected or satisfied
8
Critical Violations
4
Contrasts
1
Images

Evaluation results:

Pages in the sample: 36 — pages identified in the page search: N/D

Technical accessibility evaluation — This document presents a technical accessibility evaluation based on the documented checks and stated limitations. Automated checks cover only part of the WCAG criteria and do not replace human evaluation. It is not an EAA certification, a legal assessment, a guarantee of regulatory compliance, or protection against penalties; EAA applicability has not been assessed. The accessibility statement and the compliance of the service remain the responsibility of the owner of the digital service.

The executive summary is the strategic core of this document, giving an immediate and clear overview of the results of the accessibility audit. This section is specifically designed to give company decision-makers and key stakeholders a quick but complete understanding of the conformance of the website, highlighting the main issues and their potential impact on the experience of users with disabilities.

Business impact and opportunities

Potential user base: In Italy, about 3.1 million people (5.2% of the population) have disabilities that can affect digital access. An accessible website can reach a significantly wider audience.

Business benefits of accessibility:

Risks of non-conformance:

The data presented in this summary come from the aggregation and normalization of the results of the different tools. The technical quality indicator is a synthetic, non-normative value, calculated at scan time as 29 criteria passed (no violations detected or satisfied at the manual check) ÷ 46 applicable criteria assessed. The criteria not satisfied are listed by P.O.U.R. principle in §5.

It is essential to understand that each violation identified is a potential barrier that can prevent or significantly limit access to the content and features of the website for specific groups of users. Remediating these issues is a concrete opportunity to widen the user base, improve the overall experience of the website and show the organization's commitment to digital inclusion.

Technical result on the WCAG 2.1 level AA criteria: PARTIALLY CONFORMING

The applicability of the European Accessibility Act was not assessed. WCAG 2.1 level AA criteria: 17 criteria not satisfied, 10 with no violations detected by the automated tools, 19 satisfied in the manual review, 0 not assessed, 4 not applicable, out of 50. The list is in §5. The evaluation refers to the state of the website on 23/09/2026.

How to read the result: with at least one criterion not satisfied the result is “partially conforming”, whatever the number of criteria not satisfied: full conformance has not yet been reached and remediation is needed.

The automated tools detected 30 violations of WCAG 2.1 A/AA criteria (4916 instances across all pages) and 38 findings to be verified (11064 instances), which do not demonstrate the failure of a criterion. The issues classified as critical by the tools are 10 (2 among the findings to be verified).

63% Technical quality indicator
30 Violations (4916 instances; 38 findings to be verified)
10 Critical (2 among the findings)
4/4 Principles with criteria not satisfied
2398 Automated checks passed
50/50 WCAG criteria Coverage 100.0%

5. Detailed results by P.O.U.R. principle

The detailed analysis according to the P.O.U.R. principles (Perceivable, Operable, Understandable, Robust) is the conceptual and operational framework through which the Web Content Accessibility Guidelines structure the requirements of digital accessibility. This section presents an in-depth and systematic analysis of how the website stands against each of these four fundamental pillars, showing for each principle which criteria are not satisfied.

Each P.O.U.R. principle is a critical dimension of accessibility that meets specific needs of users with disabilities. The Perceivable principle ensures that information is presented in ways that can be perceived through different senses; Operable ensures that all features can be used regardless of the input device; Understandable requires information and operations to be clear and intuitive; Robust ensures compatibility with current and future assistive technologies.

Because these principles depend on each other, a failure in a single area can compromise the whole accessibility experience. For each principle the WCAG 2.1 level AA criteria not satisfied are reported, with the number of those with no violations detected by the automated tools and the list of those not assessed.

5.1 Perceivable

Criteria of the principle: 20 — not satisfied: 11; with no violations detected by the automated tools: 2; satisfied in the manual review: 5; not assessed: 0; not applicable: 2.

Criteria not satisfied — Perceivable
Criterion Name Level
1.1.1Non-text ContentA
1.2.3Audio Description or Media Alternative (Prerecorded)A
1.2.5Audio Description (Prerecorded)AA
1.3.1Info and RelationshipsA
1.3.5Identify Input PurposeAA
1.4.1Use of ColorA
1.4.3Contrast (Minimum)AA
1.4.4Resize TextAA
1.4.10ReflowAA
1.4.11Non-text ContrastAA
1.4.12Text SpacingAA

5.2 Operable

Criteria of the principle: 17 — not satisfied: 4; with no violations detected by the automated tools: 5; satisfied in the manual review: 7; not assessed: 0; not applicable: 1.

Criteria not satisfied — Operable
Criterion Name Level
2.1.1KeyboardA
2.4.4Link Purpose (In Context)A
2.4.7Focus VisibleAA
2.5.3Label in NameA

5.3 Understandable

Criteria of the principle: 10 — not satisfied: 1; with no violations detected by the automated tools: 2; satisfied in the manual review: 6; not assessed: 0; not applicable: 1.

Criteria not satisfied — Understandable
Criterion Name Level
3.1.2Language of PartsAA

5.4 Robust

Criteria of the principle: 3 — not satisfied: 1; with no violations detected by the automated tools: 1; satisfied in the manual review: 1; not assessed: 0.

Criteria not satisfied — Robust
Criterion Name Level
4.1.2Name, Role, ValueA

6. Remediation recommendations

The recommendations in this section are a structured and prioritized operational roadmap for overcoming the issues detected here. The plan that follows is a general model by priority phase: the figures of each phase come from this evaluation, timeframes and skills are indicative.

The proposed remediation strategy follows an incremental and sustainable approach that makes it possible to achieve tangible improvements in the short term while working towards full conformance in the medium to long term. For each phase the plan indicates approximate timeframes and required skills, to support operational planning and resource allocation.

It is important to stress that accessibility remediation should not be regarded as an isolated project with a fixed end date, but rather as a continuous process integrated into the development and maintenance cycle of the website. Automated checking processes, staff training and accessible development practices from the design stage onwards are essential to maintain the standards reached and to prevent new accessibility barriers from being introduced.

6.1 Priority interventions (critical)

10 issues classified as critical were detected: they should be fixed first.

6.2 Structured intervention plan

Table 6.2: Remediation plan by priority
Phase Priority Interventions Approximate timeframe Required skills
Phase 1 Critical Resolution of blocking issues (10 issues) 1-2 weeks Senior frontend developer
Phase 2 High Fixing high-impact issues (47 issues) 2-3 weeks Development team
Phase 3 Medium Optimizations and improvements (9 issues) 3-4 weeks Development team + UX designer
Phase 4 Low Refinements and best practices (2 issues) Ongoing The whole team

The timeframes are indicative: they do not come from an estimate made on this website.

6.3 Guidelines for the team

For the development team:

For the content team:

General best practices:

7. Publishable statement

This evaluation describes the technical state of the website. The statement that the party publishes externally is a separate document, whose content depends on the legislation that applies to the party: the model is downloaded separately, and is generated only when the regime has been declared.

The model leaves to be completed the data that belong to the party and that a technical review cannot establish: who responds to reports, within what time, the outcome of any disproportionate burden assessment and the date of signature.

8. Appendices

The technical appendices that close this report provide essential reference material for an in-depth understanding and the practical implementation of the recommendations presented. This section collects operational resources, technical glossaries and implementation guidelines that form a complete toolkit for the development and maintenance teams responsible for remediating the issues identified.

The material presented here is general reference, based on the established best practices of the international accessible web development community: it is not specific to the issues of this website, whose criteria not satisfied are listed in §5.

This technical documentation also serves as a training resource for the organization's technical staff, helping to build in-house skills in digital accessibility. Investing in the training and awareness of the development team is in fact one of the key elements to ensure that accessibility becomes an integral part of the company culture and of the development processes, rather than a requirement added at the final review.

8.1 WCAG glossary and P.O.U.R. principles

Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
Operable
User interface components and navigation must be operable.
Understandable
Information and the operation of the user interface must be understandable.
Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

8.2 Glossary of the most frequent WCAG criteria

As general reference, some of the WCAG 2.1 criteria most often violated on the web and their importance for accessibility. The list does not concern this website: its criteria not satisfied are in §5.

Table 8.2: WCAG criteria most often violated on the web (general reference)
Criterion Name Level Description
1.1.1 Non-text Content A All non-text content presented to the user has a text alternative that serves the equivalent purpose.
1.3.1 Info and Relationships A Information, structure and relationships conveyed through presentation can be programmatically determined.
1.4.3 Contrast (Minimum) AA The visual presentation of text has a contrast ratio of at least 4.5:1 (3:1 for large text).
2.1.1 Keyboard A All functionality of the content is operable through a keyboard interface.
2.4.1 Bypass Blocks A A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
2.4.7 Focus Visible AA The keyboard focus indicator is visible during navigation.
3.3.2 Labels or Instructions A Labels or instructions are provided when content requires user input.
4.1.2 Name, Role, Value A For all user interface components, the name and role can be programmatically determined.

Additional details on the criteria:

1.1.1 - Non-text Content (Level A)
All non-text content presented to the user has a text alternative that serves the equivalent purpose, except for specific situations such as decorative content or CAPTCHA. Images must have an alternative description (alt attribute) that conveys the content and function of the image to users with visual impairments.
1.3.1 - Info and Relationships (Level A)
Information, structure and relationships conveyed through presentation can be programmatically determined or are available in text. This ensures that screen readers and other assistive technologies can correctly interpret the structure of the content.
1.4.3 - Contrast (Minimum) (Level AA)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for large text (at least 3:1), decorative text or logos. Sufficient contrast is essential for users with low vision or color blindness.
2.1.1 - Keyboard (Level A)
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. This criterion ensures full access for users who cannot use a mouse.
2.1.2 - No Keyboard Trap (Level A)
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, without requiring specific timings for individual keystrokes.
2.4.1 - Bypass Blocks (Level A)
A mechanism is available to bypass blocks of content that are repeated on multiple web pages. "Skip links" let screen reader users jump directly to the main content, avoiding repetitive navigation.
2.4.2 - Page Titled (Level A)
Web pages have titles that describe topic or purpose. Descriptive titles help users orient themselves and understand the content of the page.
2.4.7 - Focus Visible (Level AA)
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. Users must be able to see which element has focus while navigating with the keyboard.
3.1.1 - Language of Page (Level A)
The default human language of each web page can be programmatically determined. The lang attribute on the HTML element lets screen readers use the correct pronunciation.
3.3.1 - Error Identification (Level A)
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
3.3.2 - Labels or Instructions (Level A)
Labels or instructions are provided when content requires user input. Form fields must be clearly labelled, with instructions and correctly associated labels.
4.1.1 - Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique.
4.1.2 - Name, Role, Value (Level A)
For all user interface components, the name and role can be programmatically determined; states, properties and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

8.3 Best practices by WCAG area

Perceivable:

Operable:

Understandable:

Robust:

8.4 Technical annexes

Recommended checking tools:

Best practices for maintaining accessibility:

9. Revision history

Document revision history with details of changes made.

Document revision history
Date Responsible Type Version Description
23/09/2026 Principi S.r.l. Reissue 1.4 New issue of the documents of the same scan, with the rendering rules in force

The integer part of the number counts the scans of the site (X.0 = X-th scan); the decimal part counts the reissues of the documents of the same scan (X.1, X.2…).