Accessibility Conformance Report
Last updated: June 24, 2026
Report type: Self-assessed Accessibility Conformance Report based on the VPAT WCAG edition.
This report is not a third-party accessibility audit or legal certification. It is a good-faith self-assessment of the current Hero's Homeroom web application based on implementation review, manual keyboard testing, and accessibility readiness work.
Product Information
- Product name: Hero's Homeroom
- Product type: Web application
- Product URL: https://www.heroshomeroom.com
- Evaluation standard: WCAG 2.1 Level A and Level AA
- Contact: support@heroshomeroom.com
Scope
This report covers public pages, teacher sign-in and account creation, student sign-in, student-facing app pages, common classroom tools and displays, and core teacher daily workflow controls.
This report does not cover third-party services outside Hero's Homeroom, user-generated content entered by teachers or students, formal testing with every screen reader/browser/device combination, or a third-party audit.
Overall Summary
- WCAG 2.1 Level A: Partially Supports
- WCAG 2.1 Level AA: Partially Supports
The student-facing experience has received the strongest accessibility review. Teacher-side advanced tools include keyboard alternatives, but some visual and drag-heavy tools need deeper usability testing before claiming full app-wide conformance.
WCAG 2.1 Level A
| Criteria | Conformance | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Partially Supports | Core controls and student-facing item, pet, and equipment visuals include meaningful labels or are treated as decorative. Some complex game and teacher tool visuals require additional alt text review. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | Hero's Homeroom does not provide prerecorded audio-only or video-only instructional content. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | No prerecorded video content is provided. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | No prerecorded video content is provided. |
| 1.3.1 Info and Relationships | Partially Supports | Semantic headings, labels, tab roles, dialog roles, progress bars, and form associations are used across priority flows. Some teacher-side sections and custom visual tools require additional semantic review. |
| 1.3.2 Meaningful Sequence | Supports | App pages follow a logical DOM and reading order consistent with their visual presentation. |
| 1.3.3 Sensory Characteristics | Partially Supports | Student-critical information is not intended to rely solely on shape, position, color, or sound. Some classroom game displays are highly visual and require continued text-equivalent review. |
| 1.4.1 Use of Color | Partially Supports | Locked, unlocked, selected, wounded, reward, and status states include text or labels in priority areas. Some decorative or legacy states may rely on color alone and require further review. |
| 1.4.2 Audio Control | Supports | Teacher-triggered sound effects are short and user-initiated via a Sound toggle. The app does not auto-play long-running audio. |
| 2.1.1 Keyboard | Partially Supports | Student-facing routes and daily teacher controls are keyboard reachable. Drag-heavy tools include keyboard alternatives. Some advanced tool workflows require deeper keyboard usability testing. |
| 2.1.2 No Keyboard Trap | Supports | Priority modals include focus handling and Escape behavior. No intentional keyboard traps are present in the tested scope. |
| 2.1.4 Character Key Shortcuts | Supports | Custom keyboard shortcuts use modifier keys (Alt + Arrow) or standard navigation keys, reducing single-key shortcut conflicts. |
| 2.2.1 Timing Adjustable | Supports | Classroom timers and vote countdowns are teacher-controlled and can be adjusted or cancelled at any time. No content requires students to complete actions within an automatic, unadjustable time limit. |
| 2.2.2 Pause, Stop, Hide | Partially Supports | The app respects prefers-reduced-motion. Teacher-initiated classroom displays—including the spinner wheel and Boss Battle—involve animations that do not include an in-tool pause or stop control, which is the basis for this partial assessment. |
| 2.3.1 Three Flashes or Below Threshold | Supports | No content that flashes above the threshold is intentionally used. |
| 2.4.1 Bypass Blocks | Supports | A skip-to-content link is present globally. |
| 2.4.2 Page Titled | Supports | App routes include descriptive titles through the Next.js application shell. |
| 2.4.3 Focus Order | Partially Supports | Focus order is logical on student routes and common teacher controls. Drag-and-drop canvas tools may present challenges for strict sequential keyboard navigation. |
| 2.4.4 Link Purpose (In Context) | Supports | Public, navigation, and core app links describe their destination or action. |
| 2.5.1 Pointer Gestures | Supports | Core app interactions do not require complex pointer gestures. Drag-heavy tools include keyboard alternatives. |
| 2.5.2 Pointer Cancellation | Partially Supports | Standard buttons and controls use normal activation patterns. Custom drag interactions in canvas tools require additional pointer cancellation review. |
| 2.5.3 Label in Name | Partially Supports | Visible button and link labels generally match their accessible names. Icon-only controls include accessible names; compact toolbars warrant continued auditing. |
| 2.5.4 Motion Actuation | Not Applicable | The app does not require device motion or user motion actuation. |
| 3.1.1 Language of Page | Supports | The app is written in English and uses the correct document language attribute. |
| 3.2.1 On Focus | Supports | Receiving focus does not trigger a change of context. |
| 3.2.2 On Input | Supports | Changing a UI component's setting does not cause a context change. Live previews in editing tools update content within the same view, which is expected behavior for those tools. |
| 3.3.1 Error Identification | Partially Supports | Student login, auth, and priority forms include visible error messages and live regions. Some teacher forms may need additional error association review. |
| 3.3.2 Labels or Instructions | Partially Supports | Priority forms and controls have labels or instructions. Some compact icon-heavy tools may need further labeling review. |
| 4.1.1 Parsing | Supports | React and Next.js produce valid DOM for standard components. Custom interactive surfaces have been reviewed for structural validity. |
| 4.1.2 Name, Role, Value | Partially Supports | Priority controls expose names, roles, selected states, progress values, and dialog roles. Some advanced custom controls require continued review. |
WCAG 2.1 Level AA
| Criteria | Conformance | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | Hero's Homeroom does not provide live audio or video content. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | No prerecorded video content is provided. |
| 1.3.4 Orientation | Supports | The app does not lock orientation. Some classroom views are designed for larger screens and display a notice on small phone viewports. |
| 1.3.5 Identify Input Purpose | Supports | Auth fields use appropriate input types, labels, and autocomplete attributes. Student login fields (class code and PIN) do not collect personal data and have no applicable WCAG autocomplete category. |
| 1.4.3 Contrast (Minimum) | Partially Supports | Text and interactive element contrast meets minimum ratios in priority areas. A full automated and manual contrast audit across custom game and tool surfaces is recommended. |
| 1.4.4 Resize Text | Partially Supports | Layouts use responsive CSS and scalable text. Some dense game and tool surfaces require testing at 200 percent zoom. |
| 1.4.5 Images of Text | Supports | The app uses real text for labels and content. Logos and decorative assets are exceptions. |
| 1.4.10 Reflow | Partially Supports | Public and student pages are responsive. Classroom tool pages are designed for tablets and computers and display a notice on small phone viewports. Some teacher tools require additional zoom and reflow testing. |
| 1.4.11 Non-text Contrast | Partially Supports | Focus indicators, selected states, and toggle controls meet non-text contrast requirements in priority areas. A full review of custom game and tool controls is recommended. |
| 1.4.12 Text Spacing | Partially Supports | Most pages accommodate standard text spacing adjustments. Dense custom tool surfaces have not been fully tested with modified user styles. |
| 1.4.13 Content on Hover or Focus | Partially Supports | Hover-revealed controls in the Whiteboard tool are also accessible on keyboard focus. Other hover-triggered content should continue to be reviewed as the tool set evolves. |
| 2.4.5 Multiple Ways | Supports | Public pages and app areas are reachable through navigation, direct links, and route-based access. |
| 2.4.6 Headings and Labels | Partially Supports | Public pages, legal pages, and priority app flows use meaningful headings and labels. Some tool panels require additional heading review. |
| 2.4.7 Focus Visible | Supports | A visible focus indicator is present on all interactive elements, with context-appropriate variants for dark-themed surfaces and the classroom Sound toggle. |
| 2.5.5 Target Size | Partially Supports | Most controls meet practical classroom target sizes. Some compact icon controls and dense tool surfaces require review against target size expectations. |
| 3.1.2 Language of Parts | Supports | No mixed-language content requiring language attribute changes is used. |
| 3.2.3 Consistent Navigation | Supports | Public and app navigation are consistent across comparable pages. |
| 3.2.4 Consistent Identification | Supports | Repeated controls—including login, demo, shop tabs, inventory tabs, and footer links—use consistent labels and identification. |
| 3.3.3 Error Suggestion | Partially Supports | Priority login and form errors describe what went wrong. Some teacher tool error states may benefit from additional corrective guidance. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Partially Supports | Destructive actions such as class and student deletion use explicit confirmation steps. Future billing, data export, or irreversible bulk actions should include equivalent safeguards. |
| 4.1.3 Status Messages | Partially Supports | Live regions announce dynamic updates across key student and teacher flows, including login results, vote interactions, grouping changes, and game state transitions. Some teacher workflow areas may benefit from additional announcements. |
Hero's Homeroom