Back to Homepage

EU Laws & Directives

German Laws

Best Practices

International Standards

Back to Homepage
German Regulation

BITV 2.0 - Barrierefreie-Informationstechnik-Verordnung

A comprehensive guide to Germany's Barrier-Free Information Technology Regulation - the federal accessibility standard for public sector websites, mobile applications, and electronic administrative documents

Mandatory for Federal Public Sector
BITV 2.0 applies to all federal public sector bodies in Germany (Träger öffentlicher Gewalt des Bundes). Websites published or substantially revised after September 23, 2018 must comply with WCAG 2.1 Level AA. Mobile applications must comply by June 23, 2021. Non-compliance can result in enforcement actions and legal consequences.

Introduction to BITV 2.0

What is the Barrierefreie-Informationstechnik-Verordnung?

The Barrierefreie-Informationstechnik-Verordnung 2.0 (BITV 2.0), or Barrier-Free Information Technology Regulation, is the German federal regulation that establishes binding accessibility requirements for websites, mobile applications, electronic documents, and graphical user interfaces of federal public sector bodies. First adopted in 2002 and comprehensively revised in 2011, the current version (BITV 2.0) was updated on May 25, 2019, to implement the EU Web Accessibility Directive (Directive 2016/2102) at the federal level in Germany.

BITV 2.0 applies to all federal public authorities (Bundesbehörden), including federal ministries, agencies, constitutional bodies, and federal corporations under public law. It establishes that federal public sector information technology must be accessible to persons with disabilities, based on the principles of the UN Convention on the Rights of Persons with Disabilities and the German Disability Equality Act (Behindertengleichstellungsgesetz - BGG).

The regulation is particularly important in Germany's federal system. While BITV 2.0 applies at the federal level (Bundesebene), each of Germany's 16 federal states (Bundesländer) has implemented corresponding state-level regulations for their public sector bodies. Despite some variations, these regulations generally follow BITV 2.0 as a model, creating substantial consistency in public sector digital accessibility across Germany.

Key Characteristics of BITV 2.0

Technically Precise Standards

Unlike general legal requirements, BITV 2.0 provides technically precise specifications. It directly references EN 301 549 and incorporates WCAG 2.1 Level AA (Stufe AA) as binding requirements. This technical precision allows developers and designers to know exactly what is required for compliance.

Comprehensive Coverage

BITV 2.0 covers not only public websites but also mobile applications (native and hybrid apps), intranets (internal websites), extranets (websites for closed user groups), electronic administrative documents (PDFs, forms, etc.), and graphical user programs (software with graphical interfaces used for public services).

Mandatory Accessibility Statements

Every covered website and mobile app must include a detailed accessibility statement (Erklärung zur Barrierefreiheit) following a standardized EU template. This statement must explain the conformance level, document known accessibility issues, provide a feedback mechanism, and reference enforcement procedures.

Systematic Monitoring

The federal monitoring body, Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik, conducts regular monitoring of federal websites and apps, publishes reports on compliance levels, and provides support to federal bodies in achieving accessibility.

Scope and Applicability

Who Must Comply with BITV 2.0?

BITV 2.0 applies to federal public sector bodies (Bundesbehörden) as defined in § 1 BGG. This includes:

Federal Ministries and Authorities (Bundesministerien und Bundesbehörden)

All federal ministries and their subordinate authorities must comply with BITV 2.0. This includes:

  • Federal ministries (e.g., Federal Ministry of Labour and Social Affairs, Federal Ministry of the Interior, etc.)
  • Federal agencies (Bundesanstalten, Bundesämter) such as the Federal Office for Migration and Refugees (BAMF), Federal Employment Agency (Bundesagentur für Arbeit), Federal Criminal Police Office (BKA)
  • Federal institutes and research centers funded and controlled by the federal government
  • Regulatory agencies (Aufsichtsbehörden) at the federal level

Federal Constitutional Bodies (Verfassungsorgane des Bundes)

