Accessibility statement

FlyHigh is designed so that students, faculty, and staff with disabilities can perceive, understand, navigate, and interact with every part of the platform. Accessibility is treated as a functional requirement in design and engineering review, not as a remediation step after release.

We build against the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, which is the technical standard referenced by Section 508 of the Rehabilitation Act (36 CFR Part 1194) for information and communication technology. Our target is full conformance across authenticated and public screens.

Conformance is a continuous engineering commitment. Newly released features are reviewed against the same standard before they reach institutional tenants.

• Semantic HTML landmarks and a single main region per page
• A skip-to-main-content link on every screen
• Full keyboard operability with no keyboard traps
• Visible, high-contrast focus indicators
• Text contrast meeting or exceeding 4.5:1
• Information never conveyed by color alone
• Accessible names on all icon-only controls
• Form fields with programmatically associated labels
• Errors announced in text, not only by color
• Live regions for dynamic status messages
• Reduced-motion support honoring system preferences
• Captions and transcripts for live classes and recordings
• Tap targets sized for motor accessibility on mobile
• Responsive layouts that reflow without horizontal scrolling

Testing combines automated rule checking during development with manual review: keyboard-only navigation, screen reader passes, contrast verification, text resizing to 200%, and zoom to 400% reflow. Instructor-authored content is checked by accessibility guidance built into the course builder.

Institutions and instructors can upload their own documents, videos, and links. FlyHigh provides captioning tools, alt-text prompts, and authoring guidance, but the accessibility of uploaded course materials remains the responsibility of the institution that publishes them. We work with disability services teams to remediate reported materials.

Where a specific interface has an outstanding barrier, we document it, provide an equivalent alternative path to the same task, and publish a remediation timeline to the affected institution. Current limitations for a given release are included in the release documentation available to institutional administrators.

A Voluntary Product Accessibility Template (VPAT) prepared against the current release is provided to institutions on request during procurement or contract renewal. Contact us to request the document for your review cycle.

If you encounter a barrier anywhere in FlyHigh, tell us. Include the page, what you were trying to do, and the assistive technology and browser you were using. We acknowledge reports within two business days and provide a remediation plan or an equivalent alternative within ten business days.