Web Development, Accessibility

Web Accessibility (WCAG) and Regulation in Spain and Europe: What B2B Teams Must Know

April 25, 2026 · 10 min read · Ver en Español →
Web Accessibility (WCAG) and Regulation in Spain and Europe: What B2B Teams Must Know

Web accessibility is no longer a best-practice checkbox — it is a binding legal obligation for a growing number of organizations operating in Spain and across the European Union. Understanding the regulatory framework is the first step toward building compliant, inclusive digital products.

The Foundation: WCAG and Its Versions

The Web Content Accessibility Guidelines (WCAG), published by the W3C's Web Accessibility Initiative (WAI), define the technical and design criteria that make web content accessible to people with disabilities — including those with visual, auditory, motor, and cognitive impairments. The guidelines are organized around four principles, commonly known as POUR:

  • Perceivable — Information and UI components must be presentable to users in ways they can perceive.
  • Operable — UI components and navigation must be operable by all users.
  • Understandable — Information and the operation of the UI must be understandable.
  • Robust — Content must be robust enough to be interpreted by a wide variety of assistive technologies.

Each principle contains specific success criteria rated at three conformance levels:

  • Level A — Minimum accessibility requirements.
  • Level AA — The standard required by most regulations worldwide, including EU law.
  • Level AAA — The highest level; not required as a blanket standard but recommended for specific content types.

The current stable version is WCAG 2.1, published in 2018, which extended WCAG 2.0 with 17 additional success criteria addressing mobile accessibility, low vision, and cognitive disabilities. WCAG 2.2, published in October 2023, adds nine further criteria, including improvements for users with cognitive or learning disabilities and those using mobile devices. European regulation currently references WCAG 2.1 Level AA as the baseline, though 2.2 is rapidly becoming the practical standard for new builds.

The European Accessibility Act (EAA)

The European Accessibility Act (Directive 2019/882/EU) is the cornerstone of EU accessibility law for the private sector. It mandates that a broad range of products and services — including websites, mobile applications, e-commerce platforms, banking services, and transport ticketing — meet accessibility requirements by 28 June 2025.

Key facts about the EAA:

  • It applies to private businesses, not just public bodies.
  • It covers products and services placed on the EU market after the transposition deadline.
  • Micro-enterprises (fewer than 10 employees and annual turnover below €2 million) are exempt from service-related obligations, but not from product requirements.
  • Member states are required to designate enforcement authorities and establish penalties for non-compliance.

For B2B web teams, this means that any client operating an e-commerce store, SaaS platform, or digital service targeting EU consumers must be EAA-compliant by mid-2025.

Spain-Specific Regulation: RD 1112/2018 and Beyond

Spain transposed the EU Web Accessibility Directive (2016/2102) through Real Decreto 1112/2018, which applies to public sector websites and mobile applications. It requires:

  • Compliance with EN 301 549 (the European harmonized standard that references WCAG 2.1 Level AA).
  • Publication of an accessibility statement on each covered website.
  • A feedback mechanism allowing users to report accessibility issues and request accessible formats.
  • Periodic monitoring by the Observatorio de Accesibilidad Web, managed by the Ministry of Economic Affairs.

For the private sector, Spain is in the process of transposing the EAA through national legislation, with the deadline of June 2025 driving urgency. Spanish businesses in sectors such as banking, insurance, e-commerce, and transport must begin compliance audits immediately if they have not already done so.

The regulatory picture is clear: WCAG Level AA conformance is the de facto legal requirement across both the public and private sectors in Spain and the EU.

Technical Implementation: Meeting WCAG 2.1 Level AA on WordPress, Webflow, and Shopify

Understanding the regulation is one thing — implementing it across real production environments is another. The technical requirements of WCAG 2.1 Level AA touch every layer of the stack: markup, CSS, JavaScript behavior, media, and third-party integrations. The following breakdown covers the highest-impact areas for teams working on WordPress, Webflow, and Shopify projects.

Semantic HTML and Document Structure

Proper semantic markup is the foundation of accessible web content. Assistive technologies such as screen readers rely on the document's semantic structure to communicate meaning to users.