Constitutional bodies of the federal government must comply, including:

  • Deutscher Bundestag (German Parliament)
  • Bundesrat (Federal Council representing the states)
  • Bundespräsidialamt (Office of the Federal President)
  • Bundesregierung (Federal Government) and the Federal Chancellery
  • Bundesverfassungsgericht (Federal Constitutional Court)
  • Other federal courts (Bundesgerichte)

Federal Corporations and Institutions under Public Law

Entities established under public law (Körperschaften, Anstalten, und Stiftungen des öffentlichen Rechts) at the federal level, such as:

  • Statutory pension insurance providers (gesetzliche Rentenversicherungsträger) like Deutsche Rentenversicherung
  • Statutory health insurance providers (gesetzliche Krankenkassen) at the federal level
  • Professional associations and chambers governed by federal law
  • Public broadcasting when performing administrative functions
State-Level Regulations
BITV 2.0 applies only to federal public sector bodies. Each of Germany's 16 federal states (Länder) has adopted its own accessibility regulations for state and local public bodies. These state regulations (e.g., L-BITV in Rhineland-Palatinate, BITV 2.0 SH in Schleswig-Holstein) generally mirror BITV 2.0 requirements, but public bodies must check their specific state regulations for exact requirements and deadlines.

Covered Technologies and Applications

Under § 1 BITV 2.0, the following information technology systems must be accessible:

Websites (Internetauftritte und Internetangebote)

All publicly accessible websites of federal public sector bodies must comply, including:

  • Main institutional websites: Primary web presence of ministries, agencies, and other federal bodies
  • Campaign and informational microsites: Special-purpose websites for campaigns, initiatives, or specific programs
  • Web applications: Interactive web-based applications for public services, forms, calculators, and tools
  • Portals and gateways: Entry points aggregating multiple services or information sources
  • Content management backends: When these interfaces are used by external users or the public (not internal-only admin interfaces)

Websites published or substantially revised after September 23, 2018, must comply. Older websites that haven't been substantially updated but remain actively used should be brought into compliance on a prioritized basis.

Intranets and Extranets (Intranetauftritte und Extranetauftritte)

Internal websites (intranets) and extranets (websites accessible only to defined closed groups) published or substantially revised after September 23, 2019, must be accessible. This includes:

  • Employee portals and internal communication platforms
  • Internal knowledge bases and documentation systems
  • Collaboration platforms and project management tools
  • Partner portals and service provider platforms
  • B2B platforms for procurement and contract management

The requirement for intranet/extranet accessibility is particularly important in Germany, where federal public sector employees include persons with disabilities who must be able to perform their duties on an equal basis with colleagues.

Mobile Applications (Mobile Anwendungen)

Mobile applications—both native apps (developed for specific platforms like iOS or Android) and hybrid apps (combining web technologies with native wrappers)—must be accessible. This requirement applies to apps published or substantially updated after June 23, 2021.

Examples include:

  • Apps for accessing public services (e.g., tax filing, benefit applications)
  • Mobile versions of government information services
  • Apps for emergency services and alerts
  • Apps providing transport information and ticketing
  • Educational and informational apps from federal institutions

Electronic Administrative Documents (Elektronisch unterstützte Verwaltungsabläufe)

Electronic documents used in administrative processes must be accessible when published after September 23, 2018 (or after September 23, 2019 for intranets/extranets). This includes:

  • PDF documents: Forms, brochures, reports, regulations, guidelines, and other official documents
  • Office documents: Word documents, Excel spreadsheets, PowerPoint presentations provided for download or exchange
  • Electronic forms: PDF forms, web forms, and application forms used for interacting with federal authorities
  • Legal documents: Published legislation, official notices, and legal information in digital formats
Archive and Legacy Content
Documents published before September 23, 2018 (or September 23, 2019 for intranets/extranets) are generally exempt unless they are needed for active administrative processes. However, if legacy documents are still actively used by the public, federal bodies should prioritize making them accessible. Archival content that is not updated and not part of active processes may remain exempt.

Graphical User Interfaces (Grafische Programmoberflächen)

