Accessibility Report
p5play is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.
Conformance Status
The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA.
p5play.org is conformant with WCAG 2.1 Level AA, with the exception of dynamic content rendered within HTML5 Canvases.
Keyboard-Only Navigation
p5play.org can be accessed entirely through keyboard-only navigation.
Note that the interactive code editors on the Learn pages trap the Tab key, which is used for
indentation. To exit the editor and move to the next focusable element, press Esc. To move to the
previous element, press Shift + Tab.
Compatibility with Browsers and Assistive Technology
Accessibility of p5play relies on a web browser to work with the particular combination of assistive technologies or plugins installed on your computer
p5play is designed to be compatible with Modern web browsers (Google Chrome, Firefox, Safari, Edge) on Windows, macOS, and Linux.
Limitations and Alternatives
Despite our best efforts to ensure accessibility of p5play, there may be some limitations. Below is a description of known limitations. Please contact us if you observe an issue not listed below.
Canvas Elements: The p5play game engine renders content to an HTML5 Canvas. Content within the canvas (sprites, game objects) is not automatically accessible to screen readers. Developers using p5play are responsible for implementing accessibility features solely within their games, such as keyboard controls and audio cues.
Feedback
We welcome your feedback on the accessibility of p5play. Please let us know if you encounter accessibility barriers on p5play:
- E-mail: info@p5play.org
- GitHub Issues: Report on GitHub
WCAG 2.1 AA Compliance Checklist
Principle 1: Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
| Success Criterion | Level | Status | Remarks & Evidence |
|---|---|---|---|
| 1.1.1 Non-text Content All non-text content (images, etc.) has a text alternative. |
A | Partially Supports | - Most static UI images have alt tags.- Known Issue: Dynamic Canvas content (games) does not automatically have alt text. - Action: Ensure all img tags in
the textbook have meaningful alt text. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | A | Not Applicable | No audio-only or video-only content is currently hosted on the site. |
| 1.2.2 Captions (Prerecorded) | A | Not Applicable | No prerecorded video content with audio. |
| 1.2.3 Audio Description or Media Alternative | A | Not Applicable | No prerecorded video content. |
| 1.2.4 Captions (Live) | AA | Not Applicable | No live audio content in synchronized media. |
| 1.2.5 Audio Description (Prerecorded) | AA | Not Applicable | No prerecorded video content. |
| 1.3.1 Info and Relationships Information, structure, and relationships conveyed through presentation can be programmatically determined. |
A | Supports | - Semantic HTML (nav, main, h1-h6,
article, footer) is used.- Form labels are associated with inputs. |
| 1.3.2 Meaningful Sequence | A | Supports | DOM order matches visual order. CSS Flexbox is used for layout but preserves logical reading order. |
| 1.3.3 Sensory Characteristics | A | Supports | Instructions do not rely solely on shape, size, or visual location (e.g., "click the round button"). |
| 1.3.4 Orientation (2.1) | AA | Supports | Site is responsive and works in both landscape and portrait orientations. |
| 1.3.5 Identify Input Purpose (2.1) | AA | Supports | Standard HTML input types (email, password, date) are used,
allowing browser autocomplete to function. |
| 1.4.1 Use of Color | A | Supports | Color is not the only means of conveying information. Links are underlined or distinct in context. Errors in forms usually have text descriptions. |
| 1.4.2 Audio Control | A | Supports | Site does not autoplay audio. |
| 1.4.3 Contrast (Minimum) | AA | Supports | - Dark mode text colors are high contrast. - Code blocks use syntax highlighting; ensure these meet 4.5:1 against the dark background. |
| 1.4.4 Resize Text | AA | Supports | Site scales correctly when using browser zoom up to 200%. |
| 1.4.5 Images of Text | AA | Supports | Most text is actual HTML text, not images. Exception: Some brand logos. |
| 1.4.10 Reflow (2.1) | AA | Supports | Content reflows into a single column at 320px width without horizontal scrolling (Responsive design). |
| 1.4.11 Non-text Contrast (2.1) | AA | Supports | UI components (buttons, inputs) and graphical objects have sufficient contrast. - Check: Verify custom focus rings (Pink/Blue) meet 3:1 contrast against background. |
| 1.4.12 Text Spacing (2.1) | AA | Supports | No fixed heights on text containers that would break if users adjust text spacing. |
| 1.4.13 Content on Hover or Focus (2.1) | AA | Supports | Tooltips/menus are dismissible and persistent. |
Principle 2: Operable
User interface components and navigation must be operable.
| Success Criterion | Level | Status | Remarks & Evidence |
|---|---|---|---|
| 2.1.1 Keyboard | A | Supports | - All standard navigation, links, and forms are keyboard accessible. - Fix Implemented: Ace Editor traps Tab, but provides Esc / Shift+Tab to escape.
|
| 2.1.2 No Keyboard Trap | A | Supports | - Fix Implemented: Ace Editor trap resolved via custom key bindings. |
| 2.1.4 Character Key Shortcuts (2.1) | A | Supports | Single key shortcuts (if any) are modifiable or active only when a specific component has focus. |
| 2.2.1 Timing Adjustable | A | Supports | No time limits on reading content or forms. |
| 2.2.2 Pause, Stop, Hide | A | Supports | Animated content (if any loop > 5s) has controls? (Check homepage banners). |
| 2.3.1 Three Flashes or Below Threshold | A | Supports | No content flashes more than 3 times per second. |
| 2.4.1 Bypass Blocks | A | Supports | - Fix Implemented: "Skip to content" links added to all main templates. |
| 2.4.2 Page Titled | A | Supports | Pages have unique elements (e.g., "p5play : Sprite"). |
| 2.4.3 Focus Order | A | Supports | Focus moves sequentially through relevant content. |
| 2.4.4 Link Purpose (In Context) | A | Supports | Link text is descriptive or understandable from context. |
| 2.4.5 Multiple Ways | AA | Supports | Users can find pages via Navigation menu, Search bar, or Sitemap links. |
| 2.4.6 Headings and Labels | AA | Supports | Headings (h1, h2) describe topic or purpose. Form inputs have labels. |
| 2.4.7 Focus Visible | AA | Supports | - Fix Implemented: Global CSS ensures visible focus indicators (outline/ring) on all interactive elements. |
| 2.5.1 Pointer Gestures (2.1) | A | Supports | Multipoint or path-based gestures are not required for operation; standard single-pointer clicks are sufficient. |
| 2.5.2 Pointer Cancellation (2.1) | A | Supports | Execution of functions is on the up-event (click/tap release), or can be aborted/undone. |
| 2.5.3 Label in Name (2.1) | A | Supports | Accessible names of buttons and links match their visible labels. |
| 2.5.4 Motion Actuation (2.1) | A | Not Applicable | Functions are not triggered by device motion (shaking/tilting). |
Principle 3: Understandable
Information and the operation of user interface must be understandable.
| Success Criterion | Level | Status | Remarks & Evidence |
|---|---|---|---|
| 3.1.1 Language of Page | A | Supports | html tag has lang="en" (or es, ja for localized
versions). |
| 3.1.2 Language of Parts | AA | Supports | Content is primarily in English. No foreign language phrases requiring tagging are present. |
| 3.2.1 On Focus | A | Supports | Focusing on a component does not trigger a context change (like submitting a form or opening a new window) automatically. |
| 3.2.2 On Input | A | Supports | Changing settings (like Dark Mode) does not cause confusing context changes. |
| 3.2.3 Consistent Navigation | AA | Supports | Top navigation bar is consistent across all subpages. |
| 3.2.4 Consistent Identification | AA | Supports | Icons and buttons with the same functionality are identified consistently. |
| 3.3.1 Error Identification | A | Supports | Form validation (Signup/Login) clearly identifies errors in text. |
| 3.3.2 Labels or Instructions | A | Supports | Instructions are provided for ensuring correct input (e.g., password rules). |
| 3.3.3 Error Suggestion | AA | Supports | Where possible, suggestions for correction are provided. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Supports | Account changes likely require confirmation or are reversible? (Check account deletion flow). |
Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
| Success Criterion | Level | Status | Remarks & Evidence |
|---|---|---|---|
| 4.1.1 Parsing | A | Supports | - HTML is validated. IDs are unique. - Note: WCAG 2.2 deprecates this, but kept for 2.1 compliance. |
| 4.1.2 Name, Role, Value | A | Supports | - Custom UI components (like the mini-editor buttons) use standard HTML buttons or valid ARIA
attributes. - Canvas elements are the main exception here regarding internal "Role" of game objects. |
| 4.1.3 Status Messages (2.1) | AA | Supports | Dynamic content updates (like "Saved", "Loading") should be announced via aria-live or
similar if critical. |
Assessment Approach
p5play assessed the accessibility of this website by the following approaches:
- Self-evaluation
This statement was created on January 11, 2026.