Fourthline SDK Accessibility Statement
Integrations guide
At Fourthline, we believe digital identity should be accessible to everyone. That’s why we’re committed to designing inclusive, user-friendly experiences across all our Software Development Kits (SDKs), whether for web, mobile, or cross-platform environments. This page outlines our current accessibility efforts, conformance levels, testing practices, and how we support business partners in meeting accessibility requirements.
If you're customizing our SDKs or want to understand how we approach accessibility, you’ll find relevant details, standards, and guidance below.
How we approach accessibility
We embed accessibility into the way we design and build, ensuring that our products can be used by people with a wide range of abilities and needs. As part of our efforts, we:
- Aim to meet the Web Content Accessibility Guidelines version 2.2 (WCAG), Level AA across supported platforms.
- Evaluate accessibility through multiple methods, including manual testing and automated scans.
- Share updates on our accessibility status and known limitations with business partners via Release Notes and newsletter.
- Actively listen and respond to feedback from clients who encounter challenges accessing our tools or content.
Fourthline SDK Voluntary Product Accessibility Template (VPAT)
This report is based on version 2.5 of the WCAG VPAT Template created by the Information Technology Industry Council (ITI).
Overview
Product Name: Fourthline SDK (App Drop-in and Web SDK)
Evaluation Date: June 2025
Supported Platforms: Web, iOS (v3.2.8 and later), Android (v3.2.8 and later), Cordova (2.2.8 and later), Flutter (2.2.8 and later), React Native (2.2.8 and later)
Product Description: The Fourthline SDK enables secure digital identity verification through features such as Biometric Authentication, Document Photo, Document Liveness, NFC Authentication, among others.
Contact: Fourthline Customer Success team
Evaluation Methods Used
Fourthline follows industry-recognized accessibility standards to assess its products during development and across the full product lifecycle. Our evaluation approach includes a combination of techniques to ensure inclusive user experiences, including:
- Automated analysis using trusted accessibility tools, such as Axe for .NET.
- Manual testing of key user flows and interface elements, performed by testers familiar with the product's typical user flows and functionality, ensuring assessments reflect real-world usage scenarios.
- Validation is performed using assistive technologies such as screen readers and keyboard navigation tools, for example: JAWS, TalkBack, and VoiceOver.
Applicable Standards/Guidelines
This report covers the degree of conformance with the following accessibility standards and guidelines:
| Standard/Guideline | Included In Report |
|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A: Yes Level AA: Yes Level AAA: No |
| Web Content Accessibility Guidelines 2.1 | Level A: Yes Level AA: Yes Level AAA: No |
| Web Content Accessibility Guidelines 2.2 | Level A: Yes Level AA: Yes Level AAA: No |
Terms
The terms used in the Conformance Level information are defined as follows:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects
or with equivalent facilitation. - Partially Supports: Some product functionality does not meet the criterion.
- Does Not Support: Most product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
- Not Evaluated: The product has not been evaluated against the criterion. This can be used only in WCAG
Level AAA criteria.
WCAG 2.2 Report
Note: When reporting on conformance with the WCAG 2.2 Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported technology use as documented in the WCAG 2.2 Conformance Requirements.
Table 1: Success Criteria, Level A
Notes:
| Criteria | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) | Supports | SDKs provide text alternatives for all non-text content. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Not Applicable | SDKs do not include pre-recorded audio-only or video-only content. |
| 1.2.2 Captions (Prerecorded) (Level A) | Not Applicable | SDKs do not include pre-recorded synchronized media content. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Not Applicable | SDKs do not include pre-recorded video content. |
| 1.3.1 Info and Relationships (Level A) | Supports | SDKs convey presentation information programmatically. |
| 1.3.2 Meaningful Sequence (Level A) | Supports | SDKs present a correct and logical reading sequence for all content. |
| 1.3.3 Sensory Characteristics (Level A) | Supports | SDKs do not rely solely on sensory characteristics to convey instructions. |
| 1.4.1 Use of Color (Level A) | Supports | Color is not the only method used to convey information; links are underlined. |
| 1.4.2 Audio Control (Level A) | Not Applicable | SDKs do not include audio content. |
| 2.1.1 Keyboard (Level A) | Supports | Content is operable through a keyboard interface. |
| 2.1.2 No Keyboard Trap (Level A) | Supports | SDKs do not trap the user's keyboard focus. |
| 2.1.4 Character Key Shortcuts (Level A 2.1 only) | Supports | SDKs do not use character key shortcuts. |
| 2.2.1 Timing Adjustable (Level A) | Not Applicable | Time constraints are necessary due to security requirements. |
| 2.2.2 Pause, Stop, Hide (Level A) | Supports | SDKs do not include any moving, blinking, scrolling, or auto-updating content that lasts more than five seconds. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Not Applicable | SDKs do not include any content that flashes more than three times per second. |
| 2.4.1 Bypass Blocks (Level A) | Not Applicable | This criterion does not apply, as the interface does not include repeated content blocks across multiple web pages. The application uses a single-page interface or maintains a consistent layout without redundant navigation or repeated sections. |
| 2.4.2 Page Titled (Level A) | Supports | All pages have descriptive titles. |
| 2.4.3 Focus Order (Level A) | Supports | SDKs provide a logical focus order for content. |
| 2.4.4 Link Purpose (In Context) (Level A) | Supports | Links have descriptive text. |
| 2.5.1 Pointer Gestures (Level A 2.1 only) | Supports | SDKs support single-finger interaction, eliminating the need to pinch, zoom, or use multiple fingers to navigate or continue. |
| 2.5.2 Pointer Cancellation (Level A 2.1 only) | Supports | Pointer actions can be canceled. |
| 2.5.3 Label in Name (Level A 2.1 only) | Supports | SDKs present labels both visually and programmatically. |
| 2.5.4 Motion Actuation (Level A 2.1 only) | Not Applicable | SDKs do not use motion-based input. |
| 3.1.1 Language of Page (Level A) | Supports | SDKs ensure that the app language is defined by Fourthline. |
| 3.2.1 On Focus (Level A) | Supports | No context change on focus. |
| 3.2.2 On Input (Level A) | Supports | No context change on input. |
| 3.2.6 Consistent Help (Level A) | Not Applicable | Help is consistently available where applicable (e.g., NFC page). |
| 3.3.1 Error Identification (Level A) | Supports | When an input error is identified, the SDK communicates the issue to the user using descriptive text. |
| 3.3.2 Labels or Instructions (Level A) | Supports | User inputs include clear labels and guidance. |
| 3.3.7 Redundant Entry (Level A) | Supports | Users are not asked to enter the same information multiple times. |
| 4.1.1 Parsing (Level A) | Supports | Always supported under WCAG 2.0/2.1. WCAG 2.2 does not apply. |
| 4.1.2 Name, Role, Value (Level A) | Supports | SDKs provide appropriate names, roles, and values for all interactive elements to support assistive technologies |
Table 2: Success Criteria, Level AA
Notes:
| Criteria | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | SDKs do not include any live synchronized media. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | SDKs do not include pre-recorded video content. |
| 1.3.4 Orientation (Level AA 2.1 only) | Not Applicable | Portrait-only mode due to security needs; may affect users with mounted devices. |
| 1.3.5 Identify Input Purpose (Level AA 2.1 only) | Supports | SDKs appropriately identify the purposes of components, icons, and regions to support assistive technologies. |
| 1.4.3 Contrast (Minimum) (Level AA) | Supports | Sufficient contrast between text and background. |
| 1.4.4 Resize text (Level AA) | Supports | Zoom up to 200% supported without loss of content/function. |
| 1.4.5 Images of Text (Level AA) | Not Applicable | SDKs do not use images of text. |
| 1.4.10 Reflow (Level AA 2.1 only) | Not Applicable | Vertical scrolling supported only. |
| 1.4.11 Non-text Contrast (Level AA 2.1 only) | Supports | Minimum 3:1 contrast for UI elements. |
| 1.4.12 Text Spacing (Level AA 2.1 only) | Supports | Text spacing meets WCAG standards. |
| 1.4.13 Content on Hover or Focus (Level AA 2.1 only) | Not Applicable | No hover/focus-triggered content. |
| 2.4.5 Multiple Ways (Level AA) | Not Applicable | SDK does not require multiple ways to locate content. |
| 2.4.6 Headings and Labels (Level AA) | Supports | Headings/labels used to convey purpose. |
| 2.4.7 Focus Visible (Level AA) | Supports | Focus indicators visible on all interactive elements. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA) | Supports | No content is hidden during keyboard focus. |
| 2.5.7 Dragging Movements (Level AA) | Not Applicable | SDKs do not use drag gestures. |
| 2.5.8 Target Size (Minimum) (Level AA) | Supports | Minimum target size of 24x24 pixels enforced. |
| 3.1.2 Language of Parts (Level AA) | Supports | SDKs do not include passages or phrases in a language other than the main language of the page, with two exceptions: • Legal Terms and Conditions must be presented in the language of the country of origin. • QES documents The QES and the Terms and Conditions documents are provided by and are the responsibility of our business partners. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | Navigation is consistent across SDK. |
| 3.2.4 Consistent Identification (Level AA) | Supports | UI components have consistent roles/labels. |
| 3.3.3 Error Suggestion (Level AA) | Supports | Suggestions offered in flows like TIN entry. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Not Applicable | SDKs do not commit users to legal/financial transactions. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only) | Not Applicable | SDKs do not include cognitive function tests, with the following exceptions: • Our Selfie Liveness product requires users to follow visual prompts to move their head in specific directions. • Users with visual or physical impairments may experience challenges when using the Documents or Biometrics modules, as these flows must be completed independently due to privacy and security constraints. |
| 4.1.3 Status Messages (Level AA 2.1 only) | Supports | SDKs present status messages in a way that assistive technologies, such as screen readers, can detect and announce to the user. |
Table 3: Success Criteria, Level AAA
Notes:
| Criteria | Conformance Level |
|---|---|
| 1.2.6 Sign Language (Prerecorded) (Level AAA) | Not Evaluated |
| 1.2.7 Extended Audio Description (Prerecorded) (Level AAA) | Not Evaluated |
| 1.2.8 Media Alternative (Prerecorded) (Level AAA) | Not Evaluated |
| 1.2.9 Audio-only (Live) (Level AAA) | Not Evaluated |
| 1.3.6 Identify Purpose (Level AAA 2.1 and 2.2) | Not Evaluated |
| 1.4.6 Contrast (Enhanced) (Level AAA) | Not Evaluated |
| 1.4.7 Low or No Background Audio (Level AAA) | Not Evaluated |
| 1.4.8 Visual Presentation (Level AAA) | Not Evaluated |
| 1.4.9 Images of Text (No Exception) (Level AAA) | Not Evaluated |
| 2.1.3 Keyboard (No Exception) (Level AAA) | Not Evaluated |
| 2.2.3 No Timing (Level AAA) | Not Evaluated |
| 2.2.4 Interruptions (Level AAA) | Not Evaluated |
| 2.2.5 Re-authenticating (Level AAA) | Not Evaluated |
| 2.2.6 Timeouts (Level AAA 2.1 and 2.2) | Not Evaluated |
| 2.3.2 Three Flashes (Level AAA) | Not Evaluated |
| 2.3.3 Animation from Interactions (Level AAA 2.1 and 2.2) | Not Evaluated |
| 2.4.8 Location (Level AAA) | Not Evaluated |
| 2.4.9 Link Purpose (Link Only) (Level AAA) | Not Evaluated |
| 2.4.10 Section Headings (Level AAA) | Not Evaluated |
| 2.4.12 Focus Not Obscured (Enhanced) (Level AAA 2.2 only) | Not Evaluated |
| 2.4.13 Focus Appearance (Level AAA 2.2 only) | Not Evaluated |
| 2.5.5 Target Size (Level AAA 2.1 and 2.2) | Not Evaluated |
| 2.5.6 Concurrent Input Mechanisms (Level AAA 2.1 and 2.2) | Not Evaluated |
| 3.1.3 Unusual Words (Level AAA) | Not Evaluated |
| 3.1.4 Abbreviations (Level AAA) | Not Evaluated |
| 3.1.5 Reading Level (Level AAA) | Not Evaluated |
| 3.1.6 Pronunciation (Level AAA) | Not Evaluated |
| 3.2.5 Change on Request (Level AAA) | Not Evaluated |
| 3.3.5 Help (Level AAA) | Not Evaluated |
| 3.3.6 Error Prevention (All) (Level AAA) | Not Evaluated |
| 3.3.9 Accessible Authentication (Enhanced) (Level AAA 2.2 only) | Not Evaluated |
Accessibility in custom SDK
Fourthline’s SDK (App Drop-in and Web SDK) is designed with accessibility in mind. To support compliance with WCAG, our default color palette has been optimized to meet the following key criteria:
- 1.4.3 Contrast (Minimum): Ensures sufficient contrast between text and background for readability.
- 1.4.1 Use of Color: Ensures that color is not the sole method for conveying information.
While our default configuration is WCAG-compliant, the SDK is fully customizable, including color themes. We encourage integration teams to verify that customizations remain aligned with accessibility standards.
Contrast requirements:
- Normal text: Minimum contrast ratio of 4.5:1 (Level AA).
- Large text: Minimum contrast ratio of 3:1.
Tools we recommend for verifying color contrast:
- Figma Color Contrast Checker: Built directly into Figma, this feature helps verify contrast levels and preview color combinations with visual impairments in mind.
- Stark (Plugin for Figma, Sketch, Adobe XD): A powerful accessibility toolkit that checks contrast, simulates various types of color blindness, and audits your designs in context.
By following these standards and using the tools above, you can ensure your implementation stays inclusive and usable for all clients, regardless of visual ability.
Legal disclaimer (Fourthline)
As of the report date referenced in this publication, this document reflects Fourthline’s assessment of its product's alignment with relevant accessibility standards, including WCAG, for informational purposes only. The contents of this document are provided “as is” and are subject to change without prior notice.
This document does not constitute a legal commitment or warranty of conformance. Fourthline makes no guarantees that the information herein will remain accurate after the report date and continues to evaluate and improve the accessibility of its products on an ongoing basis.
Please note that any customizations or modifications to Fourthline’s SDKs or platform may affect the applicability of the information provided. Fourthline disclaims any liability arising from the use of this document, and no contractual obligation is created, either explicitly or implicitly. Additionally, Fourthline makes no representations about compatibility with third-party assistive technologies.
As part of the Bank Account Verification (BAV) flow, Fourthline uses third-party services provided by Tink. To review Tink’s accessibility statement, please visit Tink’s Accessibility Statement.
Updated about 12 hours ago