Voluntary Product Accessibility Template (VPAT)

WCAG 2.2 Edition · Based on ITI VPAT 2.4

Export PDF

Product: StudioBase (Web Application (SaaS))
Date: April 2026
Contact: support@studiobase.org
Evaluation: Automated testing (axe-core WCAG 2.2 AA via Playwright E2E suite on every PR and merge), manual keyboard and screen reader testing, design system review, code audit

Live Accessibility Metrics

Last scan: 3h ago · main · cec22a0

Pages scanned

Critical

Serious

Moderate

Minor

Tags: wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aaEngine: axe-core 4.11.1

Route Scan Results

53 routes across 3 groups

Public Pages16 routes

All passing

Public Pages accessibility scan results
Route	Critical	Serious	Moderate	Minor	Status
/	0	0	0	0	Pass
/docs	0	0	0	0	Pass
/auth/login	0	0	0	0	Pass
/auth/signup	0	0	0	0	Pass
/docs/{category}	0	0	0	0	Pass
/auth/forgot-password	0	0	0	0	Pass
/platform	0	0	0	0	Pass
/auth/reset-password	0	0	0	0	Pass
/solutions	0	0	0	0	Pass
/auth/verify-email	0	0	0	0	Pass
/auth/guest/verify	0	0	0	0	Pass
/blog	0	0	0	0	Pass
/legal/vpat	0	0	0	0	Pass
/blog/{slug}	0	0	0	0	Pass
/privacy	0	0	0	0	Pass
/terms	0	0	0	0	Pass

Dashboard28 routes

1 failing

Dashboard accessibility scan results
Route	Serious	Status
/dashboard/members	1	Fail
/dashboard/settings/appearance	0	Pass
/dashboard/settings/promotions	0	Pass
/dashboard	0	Pass
/dashboard/settings/branding	0	Pass
/dashboard/bookings	0	Pass
/dashboard/settings/promo-codes	0	Pass
/dashboard/add-class	0	Pass
/dashboard/settings/billing	0	Pass
/dashboard/settings/rewards	0	Pass
/dashboard/transactions	0	Pass
/dashboard/settings/billing/invoices	0	Pass
/dashboard/settings/penalties	0	Pass
/dashboard/clients	0	Pass
/dashboard/payouts	0	Pass
/dashboard/settings/payouts	0	Pass
/dashboard/insights	0	Pass
/dashboard/clients/{email}	0	Pass
/dashboard/settings/emails	0	Pass
/dashboard/class/{schedule_item_id}	0	Pass
/dashboard/analytics/monthly	0	Pass
/dashboard/settings/class-presets	0	Pass
/dashboard/analytics/yearly	0	Pass
/dashboard/settings/class-packs	0	Pass
/dashboard/analytics/sources	0	Pass
/dashboard/settings/memberships	0	Pass
/dashboard/settings	0	Pass
/dashboard/settings/general	0	Pass

Studio Booking9 routes

All passing

Studio Booking accessibility scan results
Route	Critical	Serious	Moderate	Minor	Status
/s/e2e-studio	0	0	0	0	Pass
/s/{subdomain}/memberships	0	0	0	0	Pass
/s/{subdomain}/packs	0	0	0	0	Pass
/s/{subdomain}/instructor/accept	0	0	0	0	Pass
/s/{subdomain}	0	0	0	0	Pass
/s/{subdomain}/bookings	0	0	0	0	Pass
/s/{subdomain}/booking/{bookingId}	0	0	0	0	Pass
/s/{subdomain}/my-bookings	0	0	0	0	Pass
/s/{subdomain}/my-membership	0	0	0	0	Pass

WCAG 2.2 Success Criteria — Level A

Curated conformance assessments. Updated as compliance work progresses.

