Technology exists to amplify human potential. With the possibilities we have today, creating products that serve a diverse group of users should be inherent. If this is true, why are there so many accessibility requirements for digital products? Because they are still not met in too many cases.
The main reason for that is legacy software. Simply put, old code was never written with accessibility in mind. This created a great challenge for companies to meet the requirements. I’ve been testing Möbius since 2013 and I’ve experienced the struggle firsthand. One of the main issues with a monolithic codebase is that it can become increasingly difficult to maintain as the application grows in size and complexity. With time, it became harder for us to add new features, fix bugs, and deploy updates without breaking existing functionality and introducing new accessibility issues.
While still working with a legacy codebase, we have made every effort to ensure that Möbius is accessible to all users. Since late 2020, we have been compliant with WCAG 2.1 AA and have been using it as our minimum standard.
The areas of improvement include:
- Header hierarchy across the platform
- Alt-text for programmatically generated plots in student learning and assessment materials
- Changes to 2D math for a better screen reader experience
Each Möbius release undergoes a rigorous testing procedure using the most popular accessibility tools (screen readers, magnifying software, etc.). We aim to deliver consistent behaviour across all supported browsers.
Another contributing factor to poor accessibility is that the software industry is not taking the idea of accessible digital products far enough. Since microservice architecture emerged, many companies have had every opportunity to embrace the advantages of a more flexible codebase structure and create truly delightful and inclusive products. Some did. Others followed the strategy of “move fast and break things” that proved to deliver fast results. It felt fresh, inspiring, and innovative, but it generally omitted the concept of an inclusive product. In the 10 years of working in software development, I’ve rarely seen a case where a team produced a substandard feature, then went back to fix it. No one does that. By the time a feature is released, the business moves on to create more and more offerings. There is no time to go back and polish what’s already there. Although it’s clear now just how risky and unsustainable this strategy is, it lingers on, often resulting in bad user experience, security vulnerabilities, and WCAG compliance issues.
At DigitalEd, we are taking a different path. We do not build our platform to simply meet accessibility requirements. We build our platform for every user to have a great experience. Starting in 2023, we are embarking on a journey to reimagine the Möbius experience. As part of the plan, we have adopted an inclusive design development model while ensuring that our code can easily adapt to changing accessibility requirements and can utilize the benefits of new tools and technology.
Our Voluntary Product Accessibility Template (VPAT) contains the most recent update on platform accessibility.