Accessibility Requirements in 2025: What Barrierefreiheit Means for eCommerce, SaaS and Corporate Websites

Why Accessibility Matters Now More Than Ever

The push for digital accessibility, or "barrierefreiheit" in German-speaking regions, is no longer a fringe concern. As legislation tightens and expectations rise, businesses that ignore it are not just missing potential customers, they may soon be in breach of law. This article explores what accessibility means in 2025, which regions and sectors are affected, and how this applies to everything from eCommerce shops and SaaS dashboards to corporate landing pages and portals.

Key Regulations You Must Know

European Union: The European Accessibility Act (EAA)

The EAA came into force in 2019 and member states must comply by June 28, 2025. It targets digital products and services considered essential, including:

  • eCommerce websites and apps — Online shops must ensure that product discovery, cart, checkout, and customer service experiences are fully navigable for people using screen readers, alternative input devices, or those with cognitive limitations.
  • Banking and financial services platforms — Digital banking tools, from personal banking apps to investment portals, must be accessible to all users. This includes visual clarity, secure yet accessible authentication flows, and support for assistive technologies.
  • eBooks and eReaders — Publishers and platforms must ensure that eBooks and their readers support text scaling, screen reader output, and logical content structuring, so that users with visual impairments can engage with content equally.
  • Transport and ticketing platforms — Timetables, booking systems, and mobile travel apps must allow users with various impairments to plan and purchase journeys independently. Voiceover support, keyboard access, and real-time updates must be integrated properly.
  • Telecoms and hardware interfaces — Interfaces for routers, mobile phones, smart TVs, and telecom software must meet accessibility thresholds, ensuring all essential features can be used without vision, hearing, or fine motor control. This affects all EU countries, including Austria and Germany, and non-EU businesses selling into the EU. Any company providing covered services or digital products in the single market must be prepared to comply or face regulatory consequences.

Germany: Barrierefreiheitsstärkungsgesetz (BFSG)

Germany has implemented the EU directive with the Barrierefreiheitsstärkungsgesetz (BFSG), which translates to Accessibility Strengthening Act. It targets private sector businesses that meet one or both of the following criteria:

  • 10 or more employees — This includes all staff, even if not directly involved in the digital product. The threshold ensures even smaller firms take accessibility seriously.
  • Over €2 million in annual turnover — This ensures financial capability is taken into account and that larger firms cannot ignore accessibility obligations. The law applies to a broad range of digital and consumer-facing touchpoints, including:
  • Websites — All publicly accessible pages, including homepages, product listings, legal pages and portals. Content must be readable with assistive technologies, navigable by keyboard, and properly structured with semantic HTML.
  • Mobile apps — Applications offered through app stores must be fully navigable, screen-reader compatible, and meet WCAG standards for contrast, interaction, and error handling.
  • Self-service terminals — Digital kiosks and payment stations in retail, banking, transport or public administration must allow operation without visual, auditory or fine-motor input. That includes physical button alternatives, audio feedback, and tactile aids.
  • Customer communication interfaces — Chatbots, email forms, portals and any digital means by which consumers interact with a business. These must support keyboard-only use, meaningful feedback, and clear labelling of actions. Unlike the general EAA, the BFSG gives German regulators national enforcement power, including inspections, mandatory remediation, and administrative fines for non-compliance. This means companies trading in Germany cannot afford to see accessibility as a soft requirement — it will be enforced alongside GDPR and other regulatory frameworks.

Austria: Web-Zugänglichkeits-Gesetz (WZG)

The WZG governs accessibility for public sector websites and mobile applications in Austria. It requires all federal websites, state institutions, and publicly funded organisations to meet accessibility standards based on WCAG 2.1. This includes educational institutions, hospitals, and cultural bodies that receive state support. All content must be perceivable, operable, understandable, and robust. Currently, private sector companies are not legally bound by WZG unless they serve in a public capacity. However, accessibility is increasingly part of government tenders and procurement. Austrian municipalities and government agencies often require digital service providers to prove accessibility compliance before awarding contracts. Additionally, as the European Accessibility Act deadline nears in 2025, Austrian law will expand to cover private digital services. This makes early adoption not only compliant but commercially strategic.

United States: Americans with Disabilities Act (ADA)

The ADA, enacted in 1990, has been interpreted by courts to apply to websites and online services as part of Title III, which governs public accommodations. This means any commercial website — including eCommerce and SaaS platforms — must be usable by individuals with disabilities. This includes:

  • Proper alt text for images
  • Logical heading structure
  • Keyboard navigation
  • Accessible forms and error handling What makes the ADA particularly relevant is the wave of litigation. Thousands of lawsuits have been filed, particularly in New York, California, and Florida, often targeting retail websites with insufficient accessibility support. Businesses outside the United States but accessible to US consumers — including EU-based SaaS or eCommerce platforms — have also been named in suits. Failure to comply can result in costly settlements and reputational damage. There is no official technical standard in the ADA itself, but WCAG 2.1 Level AA is broadly accepted by courts and regulators as the required benchmark.

EN 301 549: The Technical Standard