Software with graphical user interfaces used to provide public-facing services must be accessible under Annex 2 of BITV 2.0. This includes:

  • Self-service kiosks and terminals in federal facilities
  • Public-use workstations in libraries, citizen centers, and offices
  • Software applications accessed by the public at federal facilities
  • Interactive displays and information systems

Exemptions and Exceptions

BITV 2.0 includes specific exemptions mirroring the EU Web Accessibility Directive:

Exempted Content Types

  • Pre-2018/2019 files: Office files (PDF, Word, Excel, etc.) published before September 23, 2018 (or September 23, 2019 for intranets/extranets) unless needed for active administrative processes
  • Pre-2019 time-based media: Pre-recorded audio and video published before September 23, 2019
  • Live media: Live audio and video streams (though live text alternatives like live captions should be provided where feasible)
  • Online maps: Exempt if essential information is provided in accessible alternative format for wayfinding and navigation
  • Third-party content: Content neither funded nor developed by the public body and not under its control
  • Heritage collections: Digital content from collections (libraries, museums, archives) where accessibility cannot be achieved because:
    • Source material cannot be made accessible (e.g., handwritten historical documents)
    • Making it accessible would fundamentally alter its historical or cultural significance
    • Digitization would cause unacceptable damage to fragile originals
  • Archived content: Content on websites that is no longer updated or edited and was last modified before September 23, 2019

Disproportionate Burden (Unverhältnismäßige Belastung)

Public sector bodies may claim that specific accessibility requirements impose a disproportionate burden under § 12a BGG and the Web Accessibility Directive. This exemption requires:

  • A documented assessment considering size, resources, and nature of the organization
  • Estimated costs and benefits of making the content accessible
  • Frequency and importance of use by persons with disabilities
  • Duration and permanence of the content

Even when claiming disproportionate burden, public bodies must provide accessible alternatives where possible and must document and publish the exemption in their accessibility statement. This exemption should be used sparingly and only for specific elements, not as a blanket excuse for non-compliance.

Technical Accessibility Requirements

WCAG 2.1 Level AA as Binding Standard

§ 3 Paragraph 1 BITV 2.0 establishes that websites and mobile applications of federal public sector bodies must conform to WCAG 2.1 Level AA (Stufe AA der WCAG 2.1). This is not a recommendation or aspiration—it is a binding legal requirement.

WCAG 2.1, published by the W3C in June 2018, builds on WCAG 2.0 by adding 17 new success criteria particularly addressing mobile accessibility, low vision, and cognitive disabilities. BITV 2.0 explicitly references the German translation of WCAG 2.1 authorized by W3C, ensuring that German-speaking developers and content creators can work with the standard in their native language.

The four foundational principles of WCAG—Perceivable (Wahrnehmbar), Operable (Bedienbar), Understandable (Verständlich), and Robust (Robust), known by the acronym POUR—organize all accessibility requirements. Federal websites and apps must meet all Level A and Level AA success criteria across these four principles.

Detailed Requirements by Principle

1. Perceivable (Wahrnehmbar)

Information and user interface components must be presentable to users in ways they can perceive:

  • Text Alternatives (Textalternativen, 1.1.1): Every non-text element (images, icons, graphics, charts) must have meaningful alternative text (Alternativtext) that conveys equivalent information. Decorative images must be marked as such to be ignored by assistive technologies.
  • Time-based Media (Zeitbasierte Medien, 1.2):
    • Pre-recorded video must have captions (Untertitel) and audio descriptions (Audiodeskription)
    • Live video must have live captions (Live-Untertitel) where technically feasible
    • Pre-recorded audio-only content must have transcripts (Transkripte)
    • Sign language interpretation (Gebärdensprache) should be provided for important announcements
  • Adaptable Content (Anpassbar, 1.3):
    • Use semantic HTML (headings h1-h6, lists, tables with proper structure)
    • Ensure meaningful sequence (reading order is logical)
    • Don't rely on sensory characteristics alone (shape, size, location, color)
    • Support both portrait and landscape orientations (Hoch- und Querformat, 1.3.4)
    • Identify input purpose programmatically for autofill (1.3.5)
  • Distinguishable (Unterscheidbar, 1.4):
    • Don't use color as the only means to convey information
    • Provide audio control for automatically playing audio longer than 3 seconds
    • Minimum contrast ratio of 4.5:1 for normal text, 3:1 for large text (Kontrastverhältnis, 1.4.3)
    • Text can be resized up to 200% without loss of content or functionality (1.4.4)
    • No images of text except for logos and essential images (1.4.5)
    • Reflow content for 320px width without horizontal scrolling (Umbruch, 1.4.10)
    • Ensure non-text contrast of 3:1 for UI components and graphics (1.4.11)
    • Support text spacing adjustments without loss of content (1.4.12)
    • Ensure content appearing on hover or focus is dismissible, hoverable, and persistent (1.4.13)

