Accessibility Conformance Report
WCAG Edition
(Based on VPAT® Version 2.5Rev)
- Name of Product/Version: Knoword (Web Application)
- Report Date: May 25, 2026
- Product Description: Knoword is an online educational word game and literacy platform. It features interactive single-player gameplay, user-generated content creation tools, and student progress tracking for educators.
- Contact Information: Knoword Support (via our Contact Form)
- Notes: This document reports on the accessibility conformance of our digital content, platform features, and public website.
Evaluation Methods Used
The platform was evaluated using a combination of manual testing, keyboard-only navigation workflows, web browser developer utilities, and automated accessibility scanning engines (including Axe and WAVE). Testing was conducted by team members with a thorough knowledge of general product functionality alongside digital accessibility guidelines.
Applicable Standards / Guidelines
This report covers the degree of conformance for the following digital accessibility 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
The terms used in the Conformance Level column are defined as follows:
- 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
Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.0 Conformance Requirements.
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) | Supports | Informative images/icons include descriptive alt text; decorative graphics are hidden from assistive tech. Audio and color cues for game feedback (correct/incorrect states) are paired with text descriptions and assertive aria-live announcements. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Not Applicable | The application does not host, stream, or utilize any prerecorded audio-only or video-only media content. |
| 1.2.2 Captions (Prerecorded) (Level A) | Not Applicable | The application does not contain any prerecorded synchronized multimedia (video with audio) that would require captions. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Not Applicable | The application does not include prerecorded synchronized multimedia, therefore audio descriptions or alternative media representations are not required. |
| 1.3.1 Info and Relationships (Level A) | Supports | Structural layout uses semantic HTML5 landmarks (<main>, <nav>) and sequential heading levels. Game inputs use explicit aria-label or id/for label bounds, and related study items or card elements are grouped programmatically using standard lists. |
| 1.3.2 Meaningful Sequence (Level A) | Supports | DOM source code order directly mirrors the visual interface layout. Information, definitions, and gameplay inputs read in a logical, sequentially coherent progression when style sheets are deactivated or viewports change. |
| 1.3.3 Sensory Characteristics (Level A) | Supports | Instructions and layout elements do not rely exclusively on shape, size, visual location, or sound to convey direction; all interactive cues are accompanied by explicit text labels. |
| 1.4.1 Use of Color (Level A) | Supports | Color is never used as the exclusive visual means to convey status, errors, or interface transitions; all color-coded states are accompanied by explicit text descriptions. |
| 1.4.2 Audio Control (Level A) | Supports | Sound effects are strictly episodic and last under 3 seconds; toggles to disable audio feedback are built directly into the game UI and in-game menus. |
| 2.1.1 Keyboard (Level A) | Supports | All platform navigation, menu configurations, and interactive game loop controls are fully operable using standard keyboard inputs (Tab, Enter, Spacebar). |
| 2.1.2 No Keyboard Trap (Level A) | Supports | Focus management ensures that keyboard focus can be moved into and out of all interactive elements, modals, and in-game menus seamlessly without trapping the user. |
| 2.1.4 Character Key Shortcuts (Level A) | Supports | Standard shortcuts utilize modifier keys across the majority of the application. Where single-character number keys (1, 2, 3) are mapped to selection mechanics in multiple-choice gameplay, a user setting is provided to require a modifier key combo (Alt/Option), ensuring safety for voice dictation users. |
| 2.2.1 Timing Adjustable (Level A) | Supports | Game and study configurations allow users or instructors to adjust, extend, or entirely deactivate gameplay countdown timers and time limits. |
| 2.2.2 Pause, Stop, Hide (Level A) | Supports | Interface animations do not feature continuous looping over 5 seconds, and all moving elements automatically respect native system-level prefers-reduced-motion settings. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Supports | Platform interfaces, visual game states, and screen transitions contain no flashing, blinking, or strobing frequencies that exceed safe visual thresholds. |
| 2.4.1 Bypass Blocks (Level A) | Supports | A functional, keyboard-accessible skip-navigation link is embedded at the top of the page structures to allow rapid bypass of global header blocks. |
| 2.4.2 Page Titled (Level A) | Supports | Every distinct platform view and routing context dynamically updates with a unique, descriptive HTML <title> tag defining the specific page content. |
| 2.4.3 Focus Order (Level A) | Supports | Pressing the Tab key moves your selection through the page elements in a natural, logical order from top to bottom, perfectly matching the visual layout of the screen. |
| 2.4.4 Link Purpose (In Context) (Level A) | Supports | Link text is always written to clearly describe its destination or purpose, ensuring users know exactly where a link goes without relying on vague or ambiguous phrasing. |
| 2.5.1 Pointer Gestures (Level A) | Supports | The platform does not require any multi-touch or path-based pointer gestures (like pinching to zoom or swiping to navigate). All standard navigation and gameplay can be operated with simple clicks and taps. |
| 2.5.2 Pointer Cancellation (Level A) | Supports | Clicking or tapping buttons fires actions only when the user releases the click, allowing them to cancel an accidental press by dragging away before letting go. |
| 2.5.3 Label in Name (Level A) | Supports | The platform primarily uses native HTML <label for="..."> tags for forms and standard text within buttons. This ensures that the programmatic accessible name automatically and perfectly matches the visual text displayed on the screen. |
| 2.5.4 Motion Actuation (Level A) | Supports | The application does not use device motion, tilting, or shaking to trigger any functions or gameplay mechanics; all actions are controlled through standard touch, mouse clicks, or keyboard entry. |
| 3.1.1 Language of Page (Level A) | Supports | The root element dynamically updates its language attribute to match the user’s currently selected locale, establishing the correct default language for the global layout and navigation menus. |
| 3.2.1 On Focus (Level A) | Supports | Moving keyboard focus to any interactive element or input field only highlights the item; it never triggers an automatic change of context, navigation, or form submission. |
| 3.2.2 On Input (Level A) | Supports | Changing the value of any form control, dropdown selection, or checkbox does not automatically trigger an unexpected change of context, navigation, or automatic form submission. |
| 3.2.6 Consistent Help (Level A) | Supports | Support and self-help mechanisms (such as links to contact information, FAQs, and guides) are integrated directly into global templates, ensuring they appear in a strictly consistent relative order across all pages. |
| 3.3.1 Error Identification (Level A) | Supports | Input errors are automatically detected and clearly described to the user via explicit contextual text messages, ensuring errors do not rely on visual cues or color changes alone. |
| 3.3.2 Labels or Instructions (Level A) | Supports | Clear, persistent labels and explicit text instructions or formatting constraints are provided for all form inputs and user data entry fields. |
| 3.3.7 Redundant Entry (Level A) | Supports | The application does not require repetitive data entry within a single multi-step task; previously entered information is securely retained, carried forward, or automatically populated. |
| 4.1.1 Parsing (Level A) | Supports | For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata. |
| 4.1.2 Name, Role, Value (Level A) | Supports | The application utilizes semantic HTML elements and ARIA attributes where appropriate, ensuring that assistive technologies can accurately identify the name, role, and current state of all interactive user interface controls. |
Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | The platform does not host, broadcast, or transmit live streaming media or real-time video events. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | The platform does not utilize or embed pre-recorded video content requiring descriptive audio tracks. |
| 1.3.4 Orientation (Level AA) | Supports | Responsive CSS layouts adapt smoothly across both portrait and landscape viewports, ensuring content and core gameplay mechanics are never locked or constrained to a single device orientation. |
| 1.3.5 Identify Input Purpose (Level AA) | Supports | Login and registration inputs use native autocomplete attributes. This helps browsers and password managers correctly identify each field and auto-fill the user’s information. |
| 1.4.3 Contrast (Minimum) (Level AA) | Supports | Main text elements and UI labels use high-contrast color choices that meet the standard 4.5:1 contrast ratio against their backgrounds. |
| 1.4.4 Resize text (Level AA) | Supports | The interface handles browser text zooming up to 200% without breaking layouts, overlapping text, or losing any features. |
| 1.4.5 Images of Text (Level AA) | Supports | The platform uses real text styled with CSS instead of flattening text into static images, ensuring all copy can be scaled, highlighted, and read by assistive tools. |
| 1.4.10 Reflow (Level AA) | Supports | Responsive design layouts wrap and stack content vertically down to a 320px width, preventing the need for horizontal scrolling on small screens or high zoom levels. |
| 1.4.11 Non-text Contrast (Level AA) | Supports | Visual boundaries for interactive elements, input fields, and keyboard focus states maintain a contrast ratio of at least 3:1 against adjacent background colors. |
| 1.4.12 Text Spacing (Level AA) | Supports | Container elements use flexible layouts that allow text to expand naturally without clipping or overlapping if a user increases letter, word, or line spacing through custom styles. |
| 1.4.13 Content on Hover or Focus (Level AA) | Partially Supports | Tooltips remain visible while focusing on the trigger element, but they cannot currently be dismissed using the Esc key and may disappear if the mouse pointer moves directly over the tooltip content. |
| 2.4.5 Multiple Ways (Level AA) | Supports | Users can locate pages across the site using multiple paths, including the main navigation menus, internal search features, and footer links. |
| 2.4.6 Headings and Labels (Level AA) | Supports | Page headings and form labels are descriptive, clearly identifying the purpose of each section and input field across the application. |
| 2.4.7 Focus Visible (Level AA) | Supports | Interactive elements show a distinct, high-visibility focus outline when navigated using a keyboard, ensuring the active selection is always easy to track. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA) | Supports | Sticky or fixed UI elements do not fully obscure interactive items when they receive keyboard focus; the application ensures focused elements remain visible within the viewport. |
| 2.5.7 Dragging Movements (Level AA) | Partially Supports | While audio scrubbers and general interface components support single-pointer click alternatives, certain drag-and-drop gameplay interactions currently require dragging movements or keyboard controls, and cannot be fully operated via single pointer clicks alone. |
| 2.5.8 Target Size (Minimum) (Level AA) | Supports | Interactive components and target elements maintain a minimum size of 24 by 24 pixels, or include sufficient surrounding spacing to prevent accidental activation of adjacent controls. |
| 3.1.2 Language of Parts (Level AA) | Supports | When the main page content is in a different language than the user’s selected global header locale, the main content containers explicitly use localized language attributes (such as lang="en") to ensure screen readers seamlessly switch pronunciation profiles. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | Global navigation menus, headers, and footers maintain a strictly consistent layout and structural order across all routes and pages of the application. |
| 3.2.4 Consistent Identification (Level AA) | Supports | Interactive components and utility features that appear across multiple contexts (such as search inputs, settings controls, and navigation buttons) use completely consistent labels and functional naming conventions. |
| 3.3.3 Error Suggestion (Level AA) | Supports | Input error messages provide explicit, actionable text suggestions and formatting criteria to guide the user on exactly how to resolve validation failures. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Supports | Destructive actions (such as deleting user-generated word packs or managing account subscription details) require explicit user confirmation steps to prevent accidental data loss or unintended transactions. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA) | Supports | Authentication processes do not rely on mandatory cognitive function tests; login inputs completely support standard browser auto-fill, third-party password managers, and copy-and-paste functionality. |
| 4.1.3 Status Messages (Level AA) | Supports | Dynamic updates, success notifications, and validation error messages are announced to assistive technologies via ARIA live regions without requiring a page reload or shifting user focus. |
Legal Disclaimer
This document is provided for informational purposes only. Our organization makes no warranties, express or implied, in this summary report. The information contained herein represents the current view of the platform as of the date of publication and is subject to evolution as ongoing features and security enhancements are rolled out.