Vivipod Accessibility Conformance Report (VPAT®)
Last updated: September 7, 2026
This is Vivipod's Accessibility Conformance Report (ACR), in the VPAT® 2.5Rev WCAG Edition format. It records how the Vivipod web application measures against WCAG 2.0, 2.1 and 2.2 at Levels A and AA, including known limitations. It does not separately evaluate the hardware, software or support-documentation requirements of Section 508 or EN 301 549.
Evaluation summary. The findings come from the automated suites described under Evaluation Methods Used, together with a manual review by Vivipod in September 2026: a keyboard-only pass, and screen reader sessions with VoiceOver on macOS, iPhone and iPad and with TalkBack on Android, through the core flows (signing in, the dashboard, recording and posting a response, and viewing a post). Several defects found in that review were fixed before publication and are noted in the relevant rows. This is a self-assessment, not a third-party audit; see the disclaimer at the end.
VPAT® Version 2.5Rev — WCAG Edition
| Field | Value |
|---|---|
| Name of Product/Version | Vivipod, version 1.19.0, including Vivipod Plus |
| Report Date | September 2026 |
| Product Description | Vivipod is a web application for asynchronous video discussion in education. Teachers create Spaces containing Topics; participants record short video responses in the browser and reply to one another. There is no native app; the recorder runs in the browser using the device camera and microphone. |
| Contact Information | support@vivipod.com |
| Evaluation Methods Used | See below. |
Scope
- This report covers the Vivipod web application at
vivipod.com. It does not cover the public information pages or content created by customers and participants. - Vivipod is both a delivery platform and an authoring tool: most content is recorded by end users. Where a criterion depends on what an author produces, such as captions or audio description, the response describes the mechanism Vivipod provides, and says whether that mechanism is available to every author.
- Subscription coverage. This report includes Vivipod Plus. Captions require a Plus subscription on the account that owns the Space; students and other participants do not need their own subscription.
- Level AAA is outside the scope of this evaluation.
Evaluation Methods Used
The evaluation combined automated testing with a manual review, both against version 1.19.0. Automated checks run in the Chromium browser engine in light and dark colour schemes, and they run on every change to the product to help catch accessibility problems before release. The manual review was carried out by Vivipod in September 2026.
| Method | Tool | What it covered |
|---|---|---|
| Automated rule checking | axe-core 4.13 via @axe-core/playwright, WCAG 2.0/2.1/2.2 A and AA rule sets | 36 scans: thirteen page cases in two colour schemes, plus the recorder's idle, recording, paused and review states and the PiP position menu |
| Keyboard operation | Playwright, driving real key events | Tab order, accessible name, visible focus indicator and its contrast against the composited backdrop for every reachable control; keyboard traps; Escape dismissal of dialogs; record → pause → review activated with key events after programmatic focus; all nine PiP positions reached and selected using Tab and menu navigation, with focus return verified |
| Structural checks | Playwright | Page titles, page language, reflow at 320 CSS px, the WCAG text-spacing overrides, 24×24 target sizes, presence of live regions, and the recorder's controls staying inside the viewport and unobscured at 320×800, 390×844, 844×390 and 1280×800 |
| Code review | Manual review of the application code | Feature availability by plan, autocomplete attributes, media player configuration |
| Keyboard navigation (manual) | A person using the keyboard alone | The core flows: signing in, the dashboard, recording and posting a response, and viewing a post; focus order, focus visibility, hints on focus and the skip links as experienced rather than as measured |
| Screen reader (manual) | VoiceOver on macOS, iPhone and iPad; TalkBack on Android | The same core flows, on desktop, phone and tablet: what each control, card and screen announces, whether names are meaningful and free of repetition or identifiers, and how the recorder's review screen and hints are announced |
Coverage. Automated checks ran in the Chromium browser engine on desktop, in light and dark colour schemes. The manual review used the keyboard alone and screen readers on desktop, phone and tablet: VoiceOver on macOS, iPhone and iPad, and TalkBack on Android. Form handling was confirmed by code review, and generated captions were reviewed on a sample of recordings.
Applicable Standards/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
- 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.
WCAG 2.x Report
Success Criteria are scoped for full pages, complete processes, and accessibility-supported ways of using technology, as documented in the WCAG 2 Conformance Requirements.
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | Every control reachable by keyboard carries an accessible name; checked through axe scans and keyboard checks on the tested pages and recorder states. Icon-only controls are labelled. Video posters are the first frame of the video they introduce and are exposed as such rather than as independent images. Labels on the core flows were reviewed by a person with VoiceOver; post and asset cards were re-labelled as a result, so that a card announces its author, description and age rather than an identifier, and never the same text twice. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Supports | A participant may record with the microphone disabled, producing video-only content. Every post carries a description field, which is the mechanism through which an author supplies an equivalent text alternative. As with any authoring tool, whether an individual author uses it is the author's decision. |
| 1.2.2 Captions (Prerecorded) | Supports | Evaluated with Vivipod Plus: the player supports on-demand WebVTT captions. An instructor controls caption availability per Topic and viewers choose whether to enable CC. Enabling CC requests generation if needed; generation requires an eligible Space membership and a Plus subscription on the account owning the Space, not the viewer’s plan. Completed captions can be read by anyone authorized to view the post when the caption control is available. Generation can take time or fail. Captions are machine-generated. A sample of generated transcripts was reviewed by a person and found accurate for clear classroom speech; as with any machine-generated captions, accuracy can drop with poor audio, heavy background noise, unusual names or specialist vocabulary. Captions cannot yet be edited within the application; a way for creators and administrators to correct transcripts is planned but not currently available. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Partially Supports | Posts provide an author-written description field, but automatic transcripts cover speech only and do not describe important visual information. Vivipod does not generate audio descriptions or complete descriptive transcripts. A speech transcript alone is not a full media alternative; the adequacy of author-supplied descriptions has not been evaluated. |
| 1.3.1 Info and Relationships | Supports | No axe violations for heading structure, lists, form labels or ARIA relationships across 36 scans. The recorder's review screen is exposed as a labelled region with a heading. |
| 1.3.2 Meaningful Sequence | Supports | Tab order was walked programmatically on every tested page and follows the visual order. No positive tabindex values are used. |
| 1.3.3 Sensory Characteristics | Supports | Controls are identified by text or accessible name rather than by shape or position alone. Status is conveyed by text and icon together, not position. Confirmed by a person on the core flows. |
| 1.4.1 Use of Color | Supports | The post filter conveys its state through aria-checked, a background change and an icon, not colour alone. Post status is conveyed by text badges. |
| 1.4.2 Audio Control | Supports | Video autoplays muted, so no audio begins automatically. Playback uses the browser's native media controls, which include volume and pause. |
| 2.1.1 Keyboard | Supports | The core flows were completed by a person using the keyboard alone: signing in, the dashboard, recording, pausing, reviewing and posting a response, and viewing a post. Picture-in-picture placement offers all nine drag snap positions through a keyboard-operable menu, with focus returning to its trigger after selection or Escape. The recorder's hints open on keyboard focus. Freehand drawing is path-dependent input covered by the criterion’s exception. |
| 2.1.2 No Keyboard Trap | Supports | Verified programmatically on every tested page: Tab always leaves the page rather than looping inside a widget. Modal dialogs hold focus by design and are dismissible with Escape, which is verified by automated checks. |
| 2.1.4 Character Key Shortcuts | Supports | The application defines no single-character key shortcuts. |
| 2.2.1 Timing Adjustable | Supports | No session timeout interrupts a task; the authentication session lasts seven days. Recording length is capped by plan, which is a content limit rather than a time limit on reading or interacting, and the remaining time is displayed throughout. |
| 2.2.2 Pause, Stop, Hide | Supports | The record button pulses while recording as a status cue, and the duration badge pulses as the recording limit approaches. Both stop when the person has asked for reduced motion (prefers-reduced-motion); colour and the control's label carry the same state without the animation. Other transitions in the application honour that setting as well. Verified by automated checks. |
| 2.3.1 Three Flashes or Below Threshold | Supports | No content flashes more than three times per second. |
| 2.4.1 Bypass Blocks | Supports | Every tested page, including the recorder, exposes a main landmark, which is a sufficient technique for bypassing repeated blocks. The recorder additionally offers a skip link as its first Tab stop that moves focus to its control bar, past the preview, picture-in-picture and duration controls, and the review screen offers one that jumps past the player's native controls to the description and upload controls. Both are verified by automated checks. |
| 2.4.2 Page Titled | Supports | Verified programmatically on every tested route: each has a descriptive, non-placeholder title. |
| 2.4.3 Focus Order | Supports | Focus order was walked programmatically and is logical. Focus does not land on zero-size elements. When the recorder replaces its interface with the review screen, focus is moved to the description field on keyboard devices, which is described by the screen heading so the change of screen is announced with it, and Retake and Upload follow directly; on touch-first devices (pointer: coarse) focus is moved to the review region, which is labelled by its heading, so a text field does not raise the on-screen keyboard over the video. |
| 2.4.4 Link Purpose (In Context) | Supports | No axe link-name violations across 36 scans. Icon-only links state their destination. Link text on the core flows was reviewed by a person with VoiceOver; post and asset card links were renamed as a result to read as author, description and age. |
| 2.5.1 Pointer Gestures | Supports | The only path-based gesture is freehand drawing on the video, where the drawn path is the content being produced, so the gesture is essential. All other operation is single-pointer without a path. |
| 2.5.2 Pointer Cancellation | Supports | Controls activate on the up-event. No functionality is triggered on the down-event. |
| 2.5.3 Label in Name | Supports | Where a control has visible text, its accessible name contains that text, including the post filter's counts. |
| 2.5.4 Motion Actuation | Supports | No functionality is operated by device motion. |
| 3.1.1 Language of Page | Supports | The root element carries lang="en". Verified programmatically on every tested route. |
| 3.2.1 On Focus | Supports | Receiving focus does not change context anywhere in the tested pages. |
| 3.2.2 On Input | Supports | Changing a setting does not automatically change context. Filtering a post list updates content within the page and does not move focus or change the view. |
| 3.2.6 Consistent Help | Supports | Support contact information is reached the same way from each page that offers it. |
| 3.3.1 Error Identification | Supports | Form validation errors are described in text next to the field. Confirmed by code review. |
| 3.3.2 Labels or Instructions | Supports | Form fields have persistent programmatic labels. The comment and description composers were given accessible names of their own, because a placeholder stops labelling a field the moment someone types in it. |
| 3.3.7 Redundant Entry | Supports | The sign-in flow carries the email address forward to the verification step rather than asking for it twice. |
| 4.1.1 Parsing | Supports | Per the September 2023 errata, this criterion is always supported for WCAG 2.0 and 2.1. It is obsolete and removed in WCAG 2.2. |
| 4.1.2 Name, Role, Value | Supports | No axe violations for name, role or value across 36 scans, including the recorder's four states. Additionally verified programmatically: every keyboard-reachable control has an accessible name. |
Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | Vivipod carries no live or streamed media. All video is prerecorded and asynchronous. |
| 1.2.5 Audio Description (Prerecorded) | Does Not Support | Vivipod provides no mechanism for authors to add audio description, and none is generated. |
| 1.3.4 Orientation | Supports | The interface is responsive and operates in both portrait and landscape. The recorder locks the aspect of the recording itself once capture begins, which constrains the recorded content rather than the display of the interface. |
| 1.3.5 Identify Input Purpose | Supports | The sign-in email field carries autocomplete="email". Profile fields carry autocomplete="username" and autocomplete="nickname" for the participant’s chosen display name, which accepts a full name or nickname. The sign-in verification field also carries autocomplete="one-time-code". |
| 1.4.3 Contrast (Minimum) | Supports | No axe contrast violations across 36 scans in both light and dark colour schemes. Scans freeze animations first, so measurements are taken against settled colours. |
| 1.4.4 Resize text | Supports | Content is laid out in relative units and reflows without loss of content or functionality. Verified at a 320 CSS px viewport, equivalent to 400% zoom at 1280px. |
| 1.4.5 Images of Text | Supports | The only image of text is the wordmark, which is a logo. |
| 1.4.10 Reflow | Supports | Verified programmatically: no page requires horizontal scrolling at a 320 CSS px viewport width. |
| 1.4.11 Non-text Contrast | Supports | Focus indicators are drawn in the brand accent at full strength as a 2 px ring separated from the control by a 2 px gap in the page background, so the ring sits against a known colour on any control. Automated checks measure the indicator on every keyboard-reachable control on the tested pages against the colour behind it, in both colour schemes, and fail below 3:1. Icons, control boundaries and state indicators on the core flows were reviewed by a person in both colour schemes, and no contrast below 3:1 was found. |
| 1.4.12 Text Spacing | Supports | Verified programmatically: applying the WCAG text-spacing overrides for line height, letter spacing, word spacing and paragraph spacing clips no content on any tested page. |
| 1.4.13 Content on Hover or Focus | Supports | The recorder's hints (recording limit, clear drawing, input-source descriptions and the upload-needs-a-thumbnail notice) are tooltips: they appear on pointer hover and on keyboard focus, remain while the pointer is over them, persist until hover or focus ends, and Escape dismisses them without moving focus. The Upload control is aria-disabled rather than disabled until a thumbnail exists, so a keyboard user can reach it and receive the hint. Verified by automated checks. |
| 2.4.5 Multiple Ways | Supports | A Space is reachable from the dashboard listing and by direct URL, and Topics are reachable from within a Space. |
| 2.4.6 Headings and Labels | Supports | No axe violations for heading and label rules. The recorder's review screen was given a heading naming its purpose. |
| 2.4.7 Focus Visible | Supports | Verified programmatically on every tested page: every keyboard-reachable control renders either an outline or a focus ring when focused, and that indicator measures at least 3:1 against its surroundings (see 1.4.11). |
| 2.4.11 Focus Not Obscured (Minimum) | Supports | The recorder's fixed footer bar no longer covers the controls above it at short viewport heights. Automated checks place the recorder's controls at 320×800, 390×844, 844×390 and 1280×800 and require each to sit inside the viewport, clear of the recorder's notices, and to be the topmost element at its own centre; after a retake, the preview is required to fit entirely above the toolbar at 844×390. Confirmed by a person at reduced window heights. The criterion asks that a focused component not be entirely hidden by author content. |
| 2.5.7 Dragging Movements | Supports | Picture-in-picture camera placement offers a position menu with the same nine destinations as dragging; each can be selected with a single click or tap. The menu also supports keyboard navigation. Freehand drawing is path-dependent content creation for which dragging is essential. |
| 2.5.8 Target Size (Minimum) | Supports | Verified programmatically: no interactive target on the tested pages is smaller than 24×24 CSS pixels. |
| 3.1.2 Language of Parts | Supports | The interface is presented in a single language. Participant-recorded content is media rather than text passages. |
| 3.2.3 Consistent Navigation | Supports | The header, account menu and notification control appear in the same relative order on every page that includes them. |
| 3.2.4 Consistent Identification | Supports | Repeated controls use consistent icons and accessible names throughout. |
| 3.3.3 Error Suggestion | Supports | Validation messages describe what is required rather than only reporting failure. Confirmed by code review. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Destructive actions such as discarding a recording are confirmed through a dialog. Payment is handled by Stripe's hosted checkout, which provides its own review and confirmation step. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | Sign-in is by emailed one-time code or Google sign-in. No cognitive function test is imposed: there is no puzzle or transcription requirement, the code field supports paste and is marked autocomplete="one-time-code", and a federated alternative is offered. |
| 4.1.3 Status Messages | Supports | Status messages are announced through live regions without moving focus. Verified programmatically that live regions are present, and status announcements were heard in VoiceOver and TalkBack during the core flows. |
How captions work
Captions let participants read what is said in a recording.
Only the Space owner needs Vivipod Plus to enable caption generation. Students and other viewers do not need their own subscription.
| Who | Captions in an institution's Space |
|---|---|
| The subscribing institution's staff | Yes |
| Students and participants, including those on free accounts | Yes |
| Anyone who can view the post, after captions exist | Yes |
A subscribing institution enables generation for eligible members of its Spaces; students do not need their own Plus subscription. Completed captions remain readable after the subscription lapses, subject to post access and the caption control being available.
Instructors enable captions for each Topic. Captions are available to viewers only while that setting is enabled. Viewers enable CC to request captions. If none exist, an eligible member's request starts generation and the player adds the track once it is ready. Opening the post alone does not start generation, and a nonmember cannot start it. Delays and generation failures can leave captions temporarily unavailable.
The 1.2.2 rating assesses caption support with Vivipod Plus under these configuration and activation requirements. Captions are machine-generated. A sample of generated transcripts was reviewed by a person and found accurate for clear classroom speech; accuracy can drop with poor audio, background noise, unusual names or specialist vocabulary, so the rating is not a guarantee for every recording. Captions cannot yet be edited within the application. A way for creators and administrators to correct a transcript is planned but not currently available; until then, instructors sharing recordings with people who rely on captions should check their accuracy and contact support if errors make a recording difficult to follow.
Legal Disclaimer
This report describes the state of the product at the version and date given above, based on the evaluation methods described. It is a self-assessment and not a third-party certification. Vivipod makes no warranty that the product conforms to any standard beyond what is stated here.
VPAT® is a registered service mark of the Information Technology Industry Council (ITI).