2. Operable (Bedienbar)

User interface components and navigation must be operable:

  • Keyboard Accessible (Tastaturzugänglich, 2.1):
    • All functionality available via keyboard without requiring specific timings
    • No keyboard trap—users can move focus in and out of all components
    • Provide keyboard shortcuts where beneficial, but ensure they can be remapped or disabled
  • Enough Time (Ausreichend Zeit, 2.2):
    • Allow users to turn off, adjust, or extend time limits (Zeitbegrenzungen)
    • Provide warnings before timeout with ability to extend session
    • Allow users to pause, stop, or hide moving, blinking, or auto-updating content
  • Seizures and Physical Reactions (Anfälle, 2.3):
    • Nothing flashes more than three times per second
    • Avoid content that could trigger photosensitive seizures
  • Navigable (Navigierbar, 2.4):
    • Provide a way to skip repeated content (Skip-Links, 2.4.1)
    • Use descriptive page titles (Seitentitel, 2.4.2)
    • Ensure logical focus order (Fokusreihenfolge, 2.4.3)
    • Provide clear link purpose from link text alone or with context (Linkzweck, 2.4.4)
    • Offer multiple ways to find pages (search, sitemap, navigation, 2.4.5)
    • Use descriptive headings and labels (Überschriften und Beschriftungen, 2.4.6)
    • Make focus visible (Sichtbarer Fokus, 2.4.7)
  • Input Modalities (Eingabemodalitäten, 2.5):
    • Provide alternatives to path-based or multipoint gestures (2.5.1)
    • Design to prevent accidental pointer input (2.5.2)
    • Ensure labels or instructions match accessible names (2.5.3)
    • Provide alternatives to motion-based actuation (tilting, shaking, 2.5.4)
    • Ensure touch targets are at least 44×44 CSS pixels (Zielgröße, 2.5.5)

3. Understandable (Verständlich)

Information and operation of user interface must be understandable:

  • Readable (Lesbar, 3.1):
    • Identify the default language of the page programmatically (lang attribute, 3.1.1)
    • Identify language changes within content (Sprachwechsel, 3.1.2)
    • Write in clear, simple German (Einfache Sprache) appropriate for a general audience
  • Predictable (Vorhersehbar, 3.2):
    • Don't trigger context changes automatically on focus (3.2.1)
    • Don't trigger context changes automatically on input unless user is warned (3.2.2)
    • Use consistent navigation (Konsistente Navigation, 3.2.3)
    • Use consistent identification for components with same functionality (3.2.4)
  • Input Assistance (Hilfestellung bei Eingabe, 3.3):
    • Identify and describe errors clearly (Fehlererkennung, 3.3.1)
    • Provide labels or instructions for user input (Beschriftungen oder Anweisungen, 3.3.2)
    • Suggest corrections for input errors (Fehlervorschläge, 3.3.3)
    • Allow review and correction for legal/financial submissions (3.3.4)

4. Robust (Robust)

Content must be robust enough to work with assistive technologies:

  • Compatible (Kompatibel, 4.1):
    • Use valid HTML with proper nesting and unique IDs (4.1.1)
    • Ensure all UI components have programmatically determinable name, role, state, and value (4.1.2)
    • Communicate status messages programmatically without receiving focus (Statusmeldungen, 4.1.3)

Electronic Document Accessibility (Annex 1)

