Accessibility Conformance Report
Accessibility Conformance Report
International Edition
Based on VPAT® Version 2.5Rev
Product Information
| Field | Value |
|---|---|
| Name of Product/Version | Talkio AI web application, current production version |
| Report Date | April 21, 2026 |
| Product Description | Talkio AI is a browser-based language learning application with AI tutor conversations, voice interaction, pronunciation assessment, courses, progress tracking, wordbook, flashcards, and account authentication flows. |
| Contact Information | hello@talkio.ai |
| Notes | This report is a self-assessment for the current Talkio AI web application. It covers the authenticated /app pages, the shared layouts and controls used by those pages. Native mobile apps, internal authoring tools, customer-created content, third-party hosted payment or authentication pages, and third-party embedded media are outside the direct scope except where noted. WCAG Level AAA was not evaluated. |
| Evaluation Methods Used | Review of keyboard, naming, landmark, label, media, form, and status-message patterns; and criteria-by-criteria mapping against VPAT® 2.5Rev International requirements. |
Applicable Standards/Guidelines
This report covers the degree of conformance for 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 |
| Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018 | Yes |
| EN 301 549 Accessibility requirements for ICT products and services - V3.1.1 (2019-11) and V3.2.1 (2021-03) | Yes |
Terms
The terms used in the Conformance Level column are defined as follows.
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of 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 term is only used for WCAG Level AAA criteria.
WCAG 2.x Report
The WCAG tables also document conformance for the web criteria referenced by Revised Section 508 Chapter 5 and Chapter 6, and EN 301 549 Clause 9 Web, relevant portions of Clause 10 Non-Web Documents, Clause 11 Software, and Clause 12 Documentation and Support Services.
The answers are scoped for full pages, complete processes, and accessibility-supported ways of using technology. For this self-assessment, the application is evaluated as a responsive web application using semantic HTML, Next.js, Chakra UI, browser accessibility APIs, and accessible alternatives where a feature has more than one interaction path.
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | /app pages use text labels, image alternatives, icon button names, and visible numeric/text equivalents for progress and score information. Decorative icons and images are not required to understand the core workflows. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Supports | Core /app flows do not require prerecorded audio-only or video-only content. Where course media is embedded, it is presented through a titled player with user controls; third-party media content itself is outside direct scope. |
| 1.2.2 Captions (Prerecorded) | Supports | Talkio AI’s core learning flows provide text-based alternatives to voice interaction, including chat text and transcription-oriented experiences. Caption availability for third-party or customer-provided embedded media depends on the media source. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Supports | The evaluated /app pages are primarily interactive web content. Essential instructions and learning prompts are provided as text; third-party embedded media content is outside direct scope. |
| 1.3.1 Info and Relationships | Supports | Shared layouts provide main, navigation, and complementary landmarks. Page headings, settings tabs, menus, dialogs, form controls, course steps, wordbook items, flashcards, and authentication flows use semantic structure or ARIA-supported components. |
| 1.3.2 Meaningful Sequence | Supports | The evaluated pages follow a logical DOM and visual sequence, including the app shell, chat, settings, course flows, pronunciation, wordbook, flashcards, and authentication cards. |
| 1.3.3 Sensory Characteristics | Supports | Instructions are not conveyed only by shape, color, position, orientation, or sound. Text labels, headings, button text, and inline instructions are provided for core actions. |
| 1.4.1 Use of Color | Supports | Color is supplemented by text, icons, labels, or numeric values for status, progress, selection, validation, and scoring in evaluated /app flows. |
| 1.4.2 Audio Control | Supports | Audio playback and recording are user-initiated or user-controlled. No known automatically playing audio continues for more than three seconds without controls. |
| 2.1.1 Keyboard | Supports | Core evaluated workflows are operable with the keyboard using native buttons, links, form fields, tabs, menus, dialogs, and patched custom controls for course answers, flashcards, pronunciation history, search, chat input, and authentication actions. |
| 2.1.2 No Keyboard Trap | Supports | No keyboard traps were identified in the evaluated /app pages. Modal and popover behavior is provided through Chakra UI or equivalent focus-managed controls. |
| 2.1.4 Character Key Shortcuts | Supports | Keyboard shortcuts use modifier keys, standard keys in expected contexts, or are supplemental to visible controls. Core actions remain available through buttons and form controls. |
| 2.2.1 Timing Adjustable | Supports | No evaluated learning or authentication task imposes a short, non-adjustable time limit. Authentication sessions may expire for security reasons. |
| 2.2.2 Pause, Stop, Hide | Supports | Moving or loading content is either brief, user-initiated, or associated with active recording, loading, or celebration states. Users can stop/cancel recording and continue without relying on animated content. |
| 2.3.1 Three Flashes or Below Threshold | Supports | No evaluated content is known to flash more than three times per second. |
| 2.4.1 Bypass Blocks | Supports | The app and landing layouts include skip links and main landmarks, enabling keyboard users to bypass repeated navigation. |
| 2.4.2 Page Titled | Supports | Pages use Next.js document titles or route-level titles for key app, authentication, course, Trust Center, and learning flows. |
| 2.4.3 Focus Order | Supports | Focus order follows the visual and logical sequence for navigation, forms, tabs, dialogs, menus, chat input, course steps, flashcards, and authentication actions. |
| 2.4.4 Link Purpose (In Context) | Supports | Navigation links and action buttons use descriptive visible text or accessible labels. Icon-only controls have programmatic names where used in the evaluated scope. |
| 2.5.1 Pointer Gestures | Supports | No evaluated core functionality requires multipoint or path-based pointer gestures without an alternative. |
| 2.5.2 Pointer Cancellation | Supports | Core pointer interactions use native buttons and links or equivalent controls that activate on click/release and provide cancellation paths where relevant. |
| 2.5.3 Label in Name | Supports | Visible control labels are reflected in accessible names for /app navigation, inputs, buttons, menus, tabs, and patched custom controls. |
| 2.5.4 Motion Actuation | Not Applicable | The evaluated web application does not require device motion or user motion input. |
| 3.1.1 Language of Page | Partially Supports | Public and authentication pages set a valid BCP 47 language code on <html> based on the route. Authenticated /app pages intentionally set lang="" and translate="no" on the <html> element to prevent browser translation tools from automatically translating foreign-language learning content, which would interfere with the core product purpose. As a result, the default page language cannot be programmatically determined for authenticated /app pages. |
| 3.2.1 On Focus | Supports | No evaluated component changes context solely as a result of receiving focus. |
| 3.2.2 On Input | Supports | Form and selector changes are user-initiated and predictable. Context-changing actions use buttons, menu items, or explicit selection controls. |
| 3.2.6 Consistent Help | Supports | Help and support entry points are consistently available through public footer navigation, the Trust Center, contact information, and contextual help in relevant learning flows. |
| 3.3.1 Error Identification | Supports | Errors are identified with inline messages, Chakra alerts/toasts, validation messages, microphone permission notices, and loading/failure states in evaluated /app flows. |
| 3.3.2 Labels or Instructions | Supports | Inputs and selectors provide visible labels, accessible names, helper text, placeholders, or contextual instructions. Authentication is handled through standard provider flows; local app inputs now expose accessible names where placeholders are used. |
| 3.3.7 Redundant Entry | Supports | No evaluated multi-step process requires users to re-enter the same information unless required for security, confirmation, or user-initiated repetition. |
| 4.1.1 Parsing | Supports | For WCAG 2.0 and 2.1, this criterion is considered met per the September 2023 WCAG errata. WCAG 2.2 removed this criterion. |
| 4.1.2 Name, Role, Value | Supports | Native and Chakra UI controls expose programmatic names, roles, and states. Custom dropdowns, tabs, course answer options, flashcard controls, search controls, chat input controls, and authentication actions expose accessible names and states. |
Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | The evaluated web application does not provide live synchronized audio or video broadcasts. |
| 1.2.5 Audio Description (Prerecorded) | Supports | Core evaluated /app flows are not dependent on prerecorded video. Essential course and learning instructions are presented as text; third-party embedded media content is outside direct scope. |
| 1.3.4 Orientation | Supports | The evaluated web application is responsive and does not restrict use to a single display orientation. |
| 1.3.5 Identify Input Purpose | Supports | Authentication fields are handled by established provider flows, and local profile/settings inputs use standard form controls and labels appropriate to their purpose. |
| 1.4.3 Contrast (Minimum) | Supports | The evaluated /app pages use the shared design system with readable text contrast for primary content, controls, navigation, cards, alerts, and form elements. |
| 1.4.4 Resize Text | Supports | Evaluated pages use responsive Chakra layouts and browser text rendering. /app pages support zoom and text resize without requiring horizontal scrolling for core workflows. |
| 1.4.5 Images of Text | Supports | Images of text are not used as the primary way to present essential product information, except for logos or incidental branding. |
| 1.4.10 Reflow | Supports | The evaluated app shell and /app pages use responsive layouts, mobile navigation, flexible grids, and constrained content areas to support narrow viewports and zoomed use. |
| 1.4.11 Non-text Contrast | Supports | Primary controls, focus indicators, selected states, progress indicators, input boundaries, and icons in the evaluated scope provide visible contrast through the design system and patched focus states. |
| 1.4.12 Text Spacing | Supports | Text is rendered as standard web text in flexible containers, and evaluated pages do not rely on fixed text images or clipping for core content. |
| 1.4.13 Content on Hover or Focus | Supports | Tooltips, menus, popovers, and dialogs in the evaluated scope are dismissible and keyboard accessible through Chakra UI or equivalent component behavior. |
| 2.4.5 Multiple Ways | Supports | Major destinations are reachable through app navigation, dashboard/course links, direct URLs, footer links, and contextual links. |
| 2.4.6 Headings and Labels | Supports | /app pages use descriptive headings, tab labels, button labels, form labels, and contextual instructions for primary workflows. |
| 2.4.7 Focus Visible | Supports | Native and Chakra controls provide visible focus styling; patched custom controls include explicit focus-visible outlines where needed. |
| 2.4.11 Focus Not Obscured (Minimum) | Supports | Evaluated fixed navigation, sidebars, mobile chrome, dialogs, and course/chat controls do not intentionally obscure focused controls in normal use. |
| 2.5.7 Dragging Movements | Not Applicable | Dragging is not required for the evaluated /app and /authentication user workflows. |
| 2.5.8 Target Size (Minimum) | Supports | Primary controls and patched custom controls meet practical target sizing through Chakra UI buttons, icon buttons, menus, tabs, inputs, and navigation controls. |
| 3.1.2 Language of Parts | Does Not Support | Authenticated app pages intentionally set lang="" and translate="no" at the page level to prevent browser translation of target-language learning content. No lang attributes are applied at the span or message level. Adding per-element lang attributes would re-enable browser translation for those spans in some environments, which conflicts with the product's core design. Public pages are not subject to mixed-language content and are unaffected. |
| 3.2.3 Consistent Navigation | Supports | Primary navigation is consistent within the app shell, and public/footer navigation remains consistent across the evaluated public entry points. |
| 3.2.4 Consistent Identification | Supports | Repeated actions such as start, continue, next, retry, sign in, create account, delete, play audio, record, send, search, and open navigation are identified consistently in the evaluated /app pages. |
| 3.3.3 Error Suggestion | Supports | Validation and error states provide corrective guidance through alerts, toasts, inline messages, permission guidance, retry actions, and descriptive fallback text. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Financial processing is handled by established external providers. Evaluated data-changing and destructive app actions use confirmations, clear action labels, undo-equivalent workflow paths, or scoped updates that users can review before acting. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | Authentication does not require users to solve a cognitive-function test in the local product. Standard account creation, sign-in, provider authentication, and recovery flows are used. |
| 4.1.3 Status Messages | Supports | Loading, success, error, recording, transcription, permission, and validation states are surfaced through visible text, Chakra alerts/toasts, loading text, and stateful controls without requiring a context change. |
Revised Section 508 Report
Hardware-specific criteria are summarized as not applicable because Talkio AI is a web application. Web and software criteria that map directly to WCAG are cross-referenced to the WCAG tables above.
Chapter 3: Functional Performance Criteria
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 302.1 Without Vision | Supports | The evaluated /app workflows use semantic landmarks, headings, keyboard-operable controls, names/roles/values, text alternatives, and accessible provider flows. |
| 302.2 With Limited Vision | Supports | Responsive layouts, browser zoom, readable typography, visible focus, non-text contrast, and text alternatives support users with limited vision in evaluated workflows. |
| 302.3 Without Perception of Color | Supports | Color is supplemented by text labels, icons, headings, values, or state text for evaluated progress, validation, scoring, selection, and navigation states. |
| 302.4 Without Hearing | Supports | Text chat, visible instructions, transcription-oriented interaction, text feedback, and text alternatives support use without hearing. Embedded third-party media caption quality depends on the source. |
| 302.5 With Limited Hearing | Supports | Core learning flows provide text-based alternatives and visible status/feedback. Users can use typed chat and visual feedback without relying only on audio. |
| 302.6 Without Speech | Supports | Core learning can be completed with text input and non-speech controls. Speech-specific pronunciation and voice practice are optional enhancement features rather than the only way to use the product. |
| 302.7 With Limited Manipulation | Supports | Evaluated /app workflows support keyboard operation through buttons, links, form controls, menus, tabs, dialogs, and patched custom controls. |
| 302.8 With Limited Reach and Strength | Supports | The responsive web interface supports desktop and mobile use, keyboard input, and standard browser/device interaction patterns for the evaluated workflows. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Supports | The product uses familiar navigation, guided learning flows, clear calls to action, repeated patterns, visible progress, helper text, and recoverable errors in evaluated /app pages. |
Chapters 4, 5, and 6: Hardware, Software, Support Documentation and Services
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| Chapter 4 Hardware | Not Applicable | Talkio AI is a web application and does not include dedicated hardware, kiosks, closed hardware controls, telephones, caption decoders, or audio-description hardware. |
| 501.1 Scope - Incorporation of WCAG 2.0 AA | See WCAG 2.x section | Web and software conformance is documented in the WCAG Level A and AA tables. |
| 502 Interoperability with Assistive Technology | Supports | The evaluated product uses semantic HTML, browser accessibility APIs, Chakra UI accessibility primitives, and patched custom controls to expose name, role, state, value, focus, and event information. |
| 503 Applications | Supports | The browser-based application generally respects platform and browser accessibility settings and does not override assistive technology behavior in evaluated workflows. |
| 504 Authoring Tools | Not Applicable | The evaluated /app and /authentication workflows are not marketed as authoring tools for creating accessible ICT content. Internal/admin authoring workflows are outside this report's direct scope. |
| 602 Support Documentation | Supports | Support and Trust Center information are delivered as web content and are intended to follow the same WCAG-supported presentation model documented above. |
| 603 Support Services | Supports | Support is available by email and help-center content. Accessibility-related questions can be directed to the contact listed in this report. |
EN 301 549 Report
EN 301 549 criteria are summarized by clause. Clause 9 Web is documented through the WCAG tables above; clauses that apply only to hardware, relay services, or dedicated telecommunications products are marked not applicable.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| Clause 4 Functional Performance Statements | Supports | Functional performance is summarized by the Section 508 Functional Performance Criteria and the WCAG tables above. |
| Clause 5 Generic Requirements | Supports | Closed functionality, biometrics, and hardware operable parts are generally not applicable. Access without speech, hearing, or precise pointer use is supported in evaluated /app workflows. |
| Clause 6 ICT with Two-Way Voice Communication | Supports | Talkio AI includes optional voice-based learning interaction but is not a telecommunications relay product. Text chat provides an alternative for core learning interactions. |
| Clause 7 ICT with Video Capabilities | Supports | Video is optional in the evaluated flows. Embedded media uses titled players and standard controls; third-party media captioning or descriptions depend on the media provider/content source. |
| Clause 8 Hardware | Not Applicable | Talkio AI does not include dedicated hardware. |
| Clause 9 Web | See WCAG 2.x section | Web content conformance is documented in the WCAG Level A and AA tables. |
| Clause 10 Non-Web Documents | Not Applicable | This report covers the web application. Product and support documentation are delivered primarily as web pages, not non-web documents. |
| Clause 11 Software | Supports | The browser-based application uses web platform accessibility APIs and accessible component primitives for evaluated software behavior. |
| Clause 12 Documentation and Support Services | Supports | Documentation and support are available online and by email. Accessibility-related inquiries can be directed to the contact listed above. |
| Clause 13 ICT Providing Relay or Emergency Service Access | Not Applicable | Talkio AI is not a relay service and does not provide emergency service access. |
Current Notes and Follow-up Items
Current follow-up items are limited and product-specific:
- Language attribute design decision (3.1.1, 3.1.2): Authenticated app pages intentionally set
lang=""andtranslate="no"on the<html>element. This suppresses native browser translation tools, which is a deliberate product design choice: automatically translating foreign-language learning content would undermine the purpose of a language learning application. This means WCAG 3.1.1 (Language of Page) is only partially satisfied and 3.1.2 (Language of Parts) is not satisfied for authenticated app pages. Screen reader users who rely on language switching for TTS pronunciation of target-language content are affected by this tradeoff. - Captioning, transcripts, and audio description for third-party or customer-provided embedded media depend on the media source.
Legal Disclaimer
This Accessibility Conformance Report is provided for informational purposes and is not a certification, warranty, or guarantee of accessibility conformance. Accessibility status may change as the product, dependencies, content, browsers, and assistive technologies change.
