Practical Accessibility in Web Development

Inhaltsverzeichnis

(Dieser Artikel ist auch auf Deutsch verfügbar.)

In July 2021, Germany enacted the Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG), which puts the European Accessibility Act (EAA) into action. Estonia, Italy and Denmark have already introduced similar laws, and other EU countries will follow. The BFSG defines accessibility requirements for products and services that enter the European market or are provided to consumers after June 28, 2025. This includes, among other things, the entire e-commerce sector, hardware and software, but also national passenger transport or banking services.

Besides being an important and necessary step towards making the web more accessible for all, the EAA can pose a real threat in the case of non-compliance. If a product or service does not meet the requirements for accessibility, Germany's market surveillance authorities (Marktüberwachungsbehörden) can order its recall or discontinuation. In addition, fines of up to EUR 100,000 can be imposed. Exceptions exist only for small businesses with less than ten employees, annual sales of less than two million euros, or an annual balance sheet total of less than two million euros.

The state of web accessibility and IT projects shortly before 2025 is likely to be as follows:

• Many IT projects are already running or are just about to start without a dedicated accessibility budget, meaning that the product's inclusivity is to be achieved at low cost—in terms of money and mental effort.
• Teams do not yet have the necessary accessibility know-how. Ideally, the tooling should therefore provide guidance even to a novice.

It should be noted that accessibility is a practice, not a feature. "You do it once, and then you have it" is a myth. This means that developers should tend to accessibility regularly, both when working on new features and during maintenance. While there are several accessibility checklists available, it is unlikely that self-audit practices will stick, unless they are automated or well-integrated into the development process.

Furthermore, it is currently an unrealistic expectation to make a website one hundred percent accessible. Web accessibility is a continuum, which is why developers should not treat it with a "sink or swim" attitude. Instead, the focus should be on whether websites are more or less accessible. Every single step that makes a website more inclusive is worth taking—and talking about.

Based on this reasoning, there are some pragmatic tips and tricks web developers can employ to help integrate accessibility features into their daily coding routine. It includes low-hanging fruit to be harvested right now at nearly no cost. The following tools will not make a website completely accessible, and yet, as the saying goes, the journey is the reward.

Browsing for Inclusivity: Accessibility Audits Made Easy With Extensions

There are two aspects that turn manual accessibility testing into an expensive and tedious endeavor: First, testers require knowledge about all requirements, and second, they have to go through the entire website line by line to find accessibility violations. To significantly reduce the effort, browser extensions are here to help.

One of them is Lighthouse, mostly known for its performance analysis. However, developers can also use it to evaluate and enhance web accessibility. Integrated directly into Google Chrome, Lighthouse allows developers to assess their websites for potential accessibility issues and gain insights into areas that require improvement.

Once the audit is complete, Lighthouse will present a comprehensive report that includes an accessibility score, a list of successfully passed audits, and specific recommendations for addressing any identified issues (see info box "Lighthouse"). The suggestions are based on Web Content Accessibility Guidelines (WCAG) (see info box "WCAG") and weighted based on the impact on the user. Some of the critical rules include:

• [user-scalable="no"] is not present in the <meta name="viewport"> element, and the [maximum-scale] attribute is not below 5. If the website violates this rule, it means it disables zooming or limits how far the user can zoom in on the website's content. This is problematic for people with low vision who rely on screen magnifiers to view the content.

• <video> elements contain a <track> element with the attribute [kind="captions"] to display captions. This check is relevant for deaf users who would otherwise have limited or no access to the information contained in the video. Additionally, foreign language learners would profit from captions as well.

Lighthouse Accessibility Score​

The open-source tool Lighthouse is integrated in Google Chrome and aims to improve the quality of web pages. Regarding accessibility, it returns a score between 0 and 100, based on the number of passed/failed audits. Each issue can have a potential impact on users, such as "critical," "serious," "moderate," or "minor," based on how much it could affect a user's ability to use the site. The impact on users is then assessed, and developers can use these assessments to improve the accessibility of the web page, which could in turn improve the Lighthouse accessibility score.

The advantage of Lighthouse is that it is shipped with Google Chrome and provides measurable insights. However, it relies on the axe-core library's test rules under the hood and only runs a limited portion of those. For a full audit, it is therefore recommended to install the extension named axe DevTools, which is also available for Mozilla Firefox and Microsoft Edge. For example, the website "State of JavaScript" achieves a solid result of 89 points in Lighthouse (Figure 1). However, testing it with the extension reveals an additional 13 recommendations in comparison to Lighthouse (Figure 2).

Further browser extensions include WAVE, Siteimprove Accessibility Checker, Accessibility Insights, Tenon, and many others. These tools offer the advantage of providing actionable insights without requiring extensive accessibility expertise. While axe-core is a well-established option, it is up to the team to decide which tool best suits their needs. However, relying exclusively on browser extensions for accessibility testing can introduce certain limitations in the development workflow.

When using browser extensions solely during the testing phase, rather than throughout the feature implementation, accessibility issues may go unnoticed until later stages of the development process. Browser extensions typically test one page at a time, which can prove time-consuming and cumbersome when working with extensive or complex websites. Additionally, these extensions may have limited configuration options or only test against a predetermined set of rules, possibly overlooking project-specific requirements. Automated unit and end-to-end testing can amend some of these limitations.