Annex 1 of BITV 2.0 establishes specific requirements for electronic administrative documents. PDF documents, the most common format for federal documents, must be accessible according to PDF/UA (ISO 14289-1) and meet these criteria:

  • Proper tagging (Tags): All content must be tagged with appropriate structure elements (headings, paragraphs, lists, tables)
  • Logical reading order (Lesereihenfolge): Content must be in a logical sequence that makes sense when read linearly
  • Alternative text for images (Alternativtexte): All meaningful images must have descriptive alt text; decorative images must be marked as artifacts
  • Table structure (Tabellenstruktur): Tables must have properly defined headers and relationships between cells
  • Form field accessibility (Formularfelder): Form fields must have labels, tooltips where appropriate, and correct field types
  • Document metadata (Metadaten): Title, language, and other metadata must be properly set
  • OCR for scanned documents: Scanned documents must undergo OCR to create searchable, accessible text
Best Practice: HTML Over PDF
While PDFs can be made accessible, HTML is inherently more accessible and flexible. Federal bodies should provide information in accessible HTML format whenever possible, using PDF only when specific formatting preservation is essential (e.g., legally binding forms, official certificates).

Software and Graphical Interface Requirements (Annex 2)

Annex 2 addresses graphical user interfaces of software used for public services. These must meet requirements adapted from EN 301 549 for non-web software, including:

  • Keyboard accessibility for all functions
  • Screen reader compatibility through proper use of accessibility APIs
  • Visual customization options (font size, color schemes, contrast)
  • Audio output options where appropriate
  • Focus management and indication
  • Support for assistive technologies like screen magnifiers and voice control

Accessibility Statement (Erklärung zur Barrierefreiheit)

Mandatory Publication

§ 12b BGG and § 4 BITV 2.0 require every federal website and mobile application to publish a detailed accessibility statement (Erklärung zur Barrierefreiheit). This is not optional—it is a legal obligation.

The European Commission provides an official template and online generator for accessibility statements. German federal bodies should use this template or ensure their statements include all required elements.

Required Statement Content

The accessibility statement must include:

1. Conformance Status (Konformitätsstatus)

Declare one of three conformance levels:

  • Fully conformant (vollständig konform): The website or app fully conforms to WCAG 2.1 Level AA
  • Partially conformant (teilweise konform): Some parts do not fully conform
  • Not conformant (nicht konform): The website or app does not conform to WCAG 2.1 Level AA

2. Non-Accessible Content (Nicht barrierefreie Inhalte)

If not fully conformant, specifically identify non-accessible content and explain why:

  • Non-compliance (Nichtkonformität): List specific issues and which WCAG criteria they violate
  • Disproportionate burden (unverhältnismäßige Belastung): Explain what content is exempt due to disproportionate burden and why
  • Out-of-scope content (Inhalte außerhalb des Anwendungsbereichs): Identify exempted content (pre-2018 files, third-party content, etc.)

3. Statement Preparation (Erstellung der Erklärung)

  • Date of statement preparation or last update
  • Method used (self-assessment, external audit, automated tools, user testing)
  • Date of last significant update to the website or app

4. Feedback Mechanism (Feedback und Kontaktangaben)

Provide a clear, accessible way for users to:

  • Report accessibility problems (Barrieren melden)
  • Request information in accessible formats (Informationen in zugänglichen Formaten anfragen)
  • Ask questions about accessibility (Fragen zur Barrierefreiheit stellen)

Include contact details (email, phone, postal address) and commit to a response timeline (typically within two weeks).

5. Enforcement Procedure (Schlichtungsverfahren)

Inform users about the enforcement procedure through the Federal Monitoring Body (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) and the Schlichtungsstelle BGG (Federal Mediation Office). Include:

  • Contact details for the Federal Monitoring Body
  • Information about the mediation procedure (Schlichtungsverfahren) under § 16 BGG
  • Link to the Schlichtungsstelle BGG website