Critical requirements:

  • Use a single <h1> per page, with a logical heading hierarchy (h2 → h3 → h4).
  • Use landmark elements (<header>, <nav>, <main>, <footer>, <aside>) to define page regions.
  • Use <button> for interactive controls and <a> for navigation — never use <div> or <span> as interactive elements without ARIA roles.
  • Ensure all form inputs have associated <label> elements using for/id pairing or aria-labelledby.
<!-- Correct: explicit label association -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" required aria-describedby="email-hint" />
<span id="email-hint">We will never share your email with third parties.</span>

<!-- Incorrect: no label, inaccessible -->
<input type="email" placeholder="Email address" />

Keyboard Navigation and Focus Management

All interactive elements must be reachable and operable using only a keyboard. This is a Level A requirement, but its implementation failures are pervasive in production sites.

  • Ensure a visible focus indicator on all interactive elements. WCAG 2.2 introduces stricter focus appearance criteria (Success Criterion 2.4.11).
  • Never use outline: none or outline: 0 in CSS without providing a custom, clearly visible alternative.
  • Implement skip navigation links so keyboard users can bypass repetitive navigation blocks.
  • Manage focus programmatically when content changes dynamically — for example, after a modal opens, focus must move to the modal container.
/* Accessible focus style — meets WCAG 2.2 SC 2.4.11 minimum area */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

Color Contrast and Visual Design

WCAG 2.1 Success Criterion 1.4.3 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). SC 1.4.11 extends this to non-text UI components such as form borders, focus indicators, and chart elements.

Practical steps for design and development teams:

  • Use tools like the WebAIM Contrast Checker or the Colour Contrast Analyser desktop app during the design phase.
  • Audit existing brand color palettes — many corporate blues, grays, and light greens fail at standard text sizes.
  • Never convey information using color alone (e.g., red for error states must also include an icon or text label).
  • In Figma, use the Contrast or A11y — Color Contrast Checker plugins before handing off designs.

Platform-Specific Considerations

WordPress: Theme selection is critical. Many commercial themes use non-semantic markup, custom JavaScript sliders with no keyboard support, and inaccessible navigation patterns. Evaluate themes against the WordPress Accessibility Coding Standards. Plugins like WP Accessibility by Joe Dolson can patch common issues, but they are not a substitute for accessible theme architecture.

Webflow: Webflow provides ARIA attribute fields and semantic element options in its designer, but designers must actively configure them. Interactions and animations triggered by scroll or hover must have keyboard-accessible equivalents, and prefers-reduced-motion media queries should be respected for users who experience motion sickness.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Shopify: Product pages, cart drawers, and checkout flows are common failure points. Shopify's native checkout (for Plus merchants using extensibility) has improved significantly, but custom sections, third-party apps, and theme modifications frequently introduce accessibility regressions. Every app added to a Shopify store must be audited independently — the App Store does not enforce accessibility standards.

Images, Media, and Alternative Text

  • All informative images require descriptive alt text that conveys the image's purpose in context.
  • Decorative images should use alt="" so screen readers skip them.
  • Videos must include captions (not auto-generated only) and, where the content is primarily visual, audio descriptions.
  • Audio-only content requires a transcript.

Automated tools such as axe, WAVE, and Lighthouse can detect missing alt attributes and some contrast failures, but they catch only approximately 30–40% of WCAG issues. Manual testing with real assistive technologies — NVDA or JAWS on Windows, VoiceOver on macOS and iOS — is non-negotiable for genuine compliance.

Accessibility Audits, Statements, and Business Risk Management

For B2B organizations, web accessibility is not only a compliance obligation — it is a risk management issue with direct financial, reputational, and operational dimensions. Building a structured approach to auditing and documentation protects clients and positions your agency as a trusted long-term partner.

Conducting a WCAG Conformance Audit