WCAG 2.2 Level A conformance table
Criteria	Level	Remarks
1.1.1 Non-text Content	Supports	All images include descriptive alt text. Studio logos use the studio name (e.g., "Acme Studio logo"). Decorative images and icons use empty alt attributes or aria-hidden. Email templates include descriptive alt text for studio logo images.
1.2.1 Audio-only and Video-only (Prerecorded)	Not Applicable	The application does not include prerecorded audio-only or video-only content.
1.2.2 Captions (Prerecorded)	Not Applicable	The application does not include prerecorded multimedia content with audio.
1.2.3 Audio Description or Media Alternative (Prerecorded)	Not Applicable	The application does not include prerecorded video content.
1.3.1 Info and Relationships	Supports	Semantic HTML is used throughout (headings, lists, tables, landmarks). Form inputs have associated labels. Custom widgets use correct ARIA roles and relationship attributes. Combobox and multi-select patterns implement proper ARIA roles, states, and properties.
1.3.2 Meaningful Sequence	Supports	Content is presented in a logical reading order. The DOM order matches the visual presentation order across all major views.
1.3.3 Sensory Characteristics	Supports	Instructions and cues do not rely solely on shape, size, visual location, or sound. Error states use text labels in addition to color indicators.
1.4.1 Use of Color	Supports	Color is not the sole means of conveying information. Status indicators, form validation errors, and alerts include text labels and/or icons alongside color.
1.4.2 Audio Control	Not Applicable	The application does not auto-play audio content.
2.1.1 Keyboard	Supports	All navigation, form interactions, and button actions are keyboard accessible. Modal dialogs support focus trapping with escape-key dismissal. Date/time pickers use native inputs. Multi-step booking flows are fully keyboard navigable with proper focus management.
2.1.2 No Keyboard Trap	Supports	Users can navigate away from all components using the keyboard. Modal focus traps include escape-key dismissal to return focus to the triggering element.
2.1.4 Character Key Shortcuts	Not Applicable	The application does not implement single-character keyboard shortcuts.
2.2.1 Timing Adjustable	Supports	The application does not impose time limits on user interactions. Session timeouts follow Supabase authentication defaults and redirect gracefully to login.
2.2.2 Pause, Stop, Hide	Supports	Animations respect the prefers-reduced-motion media query. Staggered entrance animations, fade-ins, and animated counters are disabled or reduced when the user has indicated a preference for reduced motion.
2.3.1 Three Flashes or Below Threshold	Supports	No content flashes more than three times per second. Animations are subtle transitions (opacity, transform) that do not produce flashing effects.
2.4.1 Bypass Blocks	Supports	Landmark regions (header, nav, main, footer) are present on all pages. A skip-to-main-content link is implemented and verified on all routes. Main content areas have id="main-content" targets across all layouts.
2.4.2 Page Titled	Supports	Each page has a descriptive title. Dynamic pages include the studio name and context in the page title.
2.4.3 Focus Order	Supports	Focus order follows the logical reading and interaction sequence. Tab order matches the visual layout. Modal dialogs manage focus on open and return focus on close.
2.4.4 Link Purpose (In Context)	Supports	Links include descriptive text or are supplemented with aria-label attributes where the visible text alone may be ambiguous.
2.5.1 Pointer Gestures	Supports	All functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path-based gesture.
2.5.2 Pointer Cancellation	Supports	Actions are triggered on the up-event for all interactive elements, following standard browser behavior.
2.5.3 Label in Name	Supports	Visible labels for interactive controls match or are contained within their accessible names.
2.5.4 Motion Actuation	Not Applicable	The application does not use device motion or user motion for any functionality.
3.1.1 Language of Page	Supports	The HTML lang attribute is set to en on all pages.
3.2.1 On Focus	Supports	Receiving focus does not initiate a change of context. Focus events are used only for visual styling and assistive technology announcements.
3.2.2 On Input	Supports	Changing the setting of a form control does not automatically cause a change of context. Form submissions require explicit user action.
3.2.6 Consistent Help	Supports	Help mechanisms (support links, documentation links) are placed in a consistent location relative to other page content across the application.
3.3.1 Error Identification	Supports	Form validation errors are identified in text and associated with the relevant input field. Error messages describe the nature of the error.
3.3.2 Labels or Instructions	Supports	Form inputs include visible labels. Required fields are indicated. Placeholder text supplements but does not replace labels.
3.3.7 Redundant Entry	Supports	Information previously entered by or provided to the user that is required on the same or subsequent steps is auto-populated or available for selection. Users are not asked to re-enter the same information within multi-step flows.
4.1.1 Parsing	Not Applicable	WCAG 2.2: this criterion is always considered satisfied for content using HTML or XML.
4.1.2 Name, Role, Value	Supports	Standard HTML controls expose name, role, and value correctly. Custom widgets use ARIA attributes with correct roles, states, and properties. Combobox and multi-select patterns have been audited and corrected.