Statement Placement and Format

  • For websites: Link from every page, typically in the footer, using standardized link text "Erklärung zur Barrierefreiheit" or "Barrierefreiheit"
  • For mobile apps: Available on the website of the public body, in app store descriptions, or within the app settings
  • Accessible format: The statement itself must be accessible (it would be ironic otherwise!)
  • Machine-readable option: Ideally, provide a machine-readable version following EU specifications for automated monitoring

Monitoring and Enforcement

Federal Monitoring Body (Überwachungsstelle des Bundes)

The Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik (Federal Monitoring Body for IT Accessibility) was established to monitor compliance with BITV 2.0 and support federal bodies in achieving accessibility.

The monitoring body's responsibilities include:

  • Regular monitoring (Regelmäßige Überwachung): Conducting periodic assessments of federal websites and apps using automated tools, manual testing, and expert evaluation
  • Sample selection (Stichprobenauswahl): Testing representative samples including high-traffic sites, randomly selected sites, and sites from different types of federal bodies
  • Reporting (Berichterstattung): Publishing annual reports on the state of federal IT accessibility
  • Support and guidance (Unterstützung und Beratung): Providing technical guidance, best practices, and training to federal bodies
  • Handling complaints (Beschwerdebearbeitung): Investigating accessibility complaints from users and working with federal bodies to resolve issues

Contact: Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik, Bundesministerium für Arbeit und Soziales, Wilhelmstraße 49, 10117 Berlin

Mediation Procedure (Schlichtungsverfahren)

Under § 16 BGG, the Schlichtungsstelle nach dem Behindertengleichstellungsgesetz (BGG Mediation Office) provides a free, informal dispute resolution process for accessibility issues.

When to Use Mediation

Users can initiate mediation when:

  • They encounter accessibility barriers on federal websites or apps
  • They have contacted the federal body and received no response or an unsatisfactory response
  • They believe their rights under the BGG have been violated

Mediation Process

  • User files a complaint with the Schlichtungsstelle (no legal representation required)
  • Schlichtungsstelle contacts the federal body and requests a response
  • Mediation attempts to reach a mutually acceptable solution
  • Process is confidential and typically faster and less formal than court proceedings
  • If mediation fails, users retain the right to pursue legal action

Consequences of Non-Compliance

While BITV 2.0 itself does not establish administrative fines (unlike BFSG for private sector), non-compliance can result in:

  • Corrective orders (Anordnungen): Supervisory authorities can order federal bodies to remedy accessibility violations
  • Public reporting (Öffentliche Berichterstattung): Monitoring reports publicly identify non-compliant federal websites and apps
  • Legal action (Rechtliche Schritte): Persons with disabilities can bring legal action under the BGG and the General Equal Treatment Act (AGG)
  • Reputational consequences (Reputationsfolgen): Non-compliance reflects poorly on federal bodies' commitment to equality and inclusion
  • Political pressure (Politischer Druck): Parliamentary inquiries and media attention can result from persistent non-compliance

Frequently Asked Questions

Scope and Application Questions

Q: Does BITV 2.0 apply to state and local government bodies?

No, BITV 2.0 applies only to federal (Bundes-) public sector bodies. Each of Germany's 16 federal states has its own accessibility regulations for state and local government. These typically mirror BITV 2.0 requirements but may have different deadlines and enforcement mechanisms.

Q: Does BITV 2.0 apply to contractors and external service providers?

Yes, indirectly. When federal bodies procure IT services, websites, or software, they must include accessibility requirements in procurement contracts. External providers developing systems for federal bodies must deliver BITV 2.0-conformant products. The federal body remains responsible for ensuring compliance even when using external providers.

Q: What about social media accounts of federal bodies?

Social media platforms (Facebook, Twitter/X, Instagram) themselves are not under the control of federal bodies, so the platforms' own accessibility is not directly the federal body's responsibility. However, content posted by federal bodies should be as accessible as possible (e.g., including image descriptions, using clear language, providing captions for videos).

Q: Are email communications covered?

While email itself is not explicitly covered by BITV 2.0, federal bodies should ensure email communications are accessible: use plain text or accessible HTML email templates, include descriptive subject lines, provide attachments in accessible formats, and use clear language. This is consistent with the spirit of accessibility obligations even if not technically mandated by BITV 2.0.

