Seite 3: Continuous Integration and Accessibility

Inhaltsverzeichnis

Continuous integration (CI) is a practice that involves regularly integrating code changes into a shared repository, ensuring that the code is always in a releasable state. Incorporating accessibility checks into the CI pipeline helps ensure that accessibility issues are caught early, preventing them from reaching production. There are several ways to include accessibility checks into a CI pipeline, depending on the applied tools and services.

• AccessLint and axe Linter for GitHub Actions review code changes in pull requests and leave comments on any newfound accessibility issues based on the axe-core assertions. The team just needs to make the resolution of comments obligatory for a merge, and voilà—the (partial) accessibility automation is born! The only caveat: It is available for free only for personal open-source projects.
• In general, it is possible to use GitHub Actions, GitLab CI, Jenkins, and further CI/CD services to create a custom workflow that includes accessibility checks using tools like Lighthouse CI, axe-linter-action, accessibility-insights-scan, or Pa11y. Linters and automated test tools mentioned in the previous sections can be part of it as well. A comprehensive example is shown in Adrián Bolonio’s article "Automating the accessibility tests of your source code with GitHub Actions."

Integrating accessibility checks into the CI/CD pipeline is crucial for catching issues early and maintaining an inclusive user experience. However, it is important to consider the potential impact on performance, such as commit to publish (C2P) time. Initial implementations of automated accessibility tests may negatively affect C2P, with execution times more than doubling for some tests. To minimize the impact on performance, assertions should be deliberate and scoped to specific screen segments, focusing on high-traffic, high-impact transaction paths. It is essential to remember that 100 percent accessibility test coverage is not the goal; Tests are just one tool in the overall accessibility toolbox. Optimized configuration settings, omitting non-performant low-impact rules, and distributed test jobs can significantly improve performance. Alternatively, dedicated jobs can run assertions in parallel, preserving C2P time and maintaining a smooth CI/CD pipeline while still ensuring the accessibility of a given web application.

What’s Next? From Doing to Understanding

All tools and solutions described so far were based on the assumption stated at the beginning: Many teams lack internal know-how regarding accessibility requirements and best practices. This is easy to address with workshops, courses, e-learnings, etc. There are plenty of free resources that save the project budget. The most well-known ones include:

• The MDN Accessibility Learning Area
• Learn Accessibility by Google Developers
• Digital Accessibility Foundations by the W3C Web Accessibility Initiative

Browser extensions and linters offer initial guidance on web accessibility, but correct interpretation of results is crucial. These tools excel at syntax checks but follow a "one size fits all" approach. For instance, while alt attributes should not be empty, not all images require them. Decorative images do not contribute content and should therefore not be announced. Stubbornly following audit action items can worsen screen-reader user experience.

Understanding ARIA roles, labels, and attributes is crucial for accessibility. As the ARIA Authoring Practices Guide (APG) states, "No ARIA is better than Bad ARIA." Misusing ARIA can severely impact the user experience, such as improperly adding a role to a <div> tag without implementing the expected keyboard interactions.

Lacking understanding of accessibility requirements also means that developers may be unaware of essential features that could enhance the user experience. For instance, "skip to content" is a valuable accessibility feature that allows users who rely on keyboard navigation to bypass repetitive navigation elements and directly access the main content of a page.

Additionally, knowing how to navigate and interpret WCAG is of great assistance since it is widely regarded as the gold standard for web accessibility. Alongside the requirements, WCAG also offers valuable techniques and best practices that facilitate compliance. For example, the "2.4 Navigable" guideline features a success criterion with the associated technique H25: "Providing a title using the title element." This technique supplies a code snippet and test scenarios to streamline implementation.

Educating the team is a more sustainable approach than installing linters and integrating accessibility into a CI/CD pipeline, yet it is not the last step. Embracing an inclusive design process in all its facets requires changes in the business mindset and has enormous transformational power. This, however, would go beyond the scope of this article.