Web accessibility in Spain — what the law requires and how to comply

Web accessibility in Spain is governed by two overlapping frameworks: the European Accessibility Act (implemented in Spanish law as Real Decreto 1112/2018 and its updates) and the broader WCAG 2.1 guidelines that underpin all European accessibility standards.

For years, compliance was primarily a public sector concern. That's changing. The scope is expanding, enforcement is becoming more active, and the practical case for accessible design has become strong enough that even businesses without a legal obligation are investing in it.

Who is currently required to comply

Public sector bodies: All public administration websites and mobile applications in Spain must meet WCAG 2.1 AA standard. This has been mandatory since 2020, with updated requirements phasing in through 2025.

Private sector (by size and sector): The European Accessibility Act has brought new obligations for private businesses offering digital services. Large enterprises and certain service categories (banking, transport, telecommunications, e-commerce platforms) face compliance requirements from 2025 onwards. The threshold definitions are still being interpreted in Spanish implementation, but the direction is clear.

Anyone who wants to avoid risk: Accessibility lawsuits and regulatory complaints are increasing across Europe. A site that excludes users with disabilities is a liability — both reputationally and legally.

What WCAG 2.1 AA actually requires

The four principles are Perceivable, Operable, Understandable, Robust. In practical terms, for most business websites:

Visual:

• Text must have sufficient contrast against backgrounds (4.5:1 for normal text, 3:1 for large text)
• Images must have descriptive alt text
• The site must be usable at 200% zoom without loss of functionality
• Do not use colour as the only way to convey information

Navigation:

• All functionality must be usable with a keyboard alone (no mouse required)
• There must be a way to skip repetitive navigation blocks
• Page focus must be clearly visible when navigating by keyboard
• Forms must have properly associated labels

Content:

• Language must be declared in the HTML
• Pages must have descriptive titles
• Error messages must be clear and specific about what went wrong
• Links must have descriptive text (not just "click here")

Structure:

• Headings must be used correctly in hierarchy (H1 → H2 → H3, not skipped)
• Tables must have proper header markup
• PDFs linked from the site must also be accessible

The accessibility statement

Spain's Real Decreto 1112/2018 requires public sector bodies to publish an accessibility statement on their site. For private sector companies entering scope under the European Accessibility Act, similar documentation is expected.

An accessibility statement typically covers: the standard being aimed for, known issues and planned resolution dates, the date of last review, and a contact mechanism for reporting accessibility problems.

Even for companies not legally required to publish one, having an internal accessibility audit and remediation plan is good practice.

How to audit your current site

Automated tools (free): WAVE (wave.webaim.org), Google Lighthouse (built into Chrome DevTools), axe DevTools (browser extension). Automated tools catch about 30–40% of accessibility issues — enough for a first pass.

Manual testing: Tab through every page with no mouse. Check that every interactive element can be reached and activated. Use a screen reader (NVDA for Windows, VoiceOver for Mac/iOS) to navigate at least your key pages.

Colour contrast: Run all foreground/background colour combinations through a contrast checker (webaim.org/resources/contrastchecker). This is one of the most common failures.

Fixing the most common issues

Most accessibility failures on well-built modern websites come down to four things:

1. Missing or uninformative alt text on images
2. Insufficient colour contrast (usually in muted placeholder text or secondary buttons)
3. Forms without properly associated labels (the label element not connected to the input via for/id pairing)
4. Interactive elements that aren't keyboard-focusable (custom JavaScript UI components that don't handle keyboard events)

These are all fixable without rebuilding your site. For sites with more systemic issues — incorrect heading structure, broken focus management, inaccessible navigation — more significant work is needed.

We include accessibility review as part of our web development work and can audit an existing site as a standalone engagement. For businesses in scope for the European Accessibility Act, getting ahead of this now is significantly cheaper than retrofitting under regulatory pressure. Book a call if you want to understand where your site stands.