Accessibility at Korus
Korus is built so that every student has an equal opportunity to be heard. We design and develop our platform to meet the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, and we treat accessibility as a continuous engineering responsibility — not a one-time audit.
Conformance target
Korus targets conformance with WCAG 2.1 Level AA, the standard most widely referenced by U.S. higher-education institutions and U.S. federal procurement requirements (Section 508). A Voluntary Product Accessibility Template (VPAT / Accessibility Conformance Report) is available to institutional customers and procurement teams on request.
Perceivable
Sufficient color contrast, scalable text, descriptive labels and alt text, and survey content that is readable by screen readers.
Operable
Full keyboard navigation, visible focus indicators, no keyboard traps, and interactions that do not depend on a mouse or specific gestures.
Understandable
Plain language in student-facing surveys and disclosures, consistent navigation, and clear error messages with guidance on how to fix issues.
Robust
Semantic HTML, standards-compliant markup, and ARIA used where appropriate so the platform works with current and future assistive technologies.
Compatibility
Korus is designed to work with the assistive technology and browser configurations students and staff actually use:
- Modern versions of Chrome, Edge, Firefox, and Safari on desktop and mobile.
- Screen readers including JAWS, NVDA, VoiceOver (macOS and iOS), and TalkBack (Android).
- Operating system zoom and browser zoom up to 200% without loss of content or functionality.
- Reduced-motion settings — non-essential animation respects the user's prefers-reduced-motion preference.
- Dark mode and high-contrast viewing modes.
Ongoing efforts
Accessibility is part of how we build, not something we revisit only at audit time.
- Automated accessibility scanning is part of our build and release process.
- Manual keyboard and screen reader testing is performed on student-facing flows for every release.
- We track and prioritize accessibility issues alongside functional defects, not as a separate backlog.
- New components are reviewed against WCAG 2.1 AA before being released to production.
Known limitations
No software product is perfectly accessible at all times. When we discover an accessibility issue, we document it, prioritize remediation, and communicate the status to customers who ask. Where third-party components fall short of our standard, we work with the vendor or replace the component.
Report an accessibility issue
If you encounter a barrier using Korus — as a student, faculty member, administrator, or procurement reviewer — please tell us. We treat accessibility reports as high-priority. When you contact us, include:
- The page or feature where you encountered the issue
- The assistive technology, browser, and operating system you were using
- A description of what you expected and what happened
Email support@heykorus.com with subject "Accessibility Report." We aim to acknowledge accessibility reports within two business days.
For VPAT / ACR documentation, procurement language, or to discuss specific accommodations for your campus, contact support@heykorus.com. See also our Trust & Security page.
This statement was last reviewed on June 24, 2026.