Our Accessibility Policy

AESOP AI Academy is committed to making our learning platform usable by everyone, including people with disabilities. We believe that digital accessibility is not an afterthought — it's a core part of building a learning platform that truly serves all students.

Our goal is to meet or exceed WCAG 2.1 Level AA (Web Content Accessibility Guidelines) across learner-facing and public-facing pages. This is the technical standard adopted by the U.S. Department of Justice under ADA Title II for state and local government web content and mobile apps, and we use it as our internal benchmark for AESOP as an education platform.

We recognize that accessibility is an ongoing practice, not a one-time checkbox. We continuously test, improve, and respond to feedback from our community.

Our target conformance level is WCAG 2.1 Level AA, which covers four key principles:

• Perceivable — content can be presented in ways that all users can perceive (text alternatives for images, captions, sufficient color contrast)
• Operable — interface components and navigation are operable by everyone (keyboard access, no time traps, no seizure-inducing content)
• Understandable — information and interface operation are clear (readable text, predictable navigation, input assistance)
• Robust — content can be interpreted reliably by assistive technologies (valid HTML, proper ARIA attributes, semantic markup)

We also reference Section 508 of the Rehabilitation Act, ADA Title II, ADA Title III, and common institutional procurement expectations as guiding frameworks. Where a partner, school, district, agency, grant, or signed agreement requires a higher standard, that requirement controls for that deployment.

This page is written for the practical legal environment AESOP operates in, especially because our users may include parents, learners, schools, public institutions, nonprofits, and workforce programs.

• ADA Title II: State and local governments, including public schools and public universities, must provide accessible services, programs, and activities. The 2024 DOJ web and mobile-app rule uses WCAG 2.1 Level AA as the technical standard for covered public entities, with compliance dates now extended to April 26, 2027 for entities serving populations of 50,000 or more and April 26, 2028 for smaller public entities and special district governments.
• ADA Title III: Businesses open to the public must provide full and equal access to their goods, services, privileges, and advantages. DOJ guidance says this includes online goods and services, even though Title III does not currently set one detailed web technical standard the way the Title II web rule does.
• Section 508: Federal agencies and many federally connected procurement processes use Section 508 accessibility standards. AESOP tracks Section 508 because schools, agencies, and institutional buyers often ask vendors for accessibility evidence.
• Institutional procurement: Schools, districts, colleges, agencies, and employers may require WCAG conformance, accessibility remediation timelines, VPAT documentation, assistive-technology testing, or alternate formats as contract conditions.

Our operating rule is simple: build to WCAG 2.1 AA, test with both automated and manual methods, document known limitations, respond quickly to barriers, and provide an accessible alternative when a barrier cannot be fixed immediately.

Here's what we've implemented across the platform today:

• Semantic HTML — all pages use proper heading hierarchy, landmark regions (<nav>, <main>, <footer>), and meaningful link text
• Keyboard navigation — every interactive element (menus, accordions, buttons, forms) is reachable and operable via keyboard alone
• Color contrast — text and interactive elements meet WCAG AA contrast ratios (minimum 4.5:1 for normal text, 3:1 for large text)
• Dark mode — a system-wide dark theme that maintains accessibility standards and reduces eye strain
• Responsive design — all pages reflow properly at up to 400% zoom and across screen sizes from mobile to desktop
• Focus indicators — visible focus outlines on all interactive elements for keyboard and switch-device users
• No auto-playing media — audio and video content does not auto-play; users control playback
• Text alternatives — images include descriptive alt attributes; decorative images are marked appropriately

Because our lessons use AI-generated content, we take extra care to ensure that generated material is accessible:

• AI-generated text is rendered as standard HTML that screen readers can parse natively
• Story content uses clear, plain language appropriate for the selected difficulty level
• Interactive choices and quiz options are keyboard-operable and announced by assistive technology
• We do not generate content that relies solely on color, images, or spatial positioning to convey meaning

If AI-generated content ever creates an accessibility barrier for you, please let us know — we can often provide an alternative format or fix the issue quickly.

We're honest about where gaps remain. Here are areas we're actively improving:

• Third-party embeds — some embedded content (Discord widget, external video) may not fully meet AA standards; we're working with those providers or finding alternatives
• PDF certificates — downloadable certificates are being updated to include proper tagging for screen readers
• Comprehensive ARIA coverage — while core interactive components use ARIA, we're auditing all dynamic content (modals, live regions, notifications) for completeness
• Formal VPAT — we don't yet have a Voluntary Product Accessibility Template (VPAT); this is planned for later in 2026

We maintain an internal accessibility backlog and prioritize fixes based on user impact. If you encounter a specific barrier, reporting it moves it to the top of that list.

We use a combination of automated and manual testing:

• Automated scans — Lighthouse and axe-core run against all pages to catch common WCAG violations
• Manual keyboard testing — every new feature is tested with keyboard-only navigation before release
• Screen reader testing — we test with NVDA (Windows) and VoiceOver (macOS/iOS) on a regular cadence
• Color contrast checks — design changes are validated against WCAG AA ratios using automated tools

We're working toward adding user testing with assistive-technology users as the platform grows.

If you encounter an accessibility barrier or need content in an alternative format, we want to hear from you. Here's how:

• Use our Report Issue form and select "Accessibility" as the topic
• Describe what you were trying to do, what barrier you encountered, and what assistive technology you're using (if applicable)
• We aim to respond within 3 business days and provide a workaround or fix within 10 business days for most issues

You can also reach us through our Discord community if you prefer a more immediate conversation.

Accessibility standards and best practices evolve. We review this policy at least every six months, and immediately whenever:

• We add a major new feature or content type to the platform
• A relevant regulation changes (ADA Title II, Section 508, state accessibility laws)
• WCAG publishes a new version (we'll evaluate upgrading our target conformance level)
• A user reports a significant accessibility barrier we hadn't identified