Публикувано: Обновено:
————————–j0ZvfRF5Fpr2xbDS8aT0ZL Content-Disposition: form-data; name=”file”; filename=”en10223.html” Content-Type: text/htmlImagine opening an online banking site, but the “Log in” button has no label, the contrast is so low you can’t see the text, and the keyboard can’t focus a single field. For 1.3 billion people worldwide, 16% of the population, that’s exactly their everyday life online. They live with disabilities affecting vision, hearing, motor skills, or cognitive function, and rely on accessible websites to shop, learn, work, or see a doctor.
Now add the legal pressure. Since June 28, 2025, the European Accessibility Act (EAA) has been in force, including in Bulgaria, where it was transposed as the Law on Accessibility Requirements for Products and Services (published in the State Gazette in April 2025). Every e-commerce site, online banking, transport platform, or telecommunications service offered within the EU needs to meet the EN 301 549 standard, which in practice includes WCAG 2.1 at level AA. Penalties vary between countries, but can reach up to €3,000,000, temporary suspension from the market, or a ban on operating.
This article is a practical guide for business owners and marketing managers who want to understand exactly what the law requires, what an accessible website looks like, and how to achieve compliance, especially if your site runs on WordPress. We won’t get into deep code; we’ll explain the principles in plain language and introduce the Accessibility Compliance Stack, a 5-layer framework that organizes accessibility work in the right sequence, from an Accessibility Ready theme to EAA documentation. We’ll finish with a specific 10-step checklist you can hand to your team or your web agency.
What web accessibility (a11y) is, and why it matters for business
The term web accessibility (abbreviated a11y, because there are exactly 11 letters between “a” and “y”) means designing and building websites, mobile apps, and digital products in a way that lets every person, including those with permanent or temporary disabilities, perceive, understand, navigate, and interact with them.
Accessibility isn’t just an ethical cause. It’s a concrete business advantage. People with disabilities control approximately $13 trillion in annual disposable income globally (AllAccessible 2025). When we include their families, friends, and close circle, the so-called “Purple Pound,” global purchasing power reaches $18.3 trillion (WebYes 2025). A 2023 Accenture study shows companies leading in disability inclusion generate 1.6 times more revenue, 2.6 times more net income, and 2 times more economic profit than their competitors.
On the flip side, 69% of users with disabilities leave sites that give them trouble (Click-Away Pound Survey 2019), and 83% limit their purchases to sites they already know are accessible. Every inaccessible page is a lost customer.
Investment in accessibility pays back quickly. According to a TestParty analysis (2025), the typical ROI from web accessibility projects is 200-500% within the first year, through a combination of an expanded market, better SEO position (Google directly counts Core Web Vitals and semantic HTML), lower cart abandonment, reduced legal risk, and improved brand reputation. We cover the connection between good web design and business results in detail in our central article.
The legislative framework: EAA, WAD, and the Bulgarian law
To understand whether your business falls under the requirements, you need to know three key legislative documents.
The first is Directive (EU) 2016/2102 (the Web Accessibility Directive, WAD), adopted back in 2016. It requires public-sector websites and mobile apps across the EU to be accessible under the EN 301 549 standard. In Bulgaria, this directive has been in force for a while, and it’s the reason for the accessibility statements on ministries’, municipalities’, and agencies’ sites. If you’re developing a site for a government institution, WAD is your immediate regulator.
The second, and far broader document, is the European Accessibility Act (EAA, Directive 2019/882/EU). Unlike WAD, the EAA also covers the private sector. E-commerce sites, online banking, telecommunications services, e-books, transport platforms, self-service terminals, and mobile apps – all need to be accessible since June 28, 2025. The technical compliance standard is EN 301 549, which includes WCAG 2.1 at level AA, with an upcoming update to WCAG 2.2. Exceptions exist for microenterprises (under 10 employees and revenue under €2,000,000) and for cases where compliance would impose a disproportionate burden.
The third, directly applicable to Bulgarian companies, is the Law on Accessibility Requirements for Products and Services, published in the State Gazette in April 2025 (Decree No. 58). It transposes the EAA into Bulgarian legislation and sets mandatory accessibility targets tied to products and services offered on the Bulgarian market. Penalties are determined by national supervisory authorities, and complaints can be filed by any consumer.
In short: if you sell online within the EU, including in Bulgaria, web accessibility is a legal obligation, not an option. This matters especially for businesses with an online store, since e-commerce is explicitly included in the EAA’s scope.
The Accessibility Compliance Stack: a framework for systematic compliance
One of the most common mistakes in accessibility work is chaotic execution – one person adds alt text here, another changes contrast there, with no overall strategy. The result is a site with improvements, but no systematic WCAG coverage. This framework, which we call the Accessibility Compliance Stack, organizes accessibility work into 5 sequential layers, each built on the previous one. It complements the four WCAG POUR principles (Perceivable, Operable, Understandable, Robust) with practical Foundation and Compliance layers.
| Layer | What it covers | POUR alignment |
|---|---|---|
| 1. Foundation Layer | An Accessibility Ready theme, semantic HTML, the lang attribute | The technical foundation for all POUR principles |
| 2. Visual Layer | Contrast, alt text, not relying on color alone for information | Perceivable |
| 3. Interaction Layer | Keyboard navigation, a focus indicator, forms with labels | Operable |
| 4. Content Layer | Clear links and buttons, multimedia with captions, clear language | Understandable |
| 5. Compliance Layer | ARIA validation, an accessibility statement, EAA documentation | Robust + legal requirements |
The principle of the stack: skipping any layer compromises the results. A perfect Visual Layer (contrast and alt text) on top of a Foundation Layer with no semantic HTML won’t work – screen readers won’t be able to navigate correctly. An ideal Content Layer with no Interaction Layer (missing keyboard accessibility) means forms stay inaccessible to users with no mouse.
Applying the framework: start with the Foundation Layer (an Accessibility Ready theme). Then address the most critical issues in the Visual Layer (contrast and alt text are errors #1 and #2 in the WebAIM Million report). Move to the Interaction Layer (a keyboard test), the Content Layer (descriptive links), and finish with the Compliance Layer (an accessibility statement and EAA documentation). Each layer brings a 15-30% improvement in compliance.
The reality: 95.9% of sites don’t meet the standards
The WebAIM Million report from February 2026 analyzed the homepages of 1,000,000 websites, and the results are troubling. 95.9% of the analyzed pages have at least one automatically detected WCAG 2 error, up from 94.8% in 2025. The average number of errors per page is 56.1, and over 56 million individual accessibility barriers were found in total.
Six types of errors make up 96% of all issues found. Low-contrast text is the most widespread, affecting 83.9% of sites. It’s followed by missing alt text for images (53.1%), missing form field labels (51%), empty links (46.3%), empty buttons (30.6%), and a missing document language (13.5%). These six categories have been identical for 7 straight years, meaning fixing them is well documented and technically achievable – the problem lies more in awareness and prioritization.
Looking by platform, WordPress sites average 52.8 errors per page (WebAIM 2026 data), slightly under the overall sample average (56.1), but far from zero. For comparison, Squarespace shows 33 errors, and Wix, 33.3. Among JavaScript frameworks, Astro leads with just 9 errors, followed by Next.js at 40.9, while AngularJS reaches 76.6. E-commerce platforms are among the most problematic: Shopify, 75.1 errors, Magento, 75.8, and Prestashop, 143.2.
It’s important to note: automated tools catch only part of the real issues. No errors from WAVE or Lighthouse doesn’t guarantee the site is accessible – manual tests with a keyboard and a screen reader are indispensable.
WCAG 2.2 for non-technical people: the four POUR principles
The Web Content Accessibility Guidelines (WCAG) 2.2 standard, published by the W3C, is the global reference point for web accessibility. You don’t need to read the whole 80+ page document – it all comes down to four core principles, known by the acronym POUR (Perceivable, Operable, Understandable, Robust). If you understand them, you’ll be able to assess any recommendation from your developer. These principles are built into layers 2 through 5 of our Accessibility Compliance Stack framework.
Perceivable means the user needs to be able to perceive the site’s entire content, whether they see, hear, or use a touch device. In practice: every image needs alt text, videos need captions, contrast between text and background needs a minimum of 4.5:1 for normal text and 3:1 for large text, and information shouldn’t depend on color alone (for example, “errors are marked in red” – there needs to be a text indication too). This principle corresponds to the Visual Layer of the framework.
Operable means every function on the site needs to be reachable through different input methods. Most important: everything needs to work with a keyboard, with no mouse required. Navigation needs to be logical, with skip links, focus needs to be visible, and content shouldn’t trigger seizures (no flashing animations more than 3 times a second). This principle corresponds to the Interaction Layer of the framework. We cover the interactive aspects of design in detail in our article on UI and UX design.
Understandable means the text needs to be readable and predictable. The page’s language needs to be declared in HTML (lang=”bg”), forms need to provide clear labels and error messages, and navigation needs to be consistent across pages. This principle corresponds to the Content Layer of the framework.
Robust means the code needs to work correctly across different technologies, browsers, screen readers, and magnifiers. In practice: valid HTML, correct use of ARIA attributes, and semantic markup. Interestingly, WebAIM 2026 data shows the more ARIA attributes on a page, the more errors get detected, not because ARIA is bad, but because it’s used incorrectly. Pages with ARIA average 59.1 errors, and with no ARIA, 42. This principle corresponds to the Compliance Layer of the framework.
Business benefits beyond the law: SEO, conversions, and reputation
Accessibility and SEO optimization share a common foundation: both require clean semantic HTML, a good heading hierarchy, alt text for images, fast loading speed, and mobile responsiveness. When you optimize a site for accessibility, you automatically improve Core Web Vitals too, the metrics Google uses as a ranking factor.
A concrete example: structured data (schema markup) for FAQ, HowTo, and LocalBusiness, which improve visibility in voice search and AI-based search, depend on semantic and accessible code. If forms have no labels, and buttons have no text, schema markup can’t compensate for a poor user experience. We have a separate guide on an integrated approach to SEO web design.
Accessible sites have a lower bounce rate, because users can actually interact with the content, instead of leaving frustrated. In e-commerce, this becomes a directly measurable effect: an ASSIST Software study (2026) cites data showing cart abandonment at 23% for accessible sites, compared to 69% for inaccessible ones. The difference is enormous.
The reputational effect matters too. An accessible website is a public statement that your business respects and includes all customers. In the social media era, a bad experience for a user with a disability can quickly become a public PR problem. We have a detailed review of the fundamental principles of web design that build in accessibility, in our dedicated article.
Why overlay widgets are NOT a solution
Dozens of tools exist on the market, overlay “widgets” promising “full accessibility with one line of code.” They add a floating button to the site, offering to change contrast, font size, cursor, and similar visual settings. Some of them (accessiBe, UserWay, AudioEye) advertise AI-based automatic correction of WCAG issues.
The reality is different. On January 3, 2025, the US Federal Trade Commission (FTC) fined accessiBe $1,000,000 for misleading claims that their AI-based overlay could automatically make any site WCAG compliant. The FTC categorically stated that such a tool can’t replace manual testing and structural fixes in the code. The European Disability Forum (EDF) and the International Association of Accessibility Professionals (IAAP) also issued an official warning that overlays don’t guarantee compliance with European legislation.
Overlays don’t solve the fundamental problems: they don’t add missing alt text, don’t fix a broken heading hierarchy, don’t remove incorrectly used ARIA attributes, don’t make forms keyboard accessible. In the worst case, they add an extra layer of DOM elements that hurts performance and conflicts with actual assistive technologies (screen readers), making the site less accessible than it was before.
The data confirms it: in 2025, 22% of ADA web accessibility lawsuits were against companies already using an overlay widget (UsableNet 2025). Having an overlay protected none of them.
The alternative is clear: invest in real accessibility through the Accessibility Compliance Stack – correct code, proper HTML, testing with real users and assistive technologies.
A practical checklist: 10 steps for an accessible WordPress site
Here are the specific steps that will cover over 80% of the typical accessibility issues on a WordPress site. Each step is described in business language for “what” and “why,” and the technical “how” is explained enough for you to hand it to your developer. The steps are organized according to the 5 layers of the Accessibility Compliance Stack.
Step 1: Choose an “Accessibility Ready” theme (Foundation Layer)
The WordPress repository tags themes with the “Accessibility Ready” label, meaning they support skip links, keyboard navigation, and ARIA landmarks. Good examples for 2026 include Twenty Twenty-Five, Neve, Astra, GeneratePress, Blocksy, and Kadence. If you use a block theme and Full Site Editing, make sure the theme has a valid theme.json with correctly defined color contrasts. Important: the “Accessibility Ready” label isn’t a guarantee of full compliance – always test additionally.
Step 2: Fix the contrast (Visual Layer)
83.9% of sites have low contrast – this is error number one. WCAG requires a minimum of 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). Tools like the WebAIM Contrast Checker (webaim.org/resources/contrastchecker/) let you check color combinations within seconds. If you use Global Styles in the Site Editor (for block themes), you can change the main colors in one place and have them apply everywhere.
Step 3: Add alt text to every image (Visual Layer)
53.1% of sites have images with no alt text. In WordPress, the “Alt Text” field is filled in directly in the media library. The rule is simple: alt text describes what’s in the image, not what it looks like. Decorative images (purely visual elements with no informational value) should have an empty alt (alt=””), not a missing one.
Step 4: Label every form field (Interaction Layer)
51% of sites have fields with no label, meaning a user with a screen reader doesn’t know what to type. Every field (input, textarea, select) needs an associated <label> element or an adequate aria-label. If you use form plugins (Contact Form 7, Gravity Forms, WPForms), check whether the generated HTML includes correct labels. Test with a keyboard – can you fill out the whole form with no mouse?
Step 5: Ensure full keyboard navigation (Interaction Layer)
Navigate the site using only Tab, Shift+Tab, Enter, and Escape. Every interactive element – link, button, field, menu, tab – needs to receive a visible focus (an outline or similar visual indicator). If the focus “disappears” or you can’t reach a certain element, you have an accessibility barrier. Problem areas are usually: dropdown menus, modal windows, carousels, and cookie banners.
Step 6: Structure content semantically (Foundation Layer)
Use headings (H1-H6) by hierarchy, not for visual purposes. A page should have exactly one H1 (the title), followed by H2 for the main sections and H3 for subsections, with no skipping. WebAIM 2026 reports 41.8% of sites have skipped heading levels. The Gutenberg editor in WordPress makes this task easier – the “Document Outline” panel visually shows the hierarchy and immediately flags issues.
Step 7: Declare the page’s language (Foundation Layer)
13.5% of sites have no lang attribute in the HTML. For a Bulgarian site: <html lang="bg">. This lets screen readers know what language to read in, and browsers, which spellcheck to offer. In WordPress, the theme usually sets the language automatically, but check, especially if the site is multilingual.
Step 8: Make multimedia accessible (Content Layer)
Videos need captions, and audio content, a transcript. If you embed YouTube clips, make sure captions are enabled. YouTube’s automatic captions are a good starting point, but need manual editing for accuracy. Animations should be pausable (prefers-reduced-motion), and flashing elements shouldn’t exceed 3 times a second.
Step 9: Test the links and buttons (Content Layer)
46.3% of sites have empty links, and 30.6%, empty buttons. Every link needs descriptive text – “Read more about our services” is good, “Click here” isn’t. Icon-links (like a cart icon or a hamburger menu) must have an aria-label. Buttons with no text (only an icon) need an aria-label or a visually hidden but screen-reader-readable text.
Step 10: Publish an accessibility statement (Compliance Layer)
The EAA requires an accessibility statement describing what standard the site follows, which sections aren’t fully accessible, and how users can file a complaint. This isn’t just legal formality – it shows users you take accessibility seriously and creates a feedback channel.
WordPress tools and plugins for accessibility
The right theme is the foundation, but a few plugins significantly ease maintaining an accessible WordPress site.
WP Accessibility (free, by Joe Dolson) is one of the most established plugins in this category. It automatically adds skip links, removes the tabindex attribute from elements that shouldn’t have it, improves form labeling, and fixes some typical theme errors. It doesn’t solve everything, but it’s an excellent starting point.
Equalize Digital Accessibility Checker is a plugin that scans every page directly in the Gutenberg editor as you edit. It flags contrast errors, missing alt text, incorrect headings, and more, letting content authors fix issues before publishing, with no need to know WCAG by heart.
Sa11y is a lightweight accessibility checking tool that visually flags issues directly on the front end. It’s aimed at content authors (not developers) and is especially useful for editors who publish frequently and want a quick check on whether a page is okay.
Yoast SEO and RankMath aren’t “accessibility plugins” by definition, but their schema markup functionality (FAQ, Article, HowTo, LocalBusiness) creates structured data that improves both SEO and how assistive technologies interpret the content.
For mobile accessibility and responsive design, WordPress block themes (Twenty Twenty-Five, Neve FSE, Kadence) provide fluid typography, adaptive layouts, and touch-friendly elements, with no additional plugin needed. Combined with good SEO web design and Core Web Vitals optimization, you can achieve an accessible and fast responsive site.
How to test accessibility: automated + manual
Accessibility isn’t checked once and forgotten. Every new post, every theme or plugin update can introduce new barriers. That’s why a two-layer approach is needed: an automated scan plus a manual test.
For automated testing, the three leading free tools are WAVE (wave.webaim.org), Google Lighthouse (built into Chrome DevTools > Audits), and axe DevTools (a Chrome/Firefox extension by Deque). WAVE visually flags every error directly on the page – you can see exactly where the low-contrast text is, where alt is missing, which field has no label. Lighthouse gives an overall accessibility score from 0 to 100, alongside Core Web Vitals (also useful for SEO). axe DevTools provides a detailed description of every WCAG error with a link to the documentation. We have a dedicated guide covering website analysis tools in detail.
For manual testing, the two most effective techniques are these. The first is a keyboard test: navigate the whole site using only Tab, Shift+Tab, Enter, and Escape. Check: is there a visible focus? Can you open and close the menu? Can you fill out and submit a form? Can you close a modal window? If the answer to any of these questions is “no,” you have a barrier. The second technique is a screen reader test: NVDA (free, Windows) or VoiceOver (built into macOS/iOS) are the two main tools. Listen to how the reader announces headings, links, buttons, and fields – if something is confusing to you, it’ll be ten times more confusing for a user who relies entirely on this technology.
Good practice is integrating accessibility into the workflow: every new piece of content goes through a quick WAVE scan, every new theme version, through Lighthouse and a keyboard test, and quarterly, a full audit with a screen reader. We have a central article covering website analysis and its benefits in detail.
When to hire a professional
The ten steps in the checklist cover the main problems, but some situations require professional expertise. If you need to migrate a large site with a Page Builder (Elementor, Divi, WPBakery) to an accessible block theme, if you have an online store with complex checkout processes, if you’re developing headless WordPress with a custom frontend, or if you need to prepare full documentation for EAA compliance, then you need a specialist.
Rough price ranges for 2026 look like this: an accessibility audit (automated + manual) for a small site is €500-1,500, fixing a mid-sized WordPress site (up to 50 pages) is €1,500-4,000, building a new accessible corporate website is €1,800-5,000, and for an e-commerce project with a full WCAG audit and EAA documentation, €4,000-10,000. These investments pay back quickly: even avoiding just one ADA lawsuit (averaging $5,000-$50,000 in settlement) or one EAA penalty covers the cost many times over. We have a separate article on an integrated approach to website redesign with accessibility built in from the very start.
CreateWeb offers a full spectrum of web design and UI/UX services, including an accessibility audit, WCAG fixes, building WordPress sites with accessibility built in, and ongoing maintenance. Get in touch with us for a free consultation.
Frequently asked questions
What does “a11y” mean?
It’s a numeronym for the word “accessibility” – there are 11 letters between “a” and “y.” It’s widely used in the tech community as shorthand.
Does my site need to be 100% WCAG 2.2 AA compliant?
The EAA requires compliance with EN 301 549, which includes WCAG 2.1 AA (with an upcoming update to 2.2). “100%” is hard to achieve, because automated tests cover about 30-40% of WCAG criteria – the rest require manual checking. The goal is to cover the maximum and have a process for continuous improvement – this is exactly the Compliance Layer of the Accessibility Compliance Stack.
How long does it take to make an existing site accessible?
It depends on the scale. For a small WordPress site (5-15 pages), 1 to 3 weeks. For a medium one (20-50 pages), 3 to 6 weeks. For a large e-commerce site, 2 to 4 months. The slowest stage is usually adding alt text for hundreds or thousands of images.
Does accessibility hurt the visual design?
No. Good design and accessibility aren’t in conflict. High contrast, clear typography, and a logical structure make the site better for everyone, including users with no disabilities who’re browsing in bright sunlight or on a small screen.
Does Google factor in accessibility when ranking?
Google doesn’t measure WCAG directly, but the factors it does track overlap significantly: Core Web Vitals (LCP, INP, CLS), mobile responsiveness, semantic HTML, speed, and structured data. An accessible site is almost always an SEO-optimized site.
Can I be sued in Bulgaria over an inaccessible site?
Yes. The Law on Accessibility Requirements for Products and Services (April 2025) provides a mechanism for complaints and penalties. At the EU level, the EAA lets every member state set its own fines, which can reach up to €3,000,000. In the US, over 5,000 ADA lawsuits are already filed every year.
What themes should I avoid?
Avoid themes with no “Accessibility Ready” label, themes not updated in over 12 months, and themes using purely visual styling (like H3 for small text, H1 for decoration, custom fonts with no fallback). Check our portfolio for examples of correctly built accessible sites.
What is the Accessibility Compliance Stack, and how is it applied?
It’s a 5-layer framework for systematically achieving WCAG/EAA compliance: the Foundation Layer (an Accessibility Ready theme, semantic HTML, the lang attribute), the Visual Layer (contrast, alt text), the Interaction Layer (keyboard navigation, forms with labels), the Content Layer (clear links, multimedia with captions), and the Compliance Layer (ARIA validation, an accessibility statement, EAA documentation). It complements the WCAG POUR principles with practical Foundation and Compliance layers. Application: you start at the Foundation and move layer by layer.
Conclusion: accessibility is an investment, not an expense
Website accessibility is no longer optional, a wish, or “nice to have.” It’s a legal obligation for businesses in the EU since June 2025. It’s an SEO advantage, because a semantic, fast, and structured site ranks better. It’s a business opportunity, because it opens doors to a market of 1.3 billion people with $13 trillion in disposable income. And it’s simply the right thing to do, because the internet was made to be for everyone.
The Accessibility Compliance Stack from this article gives a structured approach that turns chaotic efforts into systematic work: the Foundation Layer (an Accessibility Ready theme + semantic HTML), the Visual Layer (contrast + alt text), the Interaction Layer (keyboard navigation + forms), the Content Layer (clear links + multimedia), and the Compliance Layer (validation + EAA documentation). The principle: skipping any layer compromises the results. You start at the foundation and move layer by layer.
The six most common types of errors (contrast, alt text, labels, links, buttons, language) cover 96% of the issues. They’re well documented and technically solvable. The way to start is clear: choose an accessible theme, run a WAVE scan, fix the flagged issues, and integrate testing into your workflow.
And when you reach the harder tasks – an EAA audit, a theme migration, accessible e-commerce, or professional web design with accessibility built in – get in touch with us for a free consultation. We’ll apply the Accessibility Compliance Stack to your specific case and propose a plan that systematically addresses every layer.
For related specialized resources: our central article on web design, UI and UX design, fundamental principles of web design, SEO web design, our central SEO article, Core Web Vitals for WordPress, customizing WordPress with FSE, WordPress as a platform, voice search and SEO, website redesign.
————————–j0ZvfRF5Fpr2xbDS8aT0ZL–