WCAG 2.2 Success Criteria — Level AA

Curated conformance assessments. Updated as compliance work progresses.

WCAG 2.2 Level AA conformance table
Criteria	Level	Remarks
1.2.4 Captions (Live)	Not Applicable	The application does not include live audio content.
1.2.5 Audio Description (Prerecorded)	Not Applicable	The application does not include prerecorded video content.
1.3.4 Orientation	Supports	Content is not restricted to a single display orientation. The application is fully responsive and functions in both portrait and landscape.
1.3.5 Identify Input Purpose	Supports	Input fields for common data types (name, email, phone, address, credit card via Stripe Elements) use appropriate autocomplete attributes.
1.4.3 Contrast (Minimum)	Supports	The design system meets WCAG AA contrast ratios. Text contrast: cream-600 at 5.48:1, placeholders at 4.83:1, prose links at 5.70:1 on white backgrounds. All verified across light and dark themes.
1.4.4 Resize Text	Supports	Text can be resized up to 200% without loss of content or functionality. The application uses relative units (rem) for typography.
1.4.5 Images of Text	Supports	The application does not use images of text to convey information. All text content is rendered as real text.
1.4.10 Reflow	Supports	Content reflows to a single column at 320 CSS pixels wide without horizontal scrolling.
1.4.11 Non-text Contrast	Supports	UI components and graphical objects meet the 3:1 contrast ratio. Input borders use cream-450 token (3.36:1 on white). Toggle tracks and checkbox borders updated to meet threshold.
1.4.12 Text Spacing	Supports	Content adapts when users override text spacing properties via user stylesheets or browser extensions.
1.4.13 Content on Hover or Focus	Supports	Tooltips and popover content that appear on hover or focus are dismissible, hoverable, and persistent.
2.4.5 Multiple Ways	Supports	Users can reach content through multiple methods: primary navigation, breadcrumbs, direct URLs, and search.
2.4.6 Headings and Labels	Supports	Headings describe the topic or purpose of the content they precede. Form labels clearly describe the purpose of their associated inputs.
2.4.7 Focus Visible	Supports	A visible focus indicator is present on all interactive elements. The design system implements custom focus ring styles that are visible in both light and dark themes.
2.4.11 Focus Not Obscured (Minimum)	Supports	When a UI component receives keyboard focus, it is not entirely hidden by author-created content. Scroll-padding (80px top/bottom) ensures focused elements clear sticky headers. Z-index hierarchy audited and verified.
2.5.7 Dragging Movements	Supports	All drag-based functionality provides single-pointer alternatives. Class preset reordering includes move-up/move-down button controls with accessible labels.
2.5.8 Target Size (Minimum)	Supports	Interactive targets are at least 24x24 CSS pixels. Icon-only buttons in modals, toasts, alerts, and search inputs have been verified and fixed to meet the minimum.
3.1.2 Language of Parts	Supports	The application is presented in English. No mixed-language content is present.
3.2.3 Consistent Navigation	Supports	Navigation mechanisms are consistent across pages within each context (dashboard, public studio pages, documentation site).
3.2.4 Consistent Identification	Supports	Components with the same functionality are identified consistently throughout the application.
3.3.3 Error Suggestion	Supports	When input errors are detected and suggestions for correction are known, the suggestions are provided to the user in text.
3.3.4 Error Prevention (Legal, Financial, Data)	Supports	For financial transactions, users review a summary before confirming. Destructive actions require explicit confirmation dialogs.
3.3.8 Accessible Authentication (Minimum)	Supports	Authentication does not require cognitive function tests. Login uses email/password with browser autofill support. Social login and magic-link alternatives are available. reCAPTCHA v3 runs in the background without user interaction.
4.1.3 Status Messages	Supports	Toast notifications use role="alert" for danger/warning and role="status" for success/info. Loading state transitions announce via aria-busy. Toast container uses role="region".

Notes

Testing approach: Automated axe-core scans run on every pull request via our CI pipeline. Manual keyboard and screen reader testing covers primary user flows. The live metrics above reflect the most recent automated scan.

Third-party components: Stripe payment forms and Checkout maintain their own accessibility compliance. Google reCAPTCHA v3 operates without user interaction.

Reporting issues: Users who encounter accessibility barriers are encouraged to contact us at support@studiobase.org. We respond within 5 business days.