Voluntary Product Accessibility Template (VPAT®)
WCAG 2.1 Conformance Report — Version 2.4 Rev
Product Information
Table 1: WCAG 2.1 Level A
| Criteria | Conformance Level | Remarks / Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | All meaningful images include descriptive alt text. Decorative images use aria-hidden="true" or empty alt attributes. Icons within interactive elements have accessible labels. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Partially Supports | Podcast briefings provide full text transcript equivalents. Voice AI mock interview audio currently lacks a text-based alternative; a text transcript feature is planned. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | The application does not include prerecorded synchronized video content. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | The application does not include prerecorded synchronized video content. |
| 1.3.1 Info and Relationships | Supports | Semantic HTML is used throughout. Proper heading hierarchy is validated by axe-core. Form inputs are associated with labels. Tables include headers. ARIA landmarks define page regions. |
| 1.3.2 Meaningful Sequence | Supports | DOM order matches visual reading order across all pages. CSS layout does not alter logical content sequence. |
| 1.3.3 Sensory Characteristics | Supports | Instructions do not rely solely on shape, size, visual location, orientation, or sound. Color-coded elements always include text labels or icons. |
| 1.4.1 Use of Color | Supports | Color is never the sole means of conveying information. Status indicators, form errors, and score meters all include text or icon supplements. |
| 1.4.2 Audio Control | Supports | No audio plays automatically. Podcast playback and voice AI features require explicit user initiation and provide pause/stop controls. |
| 2.1.1 Keyboard | Supports | All interactive elements (buttons, links, form controls, modals, menus) are reachable and operable via keyboard. Custom components follow ARIA Authoring Practices. |
| 2.1.2 No Keyboard Trap | Supports | Focus is not trapped in any component. Modal dialogs return focus to the triggering element on close. The Escape key dismisses overlays. |
| 2.1.4 Character Key Shortcuts | Not Applicable | The application does not implement single-character key shortcuts. |
| 2.2.1 Timing Adjustable | Supports | No time limits are imposed on user interactions. Session tokens refresh automatically. |
| 2.2.2 Pause, Stop, Hide | Supports | No auto-scrolling, blinking, or auto-updating content is present. Background shape animations respect prefers-reduced-motion: reduce. |
| 2.3.1 Three Flashes or Below Threshold | Supports | No content flashes more than three times per second. All animations are gradual transitions. |
| 2.4.1 Bypass Blocks | Supports | Skip navigation links are present on every page. ARIA landmarks (main, nav, contentinfo) provide additional bypass mechanisms. |
| 2.4.2 Page Titled | Supports | Every page has a unique, descriptive <title> element that identifies the page purpose and site name. |
| 2.4.3 Focus Order | Supports | Tab order follows the logical reading sequence. Modal dialogs trap focus appropriately and restore it on close. |
| 2.4.4 Link Purpose (In Context) | Supports | Link text describes the destination or purpose. Where link text alone is ambiguous, surrounding context or aria-label provides clarity. |
| 2.5.1 Pointer Gestures | Supports | No multipoint or path-based gestures are required. All functionality is operable with single-point activation. |
| 2.5.2 Pointer Cancellation | Supports | Actions activate on the up-event (click/touch release). Users can move the pointer away to cancel activation. |
| 2.5.3 Label in Name | Supports | Accessible names of interactive elements contain the visible label text. Voice control users can activate controls by speaking the visible label. |
| 2.5.4 Motion Actuation | Not Applicable | No functionality is triggered by device motion or user motion. |
| 3.1.1 Language of Page | Supports | All pages declare lang="en" on the <html> element. |
| 3.2.1 On Focus | Supports | No context changes occur on focus. Focusing a form field or interactive element does not trigger navigation or submission. |
| 3.2.2 On Input | Supports | Changing a form setting does not automatically trigger context changes. Form submissions require explicit user action (button click). |
| 3.3.1 Error Identification | Supports | Form validation errors are identified in text, associated with the relevant field, and announced to assistive technologies via aria-describedby and live regions. |
| 3.3.2 Labels or Instructions | Supports | All form inputs have visible labels. Required fields are indicated. Placeholder text supplements but does not replace labels. Autocomplete attributes are set on identity fields. |
| 4.1.1 Parsing | Supports | HTML is well-formed with no duplicate IDs on the same page. Automated validation is part of the build process. |
| 4.1.2 Name, Role, Value | Supports | Custom components use appropriate ARIA roles, states, and properties. Native HTML elements are used wherever possible. Screen readers can programmatically determine the name, role, and state of all interface components. |
| 4.1.3 Status Messages | Supports | Status messages (success notifications, error counts, progress updates) use role="status" or aria-live="polite" to announce changes without moving focus. |
Table 2: WCAG 2.1 Level AA
| Criteria | Conformance Level | Remarks / Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | The application does not include live synchronized media content. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | The application does not include prerecorded synchronized video content. |
| 1.3.4 Orientation | Supports | Content is not restricted to a single display orientation. All pages function in both portrait and landscape modes. |
| 1.3.5 Identify Input Purpose | Supports | Form fields collecting personal information use appropriate autocomplete attributes (e.g., name, email, tel) to support browser autofill and assistive technology personalization. |
| 1.4.3 Contrast (Minimum) | Supports | Normal text meets a 4.5:1 contrast ratio. Large text meets a 3:1 contrast ratio. Both light and dark themes have been verified. |
| 1.4.4 Resize Text | Supports | Text can be resized up to 200% without loss of content or functionality. Layouts use relative units and responsive breakpoints. |
| 1.4.5 Images of Text | Supports | Text is rendered as actual text, not as images. The logo is the only image containing text and is supplemented with an alt attribute. |
| 1.4.10 Reflow | Supports | Content reflows to a single column at 320 CSS pixels width without horizontal scrolling. Responsive design ensures usability at all viewport sizes. |
| 1.4.11 Non-text Contrast | Supports | UI components (buttons, form field borders, icons) and graphical objects maintain at least a 3:1 contrast ratio against adjacent colors in both themes. |
| 1.4.12 Text Spacing | Supports | Content remains readable and functional when users override line height (1.5x), paragraph spacing (2x), letter spacing (0.12em), and word spacing (0.16em). |
| 1.4.13 Content on Hover or Focus | Supports | Tooltips and popovers that appear on hover/focus are dismissible (via Escape), hoverable (pointer can move to the tooltip), and persistent (remain visible until dismissed or focus moves). |
| 2.4.5 Multiple Ways | Supports | Users can locate pages via navigation menus, the site footer, the help center, and direct URL entry. A sitemap is available. |
| 2.4.6 Headings and Labels | Supports | Headings describe the content they precede. Form labels clearly describe the expected input. Heading hierarchy is validated by axe-core. |
| 2.4.7 Focus Visible | Supports | All interactive elements display a visible focus indicator using :focus-visible with sufficient contrast against the background in both light and dark themes. |
| 3.1.2 Language of Parts | Supports | The application is presented in English. Any content in a different language would be marked with the appropriate lang attribute. |
| 3.2.3 Consistent Navigation | Supports | Navigation mechanisms appear in the same relative order on every page. The site footer is consistent across all pages. |
| 3.2.4 Consistent Identification | Supports | Components with the same functionality are identified consistently throughout the application (e.g., "Print," "Save," "Generate" actions). |
| 3.3.3 Error Suggestion | Supports | When input errors are detected, descriptive suggestions for correction are provided in text (e.g., "Please enter a valid email address" rather than a generic "Invalid input"). |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Subscription changes and account deletion require explicit confirmation. Payment processing is handled by Stripe with its own confirmation step. Users can review inputs before submitting. |
Known Limitations
The following areas have identified limitations that are actively being addressed:
- AI-Generated Content: Resume outputs, cover letters, and news briefings produced by the Gemini AI engine are generated as prose text. While the surrounding application UI is fully accessible, the AI-generated content itself may not always use optimal heading structures or semantic markup for screen reader navigation. We are working to improve post-processing of AI outputs to enhance structure and readability for assistive technologies.
- Voice AI Mock Interview: The voice-based mock interview feature currently operates as an audio-only interaction. A text-based alternative (live transcript and text-input mode) is planned for a future release.
- Third-Party Embedded Content (Stripe): Payment forms are embedded via Stripe Elements. Stripe maintains its own VPAT and accessibility conformance. While Stripe Elements generally support keyboard navigation and screen readers, TailorMeSwiftly cannot guarantee or control the accessibility of Stripe-hosted iframes.
- PDF Exports: PDF document exports are currently under evaluation for accessibility tagging (PDF/UA compliance). Exported PDFs may not include proper heading tags, reading order, or alt text. We recommend using the on-screen HTML version for the most accessible experience.
Accessibility Features Summary
- Semantic HTML5 with validated heading hierarchy (axe-core automated testing)
- ARIA landmarks and labels; all content contained within landmark regions
- Skip navigation links on every page
- Full keyboard navigability; all interactive elements reachable via Tab/Shift+Tab/Enter/Space/Arrow keys
- Visible focus indicators (
:focus-visible) with sufficient contrast - Color contrast ratios meeting WCAG AA thresholds (4.5:1 normal text, 3:1 large text) in both light and dark themes
- Text resizable to 200% without content loss or horizontal scrolling
- Alt text for all meaningful images; decorative images marked
aria-hidden - Form labels, descriptive error messages, and
autocompleteattributes - No content flashing more than three times per second
prefers-reduced-motion: reducemedia query support for motion-sensitive users- Minimum 44×44 CSS pixel touch targets for all interactive elements
- Screen reader utility class (
.sr-only) for visually hidden but accessible content - Section 508 compliance (Revised Section 508 Standards)
Contact
For questions about this VPAT, to request accessibility accommodations, or to report an accessibility issue, contact:
Tailored Services LLC