Ludwig VS: The Accessibility Tool You Didn’t Know You Needed
So I have an embarrassing code-centered confession to make. I was churning out bits of HTML and CSS to create websites for friends and acquaintances years before I even understood what Javascript was and what I could do with it. From the start, HTML was beginner-friendly, and the resources for learning it were plentiful and varied. Frankly, even though HTML is not considered a programming “language” by any metric, it is commonly one of the first encounters a software developer might have with building something from scratch. However, just because it is an “easy” programming skill to pick up does not mean there isn’t a lot to consider when coding HTML successfully, specifically when it pertains to meeting accessibility standards.
The Problem: As the Internet Grows, The Percentage of Accessible Websites Shrink
According to Monsido, in 2022, 90% of websites were considered inaccessible, and 98.2% had WCAG 2 failures. The World Health Organization (WHO) estimates one in six people will manage a disability during their lifetime. We often overlook accessibility in the development process, and developers are under-resourced to meet both the current and future demand for application accessibility. Most software developers, even those specializing in front-end, will not have the necessary expertise of all the requirements to ensure an application meets the minimum standards for ARIA accessibility. Spending hours researching and parsing through each line in an entire codebase to make sure it is accessible takes valuable time away from creating new features or even moving on to a brand-new project.
With accessibility being such a vital part of the front-end developmental process, our entire project team searched for what tools already existed in this space to combat this specific predicament. Among the resources we discovered that software engineers were using to test the front end, none of them were open-source. Plenty of them provided good test coverage, at times even calculating an accessibility score and preparing it as a downloadable report. The downside? It appeared that these tools were only able to be used on a finished, rendered web application. This meant that if critical non-compliance issues were found at this stage of the developmental process, it could set back the production stage if the required rewrites were extensive enough. That solution did not appear to be optimal from our perspective.
So the Ludwig team went to the drawing board with questions. Questions like “What if we could make a tool that could test a codebase from the very first day of the development process?” and “Would it be possible to build a parser that would serve as an additional extension to the coding tools we already use daily?” All of us here at Ludwig use Visual Studio Code as our preferred text editor, and use the ESLint extension to catch syntax errors and make sure we are formatting our code to the expected standard. Would it be possible for us to devise a perfect collaboration between creating a testing tool that would parse in real time so the developer could correct errors the instant they arise and also make sure this tool was available in an easy-to-access and user-friendly format? Determined, we developed a plan and set to building a solution.
Meet Ludwig: The Tool to Make Accessibility More Accessible
Ludwig is a Visual Studio Code extension that can be toggled on and off on the activity bar as well as being activated using the designated command palette command “Ludwig: Compose”. It utilizes the VSCode API to access the active HTML document tab being used when Ludwig is toggled on. This gives a developer options on how to best incorporate Ludwig into their workflow; either have it toggled on during live coding to catch errors in the moment, or simply activate at the end during code review to identify any problems to address in the future.
Any HTML elements that are not up to ARIA accessibility standards are highlighted with a bright red line covering the entire line of code where the issue resides. When a user hovers over the indicated element, a hover bar pops up with more information concerning what needs to be changed to bring that specific element up to standard. Along with detailed information about the highlighted issue, the Read More option at the bottom of the hover bar also provides a direct link to the relevant documentation outlining the cited problem and providing additional information. This gives the user quick access to the needed resources without devoting hours of research to finding the answers themselves on how to fix a given issue.
In addition, Ludwig provides a side panel that can be accessed by clicking on its logo icon in the activity bar. Once opened, the side panel displays a button to scan the active HTML document. When clicked, Ludwig parses through the document, compiles the errors into a comprehensive list, and returns an overall score for the developer to gauge and improve their web content’s accessibility.. The dashboard also presents the user with an organized table summarizing the exact line number in the active HTML document where an issue was identified, along with a brief description of said issue, recommendations to resolve it, and a link to the pertinent documentation.
A key benefit to using Ludwig is the additional security benefit it provides. Ludwig provides a contained ecosystem for developers to use as there is no required step to upload any files or provide outside access to your codebase. Rather, Ludwig only parses code on a developer’s personal text editor which means that a software engineer can be sure that they are being provided relevant ARIA accessible testing coverage for their code while keeping it contained within their local machine or Github repository. Ludwig does not require you to share access to any of your code and does not have the capability to store any copies. This is particularly relevant if a developer is working on a project requiring increased security or special access to be able to view the codebase.
Looking Ahead: Goals for The Future
Ludwig is currently in beta, and there are plenty of exciting features we are planning to add in the future. First off, we are aiming to provide testing coverage for all ARIA standards, and we are also composing a strategy to produce tailored recommendations to meet ARIA compliance. Another feature we are excited to add is expanding Ludwig’s accessibility testing capability to cover both .jsx and .tsx files to enable support for React components. Furthermore, we would love to create tests that evaluate the contrast between the text and foreground elements against the background. This would also include identifying key indicators that rely on color distinction, ensuring that they are visible to individuals with color vision deficiency.
If you would like to contribute to our project, please reference the contribution guidelines outlined in Ludwig’s official README. Additionally, if you have any questions about Ludwig or would like to chat with any of the team members, please reach out using the links below!
Ludwig Development Team
Tyler Spicer | github | linkedin
Jake Johnson | github | linkedin
Connie Johnson | github | linkedin