EN 301 549 is the European Union’s harmonised standard for accessibility under the European Accessibility Act. It outlines the functional performance criteria and technical requirements that digital services and products must meet. Key aspects include:

  • Ensuring all functionality is operable through a keyboard interface
  • Making content perceivable through text alternatives, captions, and structure
  • Allowing users to customise presentation without loss of content or functionality
  • Providing sufficient time for interaction and preventing seizures from flashing elements
  • Structuring documents so assistive technologies can navigate them effectively EN 301 549 incorporates WCAG 2.1 Level AA but also adds extra requirements for software, hardware, documentation, and support services. For example, it covers accessibility for:
  • Mobile applications
  • Operating systems
  • Video players and document viewers
  • Support documentation and user help desks Compliance with EN 301 549 is presumed conformity under the European Accessibility Act, meaning that businesses who meet it are deemed legally compliant. It forms the basis for audits and technical evaluations in the EU.

What Accessibility Means in Practice

Accessibility refers to whether people with disabilities can use your website or application independently and effectively. This goes beyond simply displaying content — it ensures interaction, understanding, and trust. Here are some of the key principles:

  • Screen reader compatibility for blind or low-vision users — All visual content, including images, icons, and infographics, must include appropriate alternative text. Headings, lists, and landmarks must be used semantically so assistive technologies like NVDA, JAWS, or VoiceOver can interpret and relay content meaningfully. Dynamic content should be announced to screen readers using ARIA live regions.
  • Keyboard navigation for those who cannot use a mouse — All interactive elements, such as menus, buttons, sliders, forms, and modals, must be operable using the Tab key and Shift+Tab to navigate. Focus indicators must be visible and consistent. Users must not get trapped in modal windows without a clear escape path.
  • Contrast and font scaling for readability — Text and background colour combinations must meet minimum contrast ratios (4.5:1 for normal text, 3:1 for large text). The interface must support text scaling up to 200 percent without breaking layout or losing content. This helps users with visual impairments, colour blindness, or ageing eyes.
  • Avoiding motion or flashing content that could trigger seizures — Content that blinks or flashes more than three times per second must be avoided. Autoplaying videos or animations must be paused or stopped by default, or offer user control. Transitions must be smooth and not rely solely on motion cues.
  • Descriptive labels and ARIA roles for buttons and links — Every button, link, or form element must have a clear label, either visible or programmatically provided. ARIA attributes such as aria-label, aria-labelledby, and role must be used correctly to describe functionality. Buttons like "Learn more" or "Click here" must be contextually meaningful.
  • Form accessibility — Input fields must be associated with "label" elements or use aria-labels. Error messages must be conveyed programmatically and visibly. Validation messages must describe the issue and how to resolve it. Required fields should be marked and explained.
  • Navigation structure and skip links — Logical page structure with clear headings (H1 to H6) helps screen reader users navigate effectively. Skip to main content links allow keyboard users to bypass repetitive navigation. Accessible design is not just about compliance — it also enhances usability for all users. Features that improve accessibility often improve mobile usability, search engine optimisation, and general customer satisfaction. In practice, accessibility is a competitive advantage for businesses that want to serve diverse audiences and expand market reach.

eCommerce and Accessibility

Online shops have a legal obligation to make every part of the purchase journey accessible. Accessibility in eCommerce goes beyond the product detail page. It includes the end-to-end experience from landing to final checkout and post-sale communication.

  • Product listings must be readable by screen readers. This includes properly structured product titles, prices, availability indicators, and product descriptions. ARIA roles should be used where standard HTML does not suffice.
  • Forms (like checkout, registration, and login) must be navigable by keyboard alone. All fields must have labels, error messages must be readable by screen readers, and required fields must be clearly indicated.
  • Colour contrast must meet or exceed WCAG guidelines, especially for text on buttons, pricing, and form labels. Promotional banners often fail this due to light-on-light colour schemes.
  • Error messages must be descriptive and must not rely solely on colour or iconography. For example, if a field is missing, a message should say “Please enter your billing address” instead of simply showing a red outline.
  • Third-party payment gateways must also comply. This includes integrations with Klarna, PayPal, and Stripe. If the iframe or redirect page breaks the accessibility chain, your compliance is still at risk. Post-2025, any eCommerce store operating within the EU or selling to EU customers is expected to meet these requirements. Regulatory bodies will assess functionality, not just appearance. Non-compliance can result in legal challenges, fines, or contractual exclusion from large marketplaces or payment networks.

SaaS Platforms and Dashboards

