Accessibility-First Design
Our teams incorporate accessibility considerations early in the design process so that usability for all users is addressed before development begins. Accessibility is a core criterion in our design reviews, not a post-launch checklist item.
Accessible Component Library
Our engineering teams build on a shared component library with accessibility at the forefront—from buttons and form fields to data tables and interactive charts. This design system approach helps us deliver consistent, accessible behavior across our product suite and reduce the risk of accessibility regressions as features evolve.
Universal Design Principles
We apply universal design thinking that goes beyond minimum compliance. Our products are designed to be intuitive and usable for the widest possible range of people, regardless of ability or how they choose to interact with our platform.
Shared Accountability
We view accessibility as a shared responsibility—both within our organization and between HelioCampus and the institutions we serve. With the 2024 DOJ ADA Title II rule now requiring WCAG conformance for public entity digital content, institutions bear legal responsibility for the accessibility of third-party tools they adopt. We take that seriously. HelioCampus is committed to being a vendor partner that helps institutions meet their compliance obligations, and we work alongside our clients to ensure that accessibility is a collaborative effort—not a burden carried alone.
Training & Education
Structured accessibility training is available to every member of our product and engineering team through our partnership with a leading digital accessibility firm. Courses span accessibility fundamentals, ARIA implementation, screen reader testing, and inclusive design patterns. Training opportunities are not limited to a one-time onboarding event—our teams have access to ongoing sessions, webinars, and hands-on workshops to stay current as standards evolve and new techniques emerge. Accessibility awareness training is available to all new employees during onboarding, with additional specialized training offered to those involved in product development.
Accessibility as Policy
At HelioCampus, accessibility is not left to individual judgment—it is codified in our engineering standards. Our accessibility processes are documented in our internal knowledge base, and the majority of accessibility auditing happens during active development—before a feature ever reaches QA. Engineers use browser-based accessibility tools and AI-powered code audits against WCAG standards to identify and resolve issues as they build. When we evaluate third-party libraries or tools for integration into our platform, accessibility conformance is a deciding factor—not an afterthought.
Testing & Quality Assurance
Our QA approach pairs automated scanning with hands-on evaluation. Automated tools flag common issues during development, while our engineers validate real-world usability by navigating features with screen readers and keyboard-only input. We test across multiple browser and assistive technology pairings—including Chrome with NVDA, Safari with VoiceOver, and Firefox with NVDA—and supplement these efforts with AI-powered code analysis to surface issues that manual review alone might miss.
Dedicated Expertise & Third-Party Auditing
Accessibility at HelioCampus is championed by dedicated team members who guide and consult across product, engineering, and design. We also partner with an industry-leading digital accessibility firm for independent evaluation, expert remediation guidance, and ongoing conformance monitoring.
Issue Management & Feedback Resolution
When an accessibility barrier is reported—whether by a user, an institutional partner, or our own testing—it enters our engineering backlog with the same severity classification we apply to security and performance defects. We provide interim workarounds where possible so no one is blocked while a permanent fix is in progress, and we keep affected stakeholders informed as remediation moves forward. Accessibility bugs are never deprioritized behind feature work.
Continuous Improvement
Accessibility is not a one-time project—it is a long-term commitment. We continuously invest in improving accessibility across our products through regular auditing, prioritized remediation, and a forward-looking accessibility roadmap informed by user feedback, audit findings, and evolving WCAG standards. As standards advance, our products advance with them.
WCAG 2.2 Level AA
Our primary standard for accessibility. WCAG 2.2 Level AA includes 55 success criteria covering perceivability, operability, understandability, and robustness of web content, with additional criteria for focus not obscured, dragging movements, and consistent help. We continuously invest in improving our conformance with this standard.
Section 508
Federal accessibility requirements that apply to information and communication technology. The Revised Section 508 Standards incorporate WCAG 2.0 Level AA by reference. Our products target WCAG 2.2 Level AA-which includes and goes beyond the WCAG 2.0 AA criteria that Section 508 references-and our WCAG-based ACRs document conformance against those success criteria, the technical standards most relevant to Section 508 evaluations of web-based software.
Americans with Disabilities Act
The ADA prohibits discrimination against individuals with disabilities. The 2024 Title II rule references WCAG 2.1 AA as the enforceable technical standard—HelioCampus targets WCAG 2.2 AA and is continuously improving conformance.
Screen Readers
Our products are designed and tested for compatibility with commonly used screen readers. We prioritize proper semantic markup, ARIA labeling, and logical reading order so that screen reader users receive a meaningful experience when navigating dashboards, reports, and assessment workflows.
Keyboard Navigation
Interactive elements in our platform—including menus, data filters, form controls, and modal dialogs—are designed to be operable via keyboard alone. We implement visible focus indicators, logical tab order, and keyboard shortcuts so that users who cannot use a mouse can navigate our products efficiently, and we continue to expand keyboard support as our products evolve.
Semantic HTML & ARIA
Assistive technologies depend on well-structured markup to convey meaning, and we build with that in mind. Our interfaces use semantic HTML elements—headings, landmarks, lists, and tables—to give screen readers and other tools a clear map of each page. Where native HTML falls short for dynamic content, we apply WAI-ARIA roles, states, and properties so that live updates, expandable panels, and interactive widgets are announced and navigable. This foundation is what makes the rest of our accessibility work possible.
Color Contrast & Visual Design
We design our interfaces to meet or exceed WCAG 2.2 color contrast requirements—a minimum 4.5:1 ratio for normal text and 3:1 for large text and UI components. Our products use colorblind-safe palettes for data visualizations and never rely on color alone to convey meaning. These practices ensure that dashboards, reports, and interactive elements remain clear and usable for users with low vision or color vision deficiencies.
Documented in ACRs
Where a product has an ACR, known accessibility limitations are documented in that report, along with a remediation timeline. Our ACRs provide a candid, detailed account of what conforms, what partially conforms, and what is planned for future releases—giving institutions the information they need for procurement decisions.
Workarounds & Support
If you encounter an accessibility barrier while using any HelioCampus product, our support team can recommend applicable workarounds while a permanent fix is being developed. We prioritize accessibility issues in our engineering pipeline and provide regular updates on remediation progress. No user should be blocked from completing critical tasks due to an accessibility gap.
Listening, learning, and
building together
Our commitment to accessibility is strengthened by the people who use our products every day. We actively seek feedback from users with disabilities, accessibility coordinators, and institutional stakeholders to ensure our products reflect the real needs of the higher education community.
If you encounter an accessibility barrier, have suggestions for improvement, or would like to participate in user feedback sessions, we want to hear from you. We aim to respond to all accessibility inquiries within two business days.