Compliance Questions

Q: How do I test for WCAG 2.1 Level AA compliance?

Use a multi-faceted approach: (1) Automated tools like our accessibility checker, axe DevTools, WAVE, or Pa11y for initial screening; (2) Manual testing with keyboard navigation and screen readers (NVDA, JAWS, VoiceOver); (3) Testing with actual users with disabilities; (4) Following methodologies like the BIK BITV-Test or EN 301 549 testing procedures. Remember that automated tools catch only about 30-40% of issues.

Q: Can I use an accessibility overlay or widget?

No. Accessibility overlays are JavaScript-based tools claiming to make websites automatically accessible. They are not recognized as valid compliance methods under BITV 2.0 and often create more barriers than they solve. Genuine compliance requires properly implementing WCAG 2.1 Level AA in your codebase.

Q: What if our content management system (CMS) doesn't support accessibility?

Federal bodies are responsible for choosing and configuring accessible CMS platforms. Most modern CMS platforms (WordPress, Drupal, TYPO3, etc.) can be configured for accessibility. If your current CMS doesn't support WCAG 2.1 Level AA, you should plan to migrate or extensively customize it. BITV 2.0 compliance is mandatory regardless of technical limitations.

Q: How often should we update our accessibility statement?

Update your accessibility statement whenever there are significant changes to the website or app, when you remediate accessibility issues, or when your conformance level changes. Review it at least annually even if nothing has changed. The statement should always reflect the current accessibility status.

Technical Implementation Questions

Q: What's the difference between WCAG 2.0 and WCAG 2.1?

WCAG 2.1 builds on WCAG 2.0, adding 17 new success criteria focused on mobile accessibility, low vision, and cognitive disabilities. All WCAG 2.0 Level AA criteria remain in WCAG 2.1 Level AA, so WCAG 2.1 is more comprehensive. BITV 2.0 requires WCAG 2.1 Level AA, not WCAG 2.0.

Q: Can we use WCAG 2.2 instead of WCAG 2.1?

WCAG 2.2 (published October 2023) is backwards compatible with WCAG 2.1—anything conforming to WCAG 2.2 Level AA also conforms to WCAG 2.1 Level AA. Using WCAG 2.2 is acceptable and demonstrates commitment to latest best practices, but BITV 2.0 currently references WCAG 2.1 as the baseline.

Q: How do we make PDFs accessible?

Create accessible PDFs using Adobe Acrobat Pro or accessible authoring tools in Microsoft Word. Ensure proper tagging, logical reading order, alternative text for images, form field labels, and table structure. Test with PAC (PDF Accessibility Checker). Better yet, provide content in accessible HTML format rather than PDF whenever possible.

Q: Are there German-language resources for WCAG 2.1?

Yes. W3C provides an authorized German translation of WCAG 2.1. The BIK (Barrierefrei informieren und kommunizieren) project offers extensive German-language guidance, the BITV-Test methodology, and training resources. Many German accessibility consultancies and organizations provide German-language materials.

Resources and Support

Technical Standards and Testing

Support Organizations

  • Bundesfachstelle Barrierefreiheit: Federal competence center for accessibility providing consulting and training
  • AbI-Projekt (Accessibility in Informationstechnik): Project supporting federal bodies in implementing accessibility
  • Deutscher Blinden- und Sehbehindertenverband (DBSV): National association of blind and partially sighted people
  • Deutscher Gehörlosen-Bund (DGB): German Deaf Association
  • Bundesverband Selbsthilfe Körperbehinderter (BSK): Federal association for people with physical disabilities
  • Kompetenzzentrum Digitale Barrierefreiheit: Competence center for digital accessibility in various federal states
Commitment to Public Service Accessibility
BITV 2.0 compliance is not just about legal obligation—it's about ensuring that federal public services are accessible to all citizens. Germany's commitment to accessibility reflects the principle that public administration must serve all people equally, regardless of disability. Federal bodies should view BITV 2.0 as a minimum baseline and strive for excellence in accessibility, ensuring that digital transformation includes everyone.