While many think of accessibility as only affecting public-facing websites, SaaS platforms are especially affected. These are highly interactive environments where accessibility impacts both usability and compliance.

  • They are interactive applications, not static content. That means accessibility must account for dynamic interactions, JavaScript-rendered content, and asynchronous behaviours.
  • User interfaces often contain complex controls like tabs, modals, sliders, data tables, dashboards, and charts — all of which must be navigable and announced to assistive tech.
  • They serve B2B clients who themselves must be compliant. If your SaaS is used in finance, healthcare, education, or public administration, accessibility is often a contractual requirement. Accessible SaaS means:
  • Keyboard-accessible UI elements including modals, dropdowns, tooltips, buttons, and toggle switches. Tab order must be logical, and focus management must be handled intentionally.
  • Semantic HTML for forms, headings, and data tables. Tables must have headers and scope attributes. Forms must announce validation results.
  • Screen reader-friendly dashboards, especially for metrics, visualisations, and charts. Data insights should be provided as text summaries and allow toggling to non-visual representations.
  • Accessible onboarding and help flows, including accessible tour modals, chatbot interactions, and support ticket systems. All embedded documents and guides must follow accessibility best practices. Accessibility in SaaS is not just a feature — it is an expectation. Clients are beginning to include WCAG compliance in their procurement checklists, and in many verticals, lack of accessibility can disqualify vendors from tenders.

Corporate Sites and Landing Pages

Even seemingly simple or static websites must comply with accessibility law. Corporate websites are often the first point of contact with customers, investors, job applicants, and regulators.

  • Company info, contact forms, and legal disclosures must be easily accessible. Users must be able to find your address, phone number, privacy policy, and terms using only a keyboard or screen reader.
  • Cookie banners and consent flows must allow all users to understand and manage consent choices. That means avoiding dark patterns, providing visible focus states, and supporting keyboard navigation.
  • PDFs and downloads such as investor presentations, terms and conditions, or product brochures must be machine-readable. This means using tagged PDF structure, logical reading order, and text-based elements.
  • Video content, including interviews, tutorials, or ads, must include captions. If audio is essential, a transcript must be available. Auto-playing videos should allow pause and volume control via keyboard. Non-compliance in this category is often overlooked, but it exposes businesses to risks. If your website generates leads, processes applications, or provides public information, it falls within the scope of most accessibility laws in the EU and beyond.

Tools and Techniques

Making your website or app accessible is not just a matter of following a checklist — it requires a deliberate and structured workflow. From developer tools to QA practices, accessibility must be built into the design, code, and deployment process. To audit and improve accessibility:

  • Use automated testing tools such as Google Lighthouse, axe DevTools, WAVE, or Accessibility Insights. These tools can scan for missing alt text, contrast issues, missing labels, and common ARIA mistakes. They are excellent for catching low-hanging fruit, but should not replace manual review.
  • Follow the WCAG 2.1 Level AA standard. This is the recognised baseline in most jurisdictions and includes rules for text alternatives, keyboard navigation, contrast, input assistance, and more.
  • Write clean, semantic HTML — use native tags like <nav>, <main>, <button>, and <form> rather than relying on div and span. Semantic structure improves accessibility and SEO simultaneously.
  • Use proper form labelling with <label for="...">, and apply ARIA labels only where native semantics are not available. Avoid overuse of ARIA roles, which can confuse screen readers if misapplied.
  • Avoid inaccessible captchas — traditional image-based captchas are unusable for many users. Prefer accessible alternatives like hCaptcha with accessibility mode or logic-based challenges with clear instructions.
  • Maintain a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Many design systems and CSS variables can be audited with tools like Stark or Color Contrast Checker.
  • Provide clear focus indicators for interactive elements and include skip links at the top of pages so keyboard users can jump directly to content, bypassing navigation.
  • Use manual testing with screen readers such as NVDA, JAWS, or VoiceOver. Navigate through your site using only the keyboard and screen reader output — this gives real insight into usability.
  • Include accessibility in design reviews — check Figma files for heading levels, contrast, and alt text fields. Designers must think accessibly before a single line of code is written. Accessibility testing should be part of both QA and regression testing. In continuous deployment environments, this means integrating checks into pull requests and build pipelines. CI tools like Cypress, Playwright, and pa11y can be scripted to validate accessibility across core flows like onboarding, checkout, or form submissions. It is also important to maintain documentation of known accessibility issues and track them in your issue tracker. Treat them like bugs, with prioritisation and resolution cycles.

Accessibility Is a Growth Lever

Accessible websites and applications are not just inclusive — they are smarter business. Accessibility boosts performance across acquisition, conversion, and retention:

  • Reach more users — Including users with visual, motor, cognitive, or auditory impairments. Accessibility expands your market size, including older demographics and users in low-bandwidth or mobile-first contexts.
  • Reduce legal risk — Avoid fines, lawsuits, or public backlash by complying with national and international law. Accessibility is now enforced in public procurement and B2B enterprise contracts.
  • Improve UX for everyone — Features that help users with disabilities often help everyone: clearer forms, better contrast, mobile responsiveness, and more intuitive navigation.
  • Win public sector and enterprise clients — Many public and corporate RFPs now require accessibility conformance reports or VPATs. You will be disqualified from tenders if you do not comply. If you are planning a new build, or upgrading your platform before the European Accessibility Act takes full effect in 2025, accessibility cannot be a last-minute bolt-on. It must be part of your architecture from the first wireframe to final deployment. I approach accessibility not just as a legal requirement, but as a product principle. It improves code quality, SEO, conversion rates, and trust. And it ensures that every user — regardless of ability — can engage with your brand. If you want help with auditing, planning, or implementation, I would be happy to show you how I integrate accessibility into both technical delivery and growth strategy.