Vivipod Accessibility Conformance Report (VPAT®)
Last updated: November 2, 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. This revision covers version 1.65.0. Version 1.63.0 redesigned the recorder and the post player; defects found while evaluating that design were fixed in 1.65.0 and are noted in the relevant rows. The automated suites described under Evaluation Methods Used were run against 1.65.0 in November 2026, together with one-off automated checks of the parts the suites do not yet reach. The manual review, 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), was carried out by Vivipod in September 2026 on version 1.19.0, before the redesign. Remarks that rest on it are marked "(September 2026 manual review)". A manual pass on the redesigned recorder and post player is pending; see Manual review of the redesign below. Several defects found in the September review were fixed before that report was published 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.65.0, including Vivipod Plus |
| Report Date | November 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. The automated checks were run against version 1.65.0 in November 2026, in the Chromium browser engine in light and dark colour schemes. They run against a development build of the application with a local database, and are not part of the checks that run automatically on every change. The manual review was carried out by Vivipod in September 2026 on version 1.19.0, before the recorder and the post player were redesigned.
| 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 | 46 scans: fourteen page cases, including the post player at phone width, and the recorder's idle, recording, paused and review states, its camera-paused notice, its armed delete-last-clip key, its picture-in-picture position menu, its pen colour menu and the reaction recorder, each in two colour schemes |
| 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, on each tested page and on the recorder and the post player at phone width (390×844); keyboard traps; Escape dismissal of dialogs. In the recorder: record → show and hide the topic → pause → review activated with key events after programmatic focus; the Layout menu on the tool rail opened and its picture-in-picture segment chosen with Tab and Enter, and all nine picture-in-picture positions reached and selected through the position menu, with focus return verified; the delete-last-clip key armed with Enter and disarmed with Escape; a pen colour chosen; Discard's confirmation answered; a reaction's subject video played, sought and paused |
| 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 visible text contained in accessible names on the recorder's tool rail and the post player's phone rail. In the recorder: the tool rail staying a single column on screen and clear of the record button at 320×700, 390×844, 844×390 and 1280×800, and the picture-in-picture controls staying on screen, apart and unobscured in all nine positions at 320×800, 390×844, 844×390 and 1280×800 |
| One-off checks | Playwright and axe-core, run once in each colour scheme in November 2026, on version 1.63.0; what they checked is unchanged since, apart from the 1.65.0 fixes | Parts of the redesign the suites above do not yet reach: the phone comments sheet; how much the post player's phone rail buttons change when focused, measured from screenshots; the review screen's tab order and skip link at 1280×800 and 390×844; the comment ticker with and without reduced motion. These are not yet part of the suites above. |
| Code review | Manual review of the application code | Feature availability by plan, autocomplete attributes, media player configuration, and the redesigned recorder's and post player's controls, names and reduced-motion handling |
| Keyboard navigation (manual) | A person using the keyboard alone, September 2026, version 1.19.0 | 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, September 2026, version 1.19.0 | 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, in light and dark colour schemes, at a desktop window size and, for the recorder and the post player, at the phone sizes listed above. The manual review, in September 2026 and before the redesign, 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.
Manual review of the redesign
Placeholder: pending manual review. Version 1.63.0 replaced the recorder's controls with a tool rail and a new review screen, and the post view with a full-viewport player that, on phones, has its own controls, a side rail and a comment bar. A keyboard-only pass and VoiceOver (macOS, iPhone, iPad) and TalkBack (Android) sessions through recording, reviewing and posting a response, and viewing a post on desktop and phone, have not yet been repeated on this design. Remarks marked "(September 2026 manual review)" describe the design before it. Vivipod will replace this placeholder with the date, version, devices, screen readers, flows covered and findings of that pass.
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 Tab carries an accessible name: checked by axe scans and keyboard checks on the tested pages and recorder states, and on the recorder and the post player at phone width. Icon-only controls are labelled, including the recorder's tool rail (for example "Layout: Picture-in-picture", "Share screen" and "Clear drawing") and the post player's rail ("View newer post", "Comments (2)", "More post options"). The swatches in the recorder's pen colour menu are named after their colour; in 1.63.0 and 1.64.0 they had no names, which was fixed in 1.65.0 and is now verified by automated checks. The cover chosen on the recorder's review screen is shown as an image named "Cover". A video's poster is the frame chosen as its cover, and is not exposed as a separate image (code review). Labels on the core flows were reviewed by a person with VoiceOver (September 2026 manual review); 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 46 scans. The recorder's review screen is exposed as a region labelled by its heading, "Review your recording". The recorder's tools are grouped as "Recorder tools", and the review screen's as "Review tools". In the post player, the video sits in a section named "Video" and, on wider screens, the details beside it in an aside named "Post details" (code review). |
| 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 (September 2026 manual review). |
| 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. The recorder's on/off tools (Share screen, Subject video, Show topic) expose their state with aria-pressed and change icon or opacity as well as colour (code review). |
| 1.4.2 Audio Control | Supports | A post's video starts playing when it is opened, with sound where the browser allows it and muted where it does not. It can be paused or muted at any time. On wider screens the player uses the browser's native media controls, which include pause and volume, and a "Tap to unmute" button appears when the browser started the video muted. In the phone layout the player has its own controls instead: the whole video is a Play/Pause button, and a Mute/Unmute button sits in its top bar (code review; the keyboard check at phone width reaches and names both). |
| 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 (September 2026 manual review, before the redesign). On the redesigned recorder, automated checks use key events alone to start, pause and finish a take, show and hide the topic, and open the review screen; to open the Layout menu on the tool rail and choose picture-in-picture in it; to reach and select all nine picture-in-picture positions through the position menu on the picture-in-picture square, with focus returning to its trigger after selection or Escape; to arm the delete-last-clip key with Enter and disarm it with Escape; and to play, seek and pause a reaction's subject video. The recorder's hints open on keyboard focus. In the post player, the Up and Down arrow keys and the up and down buttons move between posts (code review), and in the phone layout every control is reached by Tab and named (automated check). 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. The post player moves between posts with the Up and Down arrow keys, which are not character keys, and leaves them alone while focus is in a text field, menu, slider or the comment list (code review). |
| 2.2.1 Timing Adjustable | Supports | Two kinds of time limit are set by the content. Authentication sessions expire after seven days without activity or 30 days after sign-in; active recording and playback count as activity. Both defaults exceed the 20-hour threshold, so the 20 Hour Exception applies. An institution can ask the operator to set a shorter idle limit for its accounts; that limit is the institution's own security policy and is treated as essential. No advance warning is shown before a session expires. Emailed one-time sign-in codes expire ten minutes after they are sent. That is a time-limited authentication token, which the criterion's guidance treats as essential; the email and the code entry pages both state the ten-minute limit up front, and a new code can be requested whenever one expires (a short resend interval rate-limits repeated requests) without losing entered data elsewhere. Recording length is capped by plan, which is a content limit rather than a time limit on reading or interacting, and the remaining recording time is displayed throughout. |
| 2.2.2 Pause, Stop, Hide | Supports | While recording, the record button's disc pulses gently as a status cue, and the timer pulses once 95% of the recording limit is used. In the post player's phone layout, the newest comments scroll continuously across the comment bar. All three stop when the person has asked for reduced motion (prefers-reduced-motion); in the recorder, colour and the control's label carry the same state without the animation. Automated checks confirm that the record button's disc animates while recording and stops under reduced motion; one-off checks confirmed the same for the comment ticker, and the timer's pulse was confirmed by code review. The comment ticker has no pause control of its own: the reduced-motion setting is what stops it. |
| 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's first Tab stop is a skip link that moves focus to its tools and controls (the tool rail, the upload or delete-last-clip key, the record button and Next), past the back control, the topic, the timer and the picture-in-picture controls; this is verified by automated checks. The review screen's first Tab stop is a skip link that moves focus past the back control, the topic and the play/pause control over the picture to the seek and trim bars, Retake, the description and Upload; the one-off checks verified it at 1280×800 and 390×844. |
| 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 moves to the description field on keyboard devices. The field is described by the screen heading, so the change of screen is announced with it, and Enter in it does not upload. In the wide layout Retake and Upload sit either side of it, one Tab away; at phone width Retake and Upload follow it. On touch-first devices (pointer: coarse) focus moves to the review region, which is labelled by its heading, so a text field does not raise the on-screen keyboard over the video. Automated checks verify both at the desktop size, and the one-off checks verified the keyboard-device behaviour at 390×844. The review screen's tools, Capture cover, Download and Discard, follow Upload in the Tab order (one-off check). Cancelling the Retake or Discard confirmation returns focus to the button that opened it, and confirming either moves focus to the record button once the recorder is back (automated checks); before 1.65.0 both left focus on the page, which was fixed in 1.65.0. In the post player's phone layout, closing the comments sheet with Escape returns focus to the Comments button that opened it (one-off check). |
| 2.4.4 Link Purpose (In Context) | Supports | No axe link-name violations across 46 scans. Icon-only links state their destination. Link text on the core flows was reviewed by a person with VoiceOver (September 2026 manual review); post and asset card links were renamed as a result to read as author, description and age. |
| 2.5.1 Pointer Gestures | Supports | Freehand drawing on the video is path-based, but the drawn path is the content being produced, so the gesture is essential. In the post player's phone layout, swiping up or down moves between posts; the "View newer post" and "View older post" buttons at the top of the player's rail make the same moves with a single tap (code review). All other operation is single-pointer without a path. |
| 2.5.2 Pointer Cancellation | Supports | Buttons and menu items activate on the up-event. Sliders follow the pointer from the down-event so that they can be dragged: the post player's seek bar on phones, and the recorder review screen's seek bar and trim handles. Until the pointer is released it can move them back; a seek changes only the playback position, and a trim is applied only when it is confirmed, or when the video is uploaded or downloaded (code review). |
| 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. Verified programmatically on the recorder's tool rail with its tool names shown, at desktop and phone width, and on the post player's phone rail, where "More" is named "More post options" and the "CC" button's name starts with "CC" followed by the captions' state or next action, for example "CC: Hide captions". Both were named without their visible label in 1.63.0 and 1.64.0, which was fixed in 1.65.0. |
| 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 46 scans, including the recorder's four states, its camera-paused notice, its armed delete-last-clip key, its picture-in-picture position menu, its pen colour menu, the reaction recorder and the post player at phone width. Additionally verified programmatically: every keyboard-reachable control on the tested pages, including the phone layouts of the recorder and the post player, has an accessible name. On/off tools expose their state with aria-pressed, and so does the chosen pen colour; both are verified by automated checks. The post player's seek bar on phones is a slider whose value is read as the current time of the total (code review). |
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 46 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 on most pages are a 3 px glow in the brand accent around the control (code review). Over video, the recorder's and the post player's controls use a 2 px white outline or ring, or a dark one on the post player's light stage (code review). Automated checks measure the indicator on every keyboard-reachable control on the tested pages, including the recorder and the post player at phone width, against the page colour behind it, in both colour schemes, and fail below 3:1. Over live video that backdrop is the picture itself, which the check cannot measure. The post player's round rail buttons draw their ring around the icon inside the button; the check confirms it is there but does not measure it, and screenshots in both colour schemes showed focus changing its pixels by more than 10:1 (one-off check). In 1.63.0 and 1.64.0 the phone player's up and down buttons and seek bar showed focus only as a faint tint; they gained an outline in 1.65.0. 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 (September 2026 manual review). |
| 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 are tooltips: the recording limit on the timer, the descriptions of the Layout menu's "hidden" and "full" options, and, on the review screen, the hint on Upload while no cover has been captured or the trimmed video is still too long, and the video's preparation progress. 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; on a touch screen they open on a tap and close on the next. Automated checks verify this for the timer's and the Layout options' hints; the review screen's hints use the same tooltip component (code review). The Upload control is aria-disabled rather than disabled until a cover exists, so a keyboard user can reach it and receive the hint. |
| 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 has a heading naming its purpose. |
| 2.4.7 Focus Visible | Supports | Verified programmatically on every tested page, including the recorder and the post player at phone width: every keyboard-reachable control renders an outline or a focus ring when focused, on the control itself or, for the post player's round rail buttons, around the icon inside it, and indicators drawn on the control measure at least 3:1 against their surroundings (see 1.4.11). In 1.63.0 and 1.64.0 the phone player's up and down buttons and seek bar showed focus only as a faint tint, and its topic and "more" text buttons only as an underline; all four have an outline since 1.65.0. |
| 2.4.11 Focus Not Obscured (Minimum) | Supports | The recorder's tools and controls float over the picture rather than sitting in a fixed bar. Automated checks require the tool rail to stay a single column fully on screen and clear of the record button at 320×700, 390×844, 844×390 and 1280×800. They also require the picture-in-picture position and shape buttons, at each of the nine positions, square and circular, at 320×800, 390×844, 844×390 and 1280×800, to stay on screen, apart from each other, and topmost at their own centre, so that no notice or the tool rail covers them. These are measured once the square has stopped moving after each change of position. After a retake at 844×390 the preview is required to fit inside the screen. The criterion asks that a focused component not be entirely hidden by author content. |
| 2.5.7 Dragging Movements | Supports | The picture-in-picture camera, which can be dragged into place, also has a position menu on the picture-in-picture square with the same nine destinations, each chosen with a single click or tap. Automated checks verify this with the keyboard at the desktop size and with taps at 390×844. The camera layout (hidden, picture-in-picture or one of three splits, or full) is chosen with single clicks or taps in the Layout menu on the recorder's tool rail, which automated checks also verify. The review screen's seek bar and trim handles move to wherever their bar is clicked or tapped, and with the arrow keys. In the post player's phone layout the seek bar moves to wherever it is tapped, and the comments sheet, which can be dragged down to close, also closes with its close button, a tap above it, or Escape (code review). Freehand drawing is path-dependent content creation for which dragging is essential. |
| 2.5.8 Target Size (Minimum) | Supports | Verified programmatically on the tested pages as they first load: no button or input is smaller than 24×24 CSS pixels. Axe's target-size rule, which also allows for spacing, reports no violations across 46 scans. That includes the recorder's review screen, whose seek bar and trim handles are narrower than 24 px in one direction and meet the criterion through that spacing, and the post player at phone width, whose seek bar along the bottom of the video is 24 CSS px tall; in 1.63.0 and 1.64.0 it was 20 px, which was fixed in 1.65.0. |
| 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 | Retaking a recording and discarding it from the review screen both drop a take that is saved only in the browser, and both ask for confirmation in a dialog first; Discard's dialog, including that Cancel keeps the take, is verified by automated checks. In 1.63.0 and 1.64.0 Discard deleted the take without asking, which was fixed in 1.65.0. Removing a post from a Topic is also confirmed in a dialog (code review). The recorder's delete-last-clip key removes a clip only on a second press, and says what it would remove after the first. 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 (September 2026 manual review). |
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).