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

Workflow in the Development Process

Barrierefreiheit in the Development Process

In the development phase, it is decided whether the accessibility requirements set in the design are implemented correctly. At the same time, it is the point at which many additional barriers can arise – for example, through incomplete HTML structures, insufficient focus control or dynamic content without ARIA support.

Goal of this workflow: Development of functional accessible components and pages based on technical standards and best practices.

Why accessible development is important

Even a perfect accessible design loses its effect if it is not implemented correctly. Developers are responsible for clean, semantic code that is accessible to screen readers and other assistive technologies. A consistent application of accessibility criteria not only improves the usability for people with disabilities, but also often improves maintainability, performance and SEO.

Common errors in development:

  • Incomplete HTML structures (missing labels, non-semantic containers)

  • Focus is lost when navigating or is not visible

  • Interactive elements without keyboard accessibility

  • Dynamic content without announcement (e.g. status messages)

Workflow steps in overview:

  1. Understand and implement technical requirements

    • Implementation according to WCAG 2.1/2.2 success criteria

    • Use native HTML elements before ARIA

    • Knowledge and application of accessible HTML patterns (e.g. accordions, modals)

  2. Write clean, semantic code

    • Use HTML5 elements according to their meaning (e.g. <nav>, <main>, <button>)

    • Use labels with <label>, aria-label or aria-labelledby correctly

  3. Ensure keyboard accessibility

    • Make all interactive elements keyboard accessible and operable

    • Visible focus state with CSS

    • Control focus order with tabindex, but use it sparingly

  4. Work with ARIA (Accessible Rich Internet Applications)

    • Use only where native HTML solutions are not sufficient

    • Use role assignments (role), state information (aria-pressed, aria-expanded) correctly

  5. Ensure responsive behavior

    • Make structure and interaction accessible on small displays

    • Do not make functions only accessible through hover or swipe

  6. Implement error messages and status updates

    • Visible and accessible for screen readers (e.g. with aria-live)

    • Clear, understandable instructions in forms

  7. Review and test code

    • Regular code reviews with A11y checklist

    • Combination of automated tests (e.g. with Axe) and manual checks

    • Collaboration with QA and possibly test persons with disabilities

Roles in the workflow:

  • UX Designers: User-centered design, derive requirements from user tests and WCAG

  • UI Designers: Implementation of visual clarity, interaction and focus management.

  • Product management: Ensure compliance with requirements, deadlines and legal requirements.

  • Development: Early integration for feasibility assessment.

Results of the workflow:

  • Designs that meet accessibility criteria

  • Documented requirements for technical implementation

  • Reduced adaptation effort in later phases

Tip: A graphic overview or checklist can help to establish this workflow team-wide. On request, such a presentation can be added.