Accessibility is a promise we’re keeping.

The World Wide Web Consortium (W3C)’s Web Accessibility Initiative (WAI) states accessibility addresses discriminatory aspects related to equivalent user experience for people with disabilities. Web accessibility means that people with disabilities can equally perceive, understand, navigate, and interact with websites and tools. It also means that they can contribute equally without barriers.

Actively building and managing the Corteza platform, it quickly became apparent that we’re not 100% following our mission and dream of building a Digital Work Platform for Humanity if we don’t address the accessibility requirements and make our product usable and available to everyone.

Honestly, I initially underestimated the challenge of thinking following common design principles and basing our UI on the well established Bootstrap framework is more or less good enough. In fairness, the approach built a solid foundation, but the work surely didn’t end there.

After some extra reading on the topic, our real accessibility journey started after engaging with The Accessibility Foundation, the centre of expertise in digital accessibility based in the Netherlands. They assessed the platform and provided an evaluation document outlining how much of the application is compliant with the Web Content Accessibility Guidelines (WCAG) 2.1 requirements.

The report luckily confirmed we did some things right already. At the same time, it was an eye-opening experience, providing us with a bit more insight into the real-life scenarios we needed to cover (such as 500% browser zoom-in). We realized we’re not taking advantage of the available options, for example, the `sr-only` class offered in Bootstrap by default, which hides elements on all devices except screen readers and is a powerful way to provide additional context for visually impaired individuals.

Getting educated and start using all available frameworks seems like a small price to pay if it means it can make someone’s life at least a little easier.

One thing is crystal clear — accessibility is a constant requirement. We can never consider accessibility work to be “completed”. We incorporated accessibility requirements into every internal product-related process — from product planning, designing, development to testing. We’re determined to master the field.

We don’t plan to stop here. We don’t want only to enable the disabled community to use Corteza, but eventually to have careers in building and administering Low-Code applications. In other words, we want to take the concept of inclusive design as far as it can go with Corteza in economic and social terms.