Transforming documents into an accessible alternative.

Dutch government organizations are required to make their online communications comply with WCAG standards under the Dutch Decree on Digital Accessibility. This includes PDF and similar documents published on their websites or mobile applications. However, creating compliant documents requires extensive manual work, accessibility knowledge and significant investment.

Compliance barriers

Most government workers lack this expertise, forcing them to rely on expensive software or external consultants. The result? Many organizations struggle to meet legal requirements. Leaving many users unable to access essential government information. With large sums of documents already in circulation and new ones published daily, the scale and impact of the challenge is substantial.

To address these challenges, I worked together with a multidisciplinary team of 7 people to develop a concept that would help government organizations meet accessibility requirements. The freedom of starting from scratch allowed us to thoroughly research user needs and design a solution that aligns with real-world workflows rather than enforcing new ones.

Designing an accessible alternative

Our research revealed a fundamental tension: organizations need to maintain their original documents for legal validity and brand consistency, yet these documents are often inaccessible. Rather than forcing organizations to choose between accessibility and their existing practices, we focused on a different approach: creating an accessible alternative.

The concept centers on providing a HTML alternative to an inaccessible document. This way, the original document remains untouched for legal or branding purposes, while users who depend on accessible content can access the same information without barriers. The application needed to make this process feasible for users with limited accessibility knowledge while significantly reducing the time and costs involved in making content accessible.

Building an automated solution

NLdoc simplifies this process through three steps: it converts the content from a document to HTML, checks for accessibility issues and then guides users through the manual refinements needed to ensure full WCAG compliance.

NLdoc bridges the gap between automated conversion, validation and human refinement. The editor provides contextual guidance and editing tools that prevent common accessibility mistakes, making document accessibility achievable for users at any skill level.

Rather than overwhelming users with technical requirements, the interface provides three tools that work together: a rich text editor that prevents new accessibility errors, a document overview that visualizes the impact of changes and an assistant that translates WCAG requirements into plain language.

Once the content meets all accessibility requirements, NLdoc generates a plain HTML file that works on any platform. Organizations simply publish these accessible alternatives alongside their original documents, ensuring compliance without changing their existing infrastructure.

NLdoc's rich text editor minimizes the possibility of accidentally creating accessibility issues. The interface exposes only formatting options that comply with WCAG standards, preventing common mistakes like using underlines for emphasis or creating heading hierarchies beyond level 6.

The editor provides real-time feedback through visual 'findings' indicators, highlighting both validation findings from the original document and any new accessibility issues created during editing. Errors identify content that fails WCAG requirements, warnings request verification of automated interpretations and suggestions recommend improvements that enhance readability for all users.

In December 2025, after 3 years of development, NLdoc was released as open source via GitLab (opens in new tab). Organizations can implement the complete platform, including the conversion API, validation API and editor, in their own infrastructure, customizing it to their specific needs. The architecture supports both API integration for bulk processing and the editor interface for individual document editing.