Accessibility has always mattered. But after the Department of Justice’s ruling clarifying WCAG 2.1 AA as the standard for digital accessibility, the conversation shifted. For software companies, especially those serving higher education and public institutions, accessibility moved from “important” to “essential”.
While the rule brings welcome clarity, it also brings complexity. Accessibility compliance is not a static goal, and it is not something institutions can solve alone. It requires ongoing collaboration with software vendors who understand both the standards and the realities of building accessible technology in modern, ever-changing environments.
Compliance Is Not a Finish Line
In reality, accessibility is an ongoing process. Even software that conforms to WCAG success criteria can surface minor bugs, regressions, or edge cases over time. Differences across browsers, devices, operating systems, and assistive technologies are not only possible, they are expected.
Accessibility exists in the real world, not a controlled test environment. Acknowledging that reality does not weaken a compliance claim. It reflects a more honest and mature understanding of what accessibility actually requires.
Part of this misunderstanding comes from how accessibility conformance is evaluated. VPATs are based on testing across representative browsers, devices, and assistive technologies, not every possible combination. As a result, compliant software may still behave differently in specific environments as technologies continue to evolve.
The Reality of Building Accessible Software Today
Modern higher education software operates across a complex ecosystem:
- Multiple browsers and versions
- Desktop and mobile devices
- Mobile websites and applications
- A wide range of assistive technologies, each interpreting content differently
Testing across these combinations is difficult, even for experienced teams. In our experience, when a vendor claims there are no accessibility issues at all, it often signals limited or infrequent testing, particularly with assistive technology.
Even for teams deeply committed to accessibility, testing requires expertise, repetition, and humility. Understanding how screen readers, keyboard navigation, and other tools behave takes time, especially for people who do not rely on them every day.
This is why accessibility cannot be treated as something you add at the end of development. It requires a fundamental shift in process.
Compliance Does Not Always Equal Usability
Another important nuance is the difference between technical compliance and real-world usability.
Software can meet WCAG success criteria and still be difficult to use in practice. Truly accessible products require:
- Ongoing usability testing with assistive technology
- Feedback from real users
- A willingness to revisit and refine experiences over time
Sometimes, making something accessible means it looks or behaves differently than what a sighted user might initially expect. Product teams constantly balance aesthetics, interaction patterns, and accessibility requirements. Not every workaround is appropriate, and not every visually ideal solution is accessible. These tradeoffs are part of responsible accessibility work.
What This Means for Higher Education Institutions
For institutions navigating accessibility after the Title II rule, accessibility is now clearly a shared responsibility.
Public institutions are ultimately responsible for meeting Title II requirements, but vendors play a critical role in enabling that success. At the same time, many accessibility outcomes are influenced by institutional choices, including:
- Configuration decisions
- Content creation and management
- Feature enablement or disablement
This is why accessibility cannot be evaluated solely by a checkbox or a single document. Institutions need vendors who are willing to have honest conversations about what compliance looks like in practice.
How to Identify a Vendor You Can Trust
When evaluating accessibility claims, there are several signals that often indicate a deeper, more reliable commitment:
- They describe accessibility as ongoing work, not a one-time achievement
- They acknowledge complexity, including edge cases and limitations
- They can explain how accessibility is tested on every release
- They understand the difference between compliance and usability
- They are transparent about what is vendor-controlled versus institution-controlled
- They welcome feedback and issue reporting as part of partnership, not failure
Be cautious of vendors who promise perfection, seamless behavior across every environment, or zero known issues. Accessibility work done well is iterative, honest, and grounded in real-world use.
Where We Stand
At Concept3D, we’ve spent the last several years deeply investing in accessibility across our products. That’s something we’re proud of. And it’s also something we talk about very intentionally.
Accessibility is embedded into how we design, build, and release our products. We are comfortable partnering with our customers on their accessibility and compliance challenges. Our VPAT reflects WCAG 2.1 Level AA conformance across our core products, with some products already aligned to WCAG 2.2.
More importantly, accessibility is tested on every release, evaluated continuously, and treated as a shared responsibility with our customers. We know there are areas where we can still improve; that there are areas we need to improve. That awareness is not a weakness. It is a requirement.
Moving Forward
The DOJ’s Title II final rule raised the bar, but it also created an opportunity. Institutions and vendors now have a clearer framework for working together to build more inclusive digital experiences.
Compliance is not perfection. Accessibility is about commitment, not claims.
The organizations doing this work well are the ones willing to be honest about the challenges and stay engaged long after an audit or VPAT is complete.