Skip to content
Logo mtc Berlin - Zur Startseite Logo mtc Berlin - Zur Startseite

Accessibility Workflow

The integration of accessibility into the development process is essential to design digital products from the start as inclusive and legally compliant. Accessibility should not be understood as a post-implementation check, but as an integral part of all project phases.

Define requirements early

Requirements for accessibility should be clearly defined and documented already in the design and planning phase.

  • Define accessibility as a quality goal
  • Link requirements to WCAG 2.2 (Level AA)
  • Inform project stakeholders about legal foundations (e.g. BFSG)
  • Include accessibility criteria in user stories, definition of done and acceptance criteria

Tip: Include accessibility as a fixed point in the kick-off and sprint planning.

Design phase: make it accessible

UX and UI design have a significant influence on future accessibility. Early attention saves corrections.

  • Build accessible design systems and component libraries
  • Check color contrasts and font sizes (e.g. with Figma plugins, contrast tools)
  • Think about focus indicators, keyboard paths and visual feedback
  • Plan forms, error messages and labels from the start

Recommendation: Include checklists and WCAG mappings in design reviews.

Development: implement semantically and robustly

Developers implement the accessibility requirements technically. Here, clean, semantic HTML is essential.

  • Use native HTML elements with meaningful ARIA attributes
  • Ensure focus management and keyboard navigation
  • Make dynamic content understandable with live regions or ARIA roles
  • Make the system responsive to different devices and input methods

Tools:

  • Linter
  • lintrules
  • Testing-Frameworks with A11y-Checks (e.g. axe-core, pa11y-ci)

Integrate testing

Accessibility tests should be performed regularly and early – automated and manual.

  • Automated checks in CI/CD (e.g. GitHub Actions, Cypress with axe)
  • Manual tests during development (e.g. keyboard test, screen reader test)
  • Acceptance by UX/QS with focus on accessibility
  • Document results and prioritize

Note: Chapter 3 contains detailed test instructions and tools.

Maintenance and further development

Even after release, accessibility remains a topic – especially with changes to the frontend.

  • Consider accessibility in code reviews and regression tests
  • Evaluate feedback from users with disabilities
  • Use monitoring tools or regular audits
  • Document and maintain versioning

Conclusion: Accessibility must be part of the entire development cycle – from the idea to maintenance. Only then does sustainable digital inclusion arise.