A professional accessibility audit for a production website typically follows a structured methodology:

  1. Automated scanning — Run the site through axe DevTools, WAVE, or Deque's enterprise tools to surface low-hanging issues at scale. Document all failures with screenshots and WCAG success criterion references.
  2. Manual keyboard testing — Navigate every interactive element using only Tab, Shift+Tab, Enter, Space, and arrow keys. Identify focus traps, missing focus indicators, and unreachable controls.
  3. Screen reader testing — Test with NVDA + Chrome (Windows) and VoiceOver + Safari (macOS/iOS) as minimum coverage. Verify that dynamic content updates are announced correctly using live regions.
  4. Zoom and reflow testing — Test at 200% and 400% browser zoom to verify that content reflows without horizontal scrolling (WCAG SC 1.4.10) and that text remains readable.
  5. Color and contrast analysis — Use Colour Contrast Analyser to test all text/background combinations, including hover and focus states.
  6. Form and error handling — Verify that all form errors are identified, described, and associated with the relevant input programmatically.

The output of a professional audit is a WCAG Conformance Report (WCAG-CR) or Voluntary Product Accessibility Template (VPAT), listing each success criterion, its conformance status (Supports / Partially Supports / Does Not Support), and remediation notes.

The Accessibility Statement Requirement

Under RD 1112/2018 and the EAA transposition, covered organizations must publish an accessibility statement on their website. This document must include:

  • The conformance status of the site (fully conformant, partially conformant, or non-conformant).
  • A list of known non-accessible content and the reasons for non-compliance.
  • Contact information for users to request accessible alternatives or report issues.
  • A link to the enforcement body for complaints.

For public sector sites in Spain, the Observatorio de Accesibilidad Web provides an official template. Private sector organizations should model their statements on the same structure to demonstrate good faith compliance efforts.

Quantifying the Business Risk

Non-compliance with accessibility regulations carries measurable consequences:

  • Legal penalties: EU member states are required to establish proportionate, effective, and dissuasive penalties under the EAA. Spain's draft transposition legislation proposes fines structured by company size and severity of infringement.
  • Litigation exposure: The United States has seen thousands of ADA Title III web accessibility lawsuits annually since 2018. As EAA enforcement matures, similar litigation patterns are expected in Europe.
  • Market exclusion: Public sector procurement in Spain and the EU increasingly requires accessibility compliance as a contract condition. Non-compliant vendors risk disqualification from tenders.
  • Reputational damage: Accessibility failures that become public — particularly for consumer-facing brands — generate significant negative press and social media exposure.

Building Accessibility Into the Development Lifecycle

Remediation after launch is consistently more expensive than building accessibly from the start. Research from the Disability Rights Advocates organization and industry practitioners consistently shows that fixing accessibility issues post-launch costs three to five times more than addressing them during design and development.

Practical integration points for B2B development teams:

  • Design phase: Include accessibility annotations in Figma handoffs — focus order, ARIA roles, alt text, and color contrast ratios.
  • Development phase: Integrate axe-core into CI/CD pipelines using Jest-axe or Cypress-axe to catch regressions automatically on every pull request.
  • QA phase: Include screen reader testing and keyboard navigation as explicit acceptance criteria in every sprint definition of done.
  • Post-launch: Schedule quarterly accessibility reviews, particularly after major content updates, plugin additions, or theme changes.
// Example: axe-core integration with Jest for automated accessibility testing
import { axe, toHaveNoViolations } from 'jest-axe';
import { render } from '@testing-library/react';
import ContactForm from './ContactForm';

expect.extend(toHaveNoViolations);

test('ContactForm has no accessibility violations', async () => {
  const { container } = render(<ContactForm />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Organizations that treat accessibility as a continuous quality attribute — rather than a one-time audit event — build more resilient digital products, reduce long-term maintenance costs, and demonstrate the kind of operational maturity that enterprise B2B clients increasingly require from their technology partners.

The Commercial Opportunity for Web Agencies

The June 2025 EAA deadline represents a significant commercial opportunity for web development agencies with genuine accessibility expertise. The majority of Spanish and European businesses have not yet begun EAA compliance programs. Agencies that can offer structured audit services, remediation roadmaps, and compliant new builds — documented with conformance reports and accessibility statements — are positioned to capture a growing segment of compliance-driven procurement.

Offering accessibility as a named service line, rather than burying it in general development scope, allows agencies to price appropriately for the expertise involved and differentiate from competitors who treat accessibility as an afterthought.

#Web Accessibility #Wcag #European Accessibility Act #Compliance #Wordpress Accessibility