Accessibility
Accessibility Conformance Report
VPAT® 2.5 INT · Report version 2.0 · 2026-09-03 · Product version 0.1.0
This report describes how the Eduspera platform conforms to recognised accessibility standards. Accessibility is a core product requirement at Eduspera, not a later add-on — every component is built and tested against WCAG 2.2 Level AA. For the product story behind this, see our accessibility page.
What this document is
An Accessibility Conformance Report (ACR) records, criterion by criterion, how a product measures up against a recognised accessibility standard. It is produced by completing the VPAT (Voluntary Product Accessibility Template), the form maintained by the Information Technology Industry Council — so when a procurement office asks for “your VPAT”, this page and its PDF are the answer. Each success criterion carries one of four conformance levels, and any gap is explained rather than hidden.
If you are evaluating vendors and want to know how to read a report like this one — what a wall of “Supports” usually means, and which five questions expose an unearned claim — see our guide to reading a VPAT/ACR. Institutions running a security review will also want our HECVAT answers.
Standards evaluated
- WCAG 2.2 Level AA (W3C Web Content Accessibility Guidelines) — primary target.
- EN 301 549 (European accessibility standard referenced by the European Accessibility Act).
- Section 508 (Revised, US) and ADA Title III — supported by the same WCAG 2.2 AA baseline.
Conformance status
Eduspera substantially conforms to WCAG 2.2 Level AA: 49 of 56 success criteria are fully supported, 5 partially supported and 2 not applicable. This is a vendor self-assessment based on the evaluation methods below; an independent third-party audit is in progress and this report will be updated with its findings and an attestation. Where we are aware of exceptions, we list them openly under Known limitations.
Evaluation methods
| Method | What we do |
|---|---|
| Automated | axe-core (WCAG 2.x A/AA rule set) runs in CI on every pull request and on main against public pages and authenticated learner/creator flows, together with a keyboard smoke test. A pull request carrying a serious or critical violation fails its checks and is not merged. |
| Keyboard | Keyboard-only walkthroughs of every critical flow (sign-up, course building, lesson playback, quiz, grading, settings), including a scripted Tab-to-primary-action and Escape-closes-dialog smoke in CI. |
| Screen readers | Manual testing with NVDA (Windows), VoiceOver (macOS/iOS) and JAWS on the core journeys. |
| Zoom & reflow | Content verified at 200% and 400% zoom and at 320 CSS px width without loss of content or function. |
| Contrast | Text and UI contrast checked against WCAG 2.2 AA, including a per-school brand-contrast check before publish. |
Conformance by success criterion
Conformance terms follow the VPAT convention: Supports (no known blocking issues), Partially Supports (some functionality does not fully meet the criterion — see notes), Does Not Support, and Not Applicable. Criteria marked (2.2) are new in WCAG 2.2.
Showing 56 of 56 criteria.
1. Perceivable
| Criterion | Level | Status | Notes |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Supports | Alt text is mandatory on every image upload in the builder; decorative platform icons are hidden from assistive technology. Creator-supplied third-party embeds are governed by their providers. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | A | Partially Supports | Video lessons carry an editable transcript. A text alternative for creator-uploaded audio-only or video-only media is encouraged by the accessibility score but not enforced at upload. |
| 1.2.2 Captions (Prerecorded) | A | Partially Supports | Every new video lesson is captioned automatically (speech-to-text) and carries a review status; academies can require human-reviewed captions before publishing. Some videos migrated from legacy platforms are still awaiting caption backfill. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | A | Partially Supports | The player supports audio-description tracks and transcripts. Providing them for creator-authored video depends on the creator; the accessibility score flags videos without an alternative. |
| 1.2.4 Captions (Live) | AA | Not Applicable | The platform has no live (synchronised) media. |
| 1.2.5 Audio Description (Prerecorded) | AA | Partially Supports | Audio-description tracks are supported by the player (upload per video lesson). Coverage depends on creators supplying them; the accessibility score surfaces the gap before publishing. |
| 1.3.1 Info and Relationships | A | Supports | Semantic headings, lists, tables and form labels throughout the application; the rich-text editor enforces heading structure in lesson content. |
| 1.3.2 Meaningful Sequence | A | Supports | DOM order matches the visual order; reading order is preserved at every breakpoint. |
| 1.3.3 Sensory Characteristics | A | Supports | Instructions never rely on shape, colour or position alone. |
| 1.3.4 Orientation | AA | Supports | No orientation lock; layouts work in portrait and landscape. |
| 1.3.5 Identify Input Purpose | AA | Supports | Autocomplete attributes on name, email, address and payment fields. |
| 1.4.1 Use of Color | A | Supports | Status, errors and links carry text, icons or underline in addition to colour. |
| 1.4.2 Audio Control | A | Supports | No media autoplays; the read-aloud control is user-initiated and has pause/stop. |
| 1.4.3 Contrast (Minimum) | AA | Partially Supports | Platform UI meets 4.5:1. Academy brand colours are contrast-checked before publish and a compliant fallback is enforced for text on brand backgrounds; colours inside creator-authored lesson content are flagged by the accessibility score but not blocked. |
| 1.4.4 Resize Text | AA | Supports | Text resizes to 200% without loss; an app-wide font-size preference is available. |
| 1.4.5 Images of Text | AA | Supports | Platform text is real text; logos are the only exception. |
| 1.4.10 Reflow | AA | Supports | Content reflows at 320 CSS px / 400% zoom without two-dimensional scrolling (data tables scroll within their container). |
| 1.4.11 Non-text Contrast | AA | Supports | Focus indicators, form borders and icon-only controls meet 3:1. |
| 1.4.12 Text Spacing | AA | Supports | Layouts tolerate the WCAG text-spacing overrides; a reading toolbar exposes spacing controls. |
| 1.4.13 Content on Hover or Focus | AA | Supports | Tooltips and menus are dismissible with Escape, hoverable and persistent. |
2. Operable
| Criterion | Level | Status | Notes |
|---|---|---|---|
| 2.1.1 Keyboard | A | Supports | Every interface — course builder (drag-and-drop has a keyboard sensor), learner player, quiz, grading — is fully operable by keyboard. |
| 2.1.2 No Keyboard Trap | A | Supports | Dialogs trap focus intentionally and release it on Escape or close; no other traps. |
| 2.1.4 Character Key Shortcuts | A | Supports | No single-character shortcuts are defined. |
| 2.2.1 Timing Adjustable | A | Supports | Quiz time limits are optional, announced, and can be extended per learner by the academy; no other timeouts except session expiry with re-authentication. |
| 2.2.2 Pause, Stop, Hide | A | Supports | No auto-updating or moving content; animations respect prefers-reduced-motion and an in-app reduce-motion toggle. |
| 2.3.1 Three Flashes or Below Threshold | A | Supports | No flashing content in the platform UI. |
| 2.4.1 Bypass Blocks | A | Supports | Skip-to-content link on every page; landmarks (banner, navigation, main, contentinfo). |
| 2.4.2 Page Titled | A | Supports | Unique, descriptive titles per route. |
| 2.4.3 Focus Order | A | Supports | Logical focus order; focus is moved into dialogs and restored on close. |
| 2.4.4 Link Purpose (In Context) | A | Supports | Link text is descriptive; icon-only links carry accessible names. |
| 2.4.5 Multiple Ways | AA | Supports | Navigation, search, sitemap and course outlines. |
| 2.4.6 Headings and Labels | AA | Supports | Descriptive headings and labels; the builder nudges creators to use headings in lesson content. |
| 2.4.7 Focus Visible | AA | Supports | Visible, high-contrast focus ring on every interactive element. |
| 2.4.11 Focus Not Obscured (Minimum)(2.2) | AA | Supports | Sticky headers and toolbars never cover the focused element. |
| 2.5.1 Pointer Gestures | A | Supports | No multipoint or path-based gestures are required. |
| 2.5.2 Pointer Cancellation | A | Supports | Actions fire on up-event; drag operations can be abandoned. |
| 2.5.3 Label in Name | A | Supports | Accessible names contain the visible label text. |
| 2.5.4 Motion Actuation | A | Supports | No motion-operated functionality. |
| 2.5.7 Dragging Movements(2.2) | AA | Supports | Reordering in the course builder can be done with the keyboard (space to pick up, arrows to move) as an alternative to dragging. |
| 2.5.8 Target Size (Minimum)(2.2) | AA | Supports | Interactive targets are at least 24×24 CSS px or adequately spaced. |
3. Understandable
| Criterion | Level | Status | Notes |
|---|---|---|---|
| 3.1.1 Language of Page | A | Supports | The html lang attribute follows the user's interface language (EN/IT/ES). |
| 3.1.2 Language of Parts | AA | Supports | Lesson content is marked with the course language when it differs from the interface language. |
| 3.2.1 On Focus | A | Supports | Focus never triggers a change of context. |
| 3.2.2 On Input | A | Supports | Changing a control never submits or navigates without an explicit action. |
| 3.2.3 Consistent Navigation | AA | Supports | Navigation and sidebar order is consistent across the application. |
| 3.2.4 Consistent Identification | AA | Supports | Shared component library gives identical controls identical names and icons. |
| 3.2.6 Consistent Help(2.2) | A | Supports | Help and contact links sit in the same location (footer / account menu) on every page. |
| 3.3.1 Error Identification | A | Supports | Errors are described in text, linked to the field, and announced. |
| 3.3.2 Labels or Instructions | A | Supports | Every input has a programmatic label and, where useful, instructions. |
| 3.3.3 Error Suggestion | AA | Supports | Validation messages say how to fix the problem. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Supports | Checkout shows a reviewable summary before payment; destructive actions require confirmation. |
| 3.3.7 Redundant Entry(2.2) | A | Supports | Previously entered information (name, billing details) is pre-filled within a process. |
| 3.3.8 Accessible Authentication (Minimum)(2.2) | AA | Supports | Password managers and paste are supported; Google SSO and enterprise SSO are available; email 2FA codes can be copied and pasted. No cognitive function test. |
4. Robust
| Criterion | Level | Status | Notes |
|---|---|---|---|
| 4.1.1 Parsing (obsolete) | A | Not Applicable | Removed in WCAG 2.2. Listed for report completeness only. |
| 4.1.2 Name, Role, Value | A | Supports | Native elements and ARIA where needed; states (expanded, selected, pressed) are exposed. Creator-embedded third-party widgets are governed by their providers. |
| 4.1.3 Status Messages | AA | Supports | Saves, uploads, grading outcomes and errors are announced via live regions. |
EN 301 549 (clauses 9–12)
| Clause | Status | Notes |
|---|---|---|
| 9 Web (clauses 9.1–9.4, 9.6) | Partially Supports | See the WCAG 2.2 table — EN 301 549 clause 9 maps to WCAG 2.1 AA; the 2.2-only criteria go beyond the EN requirement. |
| 10 Non-web documents | Supports | Generated PDFs (certificates, alternative-format lesson exports, this report) are tagged, carry a language and a heading outline, and use real tables with header cells. |
| 11 Software (11.1–11.7) | Supports | Web application; user preferences (theme, font size, reduced motion, high contrast) are honoured and the platform does not override assistive-technology settings. No closed functionality. |
| 11.8 Authoring tools | Partially Supports | The course builder produces accessible output (semantic HTML, alt-text prompts, heading structure), preserves accessibility information on import, and provides an accessibility score with remediation prompts. Templates are accessible. Repair of creator-supplied embeds is not automated. |
| 12.1 Product documentation | Supports | Documentation is delivered as accessible web pages; this report lists the accessibility and compatibility features. |
| 12.2 Support services | Supports | Support is available by email; support communications are accessible and alternative formats are provided on request. |
Revised Section 508 (chapters 3, 5, 6)
| Clause | Status | Notes |
|---|---|---|
| 3 Functional Performance Criteria (302.1–302.9) | Supports | Usable without vision (screen reader), with limited vision (zoom, contrast, font size), without perception of colour, without hearing (captions, transcripts), with limited hearing, without speech, with limited manipulation (keyboard-only), with limited reach and strength, and with limited language, cognitive and learning abilities (reading aids, consistent navigation, plain-language errors). |
| 5 Software (501–504) | Partially Supports | 501.1 / 502 (interoperability with assistive technology) and 503 (applications) are supported. 504 (authoring tools) is partially supported — see EN 301 549 clause 11.8. |
| 6 Support Documentation and Services (601–602) | Supports | Documentation (602.2 accessibility features, 602.3 electronic support docs in accessible web format, 602.4 alternate formats on request) and support services (603) are provided; support staff accommodate the communication needs of individuals with disabilities. |
Built-in accessibility features
- Automatic captions on video lessons, with editable transcripts, review status and an optional reviewed-captions publish gate.
- Audio-description tracks and sentence-level read-aloud in the lesson player.
- Keyboard-first, screen-reader-tested course builder and learner player.
- App-wide reading aids (theme, font size, high-contrast, reduced motion, reading toolbar).
- Alternative formats — any lesson or course as tagged PDF, HTML or Markdown.
- Per-course accessibility score that flags issues (missing captions, alt text, contrast) before publishing.
- Brand-contrast check so a school’s chosen colours still meet AA.
- Self-declared accessibility needs flow that suggests appropriate supports to each learner.
Known limitations
- 1.2.1 Audio-only and Video-only (Prerecorded) — Video lessons carry an editable transcript. A text alternative for creator-uploaded audio-only or video-only media is encouraged by the accessibility score but not enforced at upload.
- 1.2.2 Captions (Prerecorded) — Every new video lesson is captioned automatically (speech-to-text) and carries a review status; academies can require human-reviewed captions before publishing. Some videos migrated from legacy platforms are still awaiting caption backfill.
- 1.2.3 Audio Description or Media Alternative (Prerecorded) — The player supports audio-description tracks and transcripts. Providing them for creator-authored video depends on the creator; the accessibility score flags videos without an alternative.
- 1.2.5 Audio Description (Prerecorded) — Audio-description tracks are supported by the player (upload per video lesson). Coverage depends on creators supplying them; the accessibility score surfaces the gap before publishing.
- 1.4.3 Contrast (Minimum) — Platform UI meets 4.5:1. Academy brand colours are contrast-checked before publish and a compliant fallback is enforced for text on brand backgrounds; colours inside creator-authored lesson content are flagged by the accessibility score but not blocked.
- Third-party embedded media or marketing pixels configured by a school are governed by their respective providers’ conformance.
Feedback and reporting an issue
We treat accessibility issues as priority defects. If you encounter a barrier, or need content in an alternative format, contact us at [email protected]. Please include the page or feature, your browser and assistive technology, and a description of the problem. We aim to acknowledge reports within 2 business days and to agree a remediation timeline for confirmed issues.
Frequently asked questions
What is an Accessibility Conformance Report (ACR)?
An ACR is a vendor’s documented assessment of how a product measures up against a recognised accessibility standard, criterion by criterion. It records a conformance level for each success criterion — Supports, Partially Supports, Does Not Support or Not Applicable — with notes explaining any gap. Buyers use it to compare products and to evidence due diligence in a procurement file.
What is the difference between a VPAT and an ACR?
The VPAT (Voluntary Product Accessibility Template) is the blank template, maintained by the Information Technology Industry Council. The ACR is the completed document you get once a vendor fills the template in. In practice the two words are used interchangeably, and a request for “your VPAT” means “your completed ACR”.
Which standards does this report cover?
WCAG 2.2 Level AA as the primary target, plus EN 301 549 (the European standard referenced by the European Accessibility Act) and the Revised Section 508 standards used in United States federal and public-sector procurement. All three share WCAG as their technical core, so one conformance effort satisfies the substance of all three.
Is this report independently audited?
Not yet. This is a vendor self-assessment based on the evaluation methods listed on this page: automated axe-core testing in the deployment pipeline, manual keyboard passes and screen-reader testing. An independent third-party audit is in progress and this report will be updated with its findings and an attestation. We would rather state that plainly than imply an attestation we do not hold.
How current is this report?
It is generated from a versioned data file in the product repository, so it is re-issued with every accessibility-relevant release rather than written once and left to age. The report version, date and the product version it describes are printed at the top of the page and on the PDF.
Formal approval and review
This report is maintained by Eduspera, a product of Design Excellent Group SL (Calle Blanquerna 53, 07003 Palma de Mallorca, Spain). It is generated from a versioned data file in the product repository, so it is re-issued with every accessibility-relevant release (see the accessibility changelog) and reviewed in full at least twice a year. The VPAT® 2.5 (INT) PDF is the document to attach to procurement and vendor-assessment files.
VPAT® is a registered trademark of the Information Technology Industry Council (ITI).