Achieving Digital Accessibility with Limited Knowledge

Publication: 17/10/2026

Ideally, digital accessibility is accompanied by relevant expertise and specialized experts. In practice, however, the personnel, financial, or organizational prerequisites for this are often lacking.

The central question is therefore: How can accessibility be implemented as effectively as possible even with few resources and limited background knowledge?

The approach is to use proven solutions, integrate accessibility into existing processes early on, and systematically avoid recurring errors. At the same time, a realistic assessment must be made as to which requirements can be implemented without additional expertise.

Embedding Accessibility in Standards and Components

The greatest leverage lies in making accessibility an integral part of product development. Corporate design, design systems, and component libraries provide a solid foundation for this.

  • Establish design specifications: Definitively define contrasts, minimum sizes for interactive areas, and alternative operating options.
  • Use proven components: Prefer native HTML and platform components rather than unnecessarily developing functions from scratch.
  • Provide accessible components: Implement recurring elements such as dialogs, accordions, and menus—including keyboard navigation, focus management, and comprehensible documentation.

The goal is for developers to need as little additional specialized knowledge as possible to meet basic requirements.

Workflows, Checklists, and Decision Trees

Workflows are standardized procedures for recurring processes: a document is made accessible by applying style sheets and image descriptions, and then saved as a tagged PDF. A workflow helps to carry out these steps during work.

Checklists help to systematically identify common barriers and work through basic requirements. Suitable starting points include the WCAG and the materials of the W3C's Web Accessibility Initiative (WAI), as well as appropriate practical guidelines.

Decision trees complement checklists by guiding users to the right solution using specific questions. For example, this makes it possible to determine whether an image requires alternative text or is purely decorative.

Important: These tools should be concise, comprehensible, and tailored to specific workflows. This makes them easier to apply and more likely to actually be used.

Combining Automated and Manual Testing

Automated testing tools like axe and Lighthouse can identify typical technical issues early on. Ideally, they are integrated directly into development processes.

As a supplement, simple manual tests should be carried out, such as:

  • Can the application be operated entirely via keyboard?
  • Is the focus position traceable at all times?
  • Are contents and controls conveyed understandably by a screen reader?
  • Are contrasts and text alternatives appropriate?

Guided testing procedures help even individuals without in-depth prior knowledge to carry out such checks systematically.

However, automated tests only cover a fraction of barriers. They must therefore be supplemented by manual checks. Guided tests can help by walking through the tests step by step.

Using Reliable Sources of Knowledge

When uncertainties arise, official standards and documentation should form the basis. For web applications, the WCAG and the W3C's WAI are particularly relevant. For apps, Google and Apple provide their own documentation and development guidelines.

Forums and generative AI can supplement research, but should not serve as the sole source of knowledge. Results must be verified against reliable original sources. The problem of outdated or incorrect information remains unsolved. For example: A major AI claimed that LibreOffice required the Java Access Bridge to work with screen readers—that has not been true for many years.

Recognizing Limits and Deploying Expertise Selectively

Checklists, component libraries, and testing tools enable many improvements, but they do not replace sound expertise. General approaches quickly reach their limits when dealing with complex keyboard interactions, demanding selection components, or specific screen reader behavior.

Without specialist knowledge, the time required and the risk of overlooking errors also increase. Therefore, unresolved issues should be documented and prioritized selectively. For critical or complex requirements, it makes sense to bring in expert support on a targeted basis.

The core problem with this approach, too, is that specialized expertise will presumably be needed at least for optimizing libraries. People without expertise will take significantly longer to integrate all essential requirements and will certainly overlook some things. In this respect, it makes sense, at least initially, to purchase expertise for optimizing libraries and processes.

More on Accessibility and Consulting