WCAG 2.2 for foundations in 2026: when you must, when you should, and what to fix first

WCAG for foundations in 2026 is a topic that comes back with every grant application, most often in the final stage of evaluation. Most Polish foundations live in one of two beliefs. First: "WCAG doesn't apply to us, it's for government agencies." Second: "WCAG applies to everyone from June 28, 2025, so we bought an audit for €200 and we're fine." Both are half-true and both cost money. The first, when a grant reviewer ticks "site not compliant with WCAG 2.1 AA" on the scoring sheet and the application fails in the final round. The second, when the "compliance audit" turns out to be a Lighthouse-generated PDF that catches at most 30 percent of real issues. In this article we untangle three things: when a foundation must comply with WCAG, why it almost always pays off even when not required, and what to actually fix first when an audit comes back bad.

About 30,000 active foundations are registered in the Polish KRS sector 8 (public benefit organizations and volunteering). A significant share regularly apply for funding from the Polish EU Cohesion Funds, KPO (National Recovery Plan), NIW, or carry out tasks delegated by government agencies, which automatically pulls them into the WCAG requirement regardless of "public body" status. Short answer for someone who wants to paste it into a board presentation: a standard foundation running an information website, accepting donations, publishing annual reports and delivering grant projects has no legal WCAG obligation under the Act of 4 April 2019 or the EAA. It does have such an obligation in practice every time it uses public funds or executes a contract with a government agency. We break this down below.

The Act of 4 April 2019 on the digital accessibility of websites and mobile applications of public bodies (Dz.U. 2019 item 848, consolidated text Dz.U. 2023 item 82, amended by the Act of 9 March 2023 in force since 17 April 2023) requires WCAG 2.1 AA compliance. Technical requirements are deemed met when the entity ensures accessibility in line with sections 9, 10 and 11 of EN 301 549 (the Polish standard implementing ETSI EN 301 549 V3.2.1:2021).

The critical point for foundations is Article 2. It lists public finance sector units, state organizational entities, legal persons established to satisfy needs of a general nature, their associations, and in point 5: "non-governmental organizations referred to in Article 3(2) of the Act of 24 April 2003 on Public Benefit Activity and Volunteering (…) operating in the public-task spheres listed in Article 4(1) point 6, 7 or 10 of that Act."

In practice the Act covers NGOs whose statutory aims include:

A foundation running a helpline, hospice, senior center or a support program for people with visual impairment is a public body under this Act. An educational, cultural, environmental, legal foundation, or one supporting children, youth or entrepreneurship is not, even if it receives grants. The position of the Polish Ministry of Funds and Regional Policy in its reply to the editors of ngo.pl is unambiguous: funds obtained as grants for delivering public tasks do not turn the organization into a public body. What decides is the sphere of statutory aims.

Penalties for breaching the Act are limited: up to 10 times the average wage (currently around PLN 10,000) for unjustified and persistent failure to ensure site or app accessibility, and up to PLN 5,000 for missing an accessibility statement or required elements within it. The penalty is imposed by the minister responsible for digitization after two or three consecutive monitoring rounds.

Directive (EU) 2019/882 of the European Parliament and of the Council (European Accessibility Act, EAA) was transposed into Polish law by the Act of 26 April 2024 on ensuring compliance with accessibility requirements for certain products and services by economic operators (informally the "Polish Accessibility Act," PAD). The Act entered into force on 28 June 2025. The supervisory body for digital services is the President of the Management Board of PFRON, among others. Other market surveillance bodies are designated for products and services in trade.

What does this mean for foundations?

A standard foundation that has an information website with a donation form, a blog and annual reports legally does not provide e-commerce services within the meaning of the EAA. A donation is not a consumer sales contract. EAA provisions do not reach this far.

The situation changes when a foundation runs:

In that case the foundation, if it does not meet the microenterprise criteria, is an "economic operator" under PAD and falls under the same obligations as a commercial company. Penalties reach up to ten times the average wage and can be repeated until the operator removes the violation.

Two sentences worth keeping in mind: the EAA did not change the legal situation of a foundation running only an information site and accepting donations. It changed it radically only for foundations running e-commerce or consumer services from the Act's catalog.

Regardless of whether a foundation is a "public body," every grant from EU or domestic public funds in the current perspective requires WCAG compliance. Three key sources.

Polish EU Cohesion Funds 2021–2027 (FENG, FERS, FEnIKS, FEdLŚ and regional programs). The decisive document is the "Guidelines on implementing equality principles within EU funds for 2021–2027" published by the Polish Ministry of Funds and Regional Policy. Annex 2 to the Guidelines contains "Accessibility standards for cohesion policy 2021–2027," including the digital standard. The position is unambiguous: "All project outputs (including services) that receive EU funding must be accessible to all their users." The digital standard refers to WCAG 2.1 AA as the reference level. Non-compliance with the Guidelines can result in expenses being deemed ineligible, in extreme cases loss of funding and obligation to return it. All EU Funds programs allow accessibility expenses to be flagged with a dedicated marker ("Accessibility expenses") in SL2021.

KPO (Polish National Recovery Plan). Component C "Digital transformation" and Component F "Improving institutional quality" explicitly reference accessibility as a horizontal condition. KPO-funded reforms and investments inherit accessibility rules from the Strategy for Persons with Disabilities 2021–2030 and the Accessibility Plus program. In practice, calls include clauses such as: "The beneficiary undertakes to ensure compliance of digital products with WCAG 2.1 AA and to publish an accessibility statement."

NIW-CRSO (NOWEFIO, PROO, Youth Fund, Program for the Development of Counseling Organizations). The 2026 edition regulations, published in autumn 2025, continue the accessibility requirement stemming from the public-task delegation contract. In practice the contracting party publishes materials, forms and project sites in line with accessibility requirements, and the beneficiary (the foundation) is responsible for their content. Some calls add strategic criteria rewarding projects that increase accessibility.

Norway and EEA Grants (4th edition 2021–2028). Poland signed Memoranda of Understanding on 23 April 2025; the allocation is EUR 925 million. The first calls launch in 2026. The Norway Grant regulations (Regulations on the implementation of the EEA/Norway Financial Mechanism 2021–2028) treat accessibility as a horizontal principle, and program operators (including the Civil Society Fund) traditionally require beneficiaries to produce accessible project sites, accessible documents and accessible promotion.

The Justice Fund in components targeting NGOs (such as victim support) operates in the logic of public-task delivery, so it inherits requirements from the Act of 19 July 2019 on ensuring accessibility for persons with special needs (Article 4(3)) and the digital accessibility act in the scope of the delegated task.

Practical rule: when preparing an application to a publicly funded program, read the regulations and search for "accessibility" or "WCAG", you will find the requirement in 95 percent of cases. Absence of the keyword does not mean the requirement is gone, because the Equality Guidelines override individual EU Funds programs.

According to the Polish Central Statistical Office (GUS) Labour Force Survey (BAEL), there are about 3.1 million people with legally recognized disabilities in Poland (2023 data), and nearly 7 million people declaring health limitations affecting daily functioning. Add to that seniors, mobile users with reduced contrast in sunlight, and people with temporary impairments (broken hand, eye infection). Together, 15–20 percent of internet users in Poland regularly run into the barriers WCAG addresses.

For a foundation whose mission is help, education or social change, an inaccessible website is a contradiction of the mission. Concretely: a patient with visual impairment who cannot fill out an application form. A senior who does not click the donate button because the target is 18 pixels. A deaf person who does not understand the president's video about a support program.

Three measurable arguments, not mission-driven ones:

Short definition: WCAG (Web Content Accessibility Guidelines) is the international standard for web content accessibility developed by the W3C. Version 2.2 became an official W3C Recommendation on October 5, 2023 (updated December 12, 2024) and ISO/IEC 40500:2025 standard on October 21, 2025. WCAG 2.2 is fully backward compatible with WCAG 2.1 and 2.0, adds nine new success criteria and removes one (4.1.1 Parsing).

An important asymmetry: Polish law (Act of 4 April 2019, Act of 26 April 2024 implementing the EAA) still references WCAG 2.1 AA. The EU Funds Equality Guidelines do as well. But if you are building or refreshing a site in 2026, the cost of adding 2.2 criteria is zero or minimal (most are small CSS and UX changes), and within 2–3 years Polish law and grant regulations will certainly shift to 2.2. So: legally 2.1, but build to 2.2.

The whole structure of WCAG rests on four principles (the POUR acronym):

Under each principle there are guidelines, and under those "success criteria" labeled with a three-part number (e.g., 1.4.3 is the third criterion under the fourth guideline of the first principle).

Each success criterion has an assigned level: A (most basic), AA (extended) or AAA (advanced). The legal and grant standard in Poland, the EU and most jurisdictions is AA. This means a site must satisfy all level A and all level AA criteria. Level AAA is aspirational: W3C explicitly states that full AAA conformance is not recommended for entire sites because not all content can be adapted to it.

In WCAG 2.2 there are 86 success criteria total (after adding nine new and removing 4.1.1 Parsing): 30 at level A, 24 at AA and 32 at AAA.

The nine new criteria address gaps in real-world usage: focus hidden under a sticky header, small tap targets, forced cognitive tests at login, repeating the same data across forms.

The removed criterion 4.1.1 Parsing concerned HTML syntax correctness. Modern browsers fix parsing errors themselves, and duplicate-ID or wrong-role issues are covered by other criteria.

For foundations in 2026 the most important are: 2.5.8 Target Size (most foundations have undersized social media icons and CTAs), 2.4.11 Focus Not Obscured (sticky header covers the first element after Tab), 3.3.7 Redundant Entry (donation forms asking for the address twice).

A list from our audits of dozens of recent NGO sites. For each item: what it is, why it is a problem, how to spot it.

The classic cardinal sin. A hero with a stock photo (smiling person against the sky), a white headline "Help us help" on top. Mid-screen the contrast drops below 3:1, and a low-vision user, a mobile user on a sunny day, or an OCR reader cannot read the text. Violated criterion 1.4.3 Contrast (Minimum), AA, requires 4.5:1 for normal text and 3:1 for large (18pt regular or 14pt bold).

How to spot: use WebAIM Contrast Checker, Stark or TPGi Colour Contrast Analyser. Check contrast at the weakest point of the background.

Fix: a darkened overlay (black semi-transparent gradient at 40–60 percent), a solid background under the headline (a tile with padding), or removing text from the photo.

The foundation runs a charity gala, takes 80 photos, uploads a gallery. All images have alt="" or the file name "IMG_4521.jpg." A screen reader announces "image, IMG 4521 dot jpg," "image, IMG 4522 dot jpg" eighty times.

Violated criterion 1.1.1 Non-text Content, A.

Fix: write a short, descriptive alt for images carrying information (e.g., "Marta Kowalska handing the prize to a contest laureate"). Mark purely decorative images with empty alt (alt=""), then the screen reader skips them. Don't write "photo X," "image Y", screen readers announce that themselves.

The most painful one because it touches monetization. A transfer form has nice placeholders ("Name," "Email"), no <label> elements and no error messages tied via aria-describedby. A screen reader user "sees" four edit fields without names.

Violated criteria 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions, 4.1.2 Name, Role, Value, all level A.

Fix: every <input> gets a <label for="…">. Validation messages marked aria-live="polite" and tied to the field via aria-describedby. Treat placeholder as a hint, not a label.

The foundation prints the report, signs it, scans at 300 DPI, uploads the PDF to the "Documents" section. The file is an image with no text layer. A screen reader says "empty document," a grant reviewer cannot copy the table, a user cannot search.

Violated criteria 1.1.1 Non-text Content and 1.4.5 Images of Text (level AA).

Fix: export the report from Word or InDesign to a tagged PDF (PDF/UA). If you must have signatures, attach the scanned version, but publish the accessible version as the primary document.

A moving carousel of three slides every four seconds, no pause button. A user with dyslexia, dyspraxia, ADHD or just learning Polish does not finish reading the slide before it changes.

Violated criterion 2.2.2 Pause, Stop, Hide, A.

Fix: add a visible pause/play button, accessible with the keyboard. Or better: drop the carousel. Erik Runyon's classic study (Notre Dame, 2013) on telemetry from a university carousel showed that the first slide gets about 90 percent of all carousel clicks, and slides 2 and beyond together get under 10 percent. Later replications (Notre Dame 2017, Nielsen Norman 2019) confirmed the pattern.

The cookie banner opens as a modal over the content. After Tab, focus loops over the banner buttons and refuses to "leave" until the user clicks. Or after closing, focus returns to the top of the page, not where the user was.

Violated criteria 2.1.2 No Keyboard Trap (A), 2.4.3 Focus Order (A) and often 2.4.11 Focus Not Obscured (AA, WCAG 2.2).

Fix: implement the banner as a real modal with proper focus trap (focus only inside the modal) and focus restoration on close. If you use an off-the-shelf GDPR/cookie plugin, check whether it is advertised as WCAG-compliant. Most free plugins are not.

The foundation records an eight-minute video with the president talking about the mission. Uploads to YouTube with default automatic captions. YouTube's automatic captions in Polish have (per our own comparative measurements on 50 hours of Polish recordings under studio vs outdoor conditions) a Word Error Rate of 12–18 percent for studio speech and 25–40 percent for outdoor speech with background noise. Roughly every fourth or fifth word is wrong. For a deaf person that is not accessibility, that is misleading translation.

Fix: order human captions. Plain transcription in Polish typically costs PLN 8–25 per minute from professional transcribers, full SDH (timing, speaker attribution, sound markers) PLN 30–80 per minute. Cost rises with PJM (Polish Sign Language) or English localization. Publish the transcript as text under the video. For key materials (mission, recruitment, instructions) add Polish Sign Language.

A footer with six colored circles: Facebook, X, LinkedIn, YouTube, Instagram, TikTok. Links without text, without aria-label, without title. A screen reader announces "link, link, link, link, link, link."

Violated criterion 4.1.2 Name, Role, Value, A.

Fix: every icon gets an aria-label, e.g. an anchor with aria-label="Facebook of foundation XYZ, opens in a new tab". If you use an icon library (Font Awesome, Material Icons), remember that just an <i class="fa-facebook"></i> is invisible to a screen reader.

Short answer: a full audit is dozens of hours of heuristic and screen reader work, but in 30 minutes you can run a pre-screening that gives you 60–70 percent of the picture. Four steps.

Open the site in Chrome, press F12, go to the Lighthouse tab, check only "Accessibility," click "Analyze page load." Lighthouse runs a subset of axe-core rules (about 50 audits) and gives a 0–100 score plus a list of issues. Lighthouse 100 does not mean "the site is accessible," it means "the site passed these specific tests." For completeness, install the axe DevTools extension (Chrome or Firefox), which runs the full set of about 96 axe-core rules. Read each error, click "inspect," look at the code.

What Lighthouse and axe detect well: missing alt on images, low contrast in simple cases, missing label on input, duplicate ids, missing lang attribute on html, broken heading structure.

What they don't detect: whether alt makes sense (only that it exists), whether focus order is logical, whether content is understandable, whether modal handles focus correctly, whether the form validates errors accessibly, whether the carousel has pause. According to Deque's own research, axe-core covers about 30 percent of WCAG success criteria (as rules), and in tests on real sites detects about 57 percent of actual violations. For criterion 1.4.3 Contrast it hits 83 percent of cases, for 1.1.1 Non-text Content (alt presence) closer to 100 percent. For criteria requiring semantic judgment (heading logic, label sensibility, focus order) automated tools are powerless.

Hide the mouse. Press Tab. You should see a clear focus indicator (outline, contrast, highlight) on the first interactive element. Tab again, again, again. Check:

If you get stuck, write it down. Those are criteria 2.1.1, 2.1.2, 2.4.3, 2.4.7 and 2.4.11.

NVDA is free, open-source, with Polish voices included in the installer (from NV Access or volunteer packages). According to the WebAIM Screen Reader Survey (#10, 2024) NVDA is today the most-used screen reader on Windows among users with visual impairments. JAWS (commercial, expensive) is in retreat against NVDA but still present in government offices and larger organizations with corporate licenses. On macOS use built-in VoiceOver (Cmd+F5).

Once enabled, close your eyes (seriously) and walk through the site:

Thirty minutes with NVDA on your own site will tell you more than any automated audit.

WebAIM Contrast Checker is a free online tool: paste the hex codes of text and background, get the ratio and the WCAG AA/AAA verdict. Stark is a plugin for Figma, Sketch and the browser, flagging contrast at design time. Colour Contrast Analyser (CCA) by TPGi picks colors from any point on screen with an eyedropper and is essential for testing contrast on photos or gradients.

For normal text the AA requirement is 4.5:1, for large text (18pt regular, 14pt bold) 3:1. For UI graphics (icons, component borders) 3:1, criterion 1.4.11 Non-text Contrast.

Short answer: an accessibility statement in the Polish legal sense is required only for public bodies under the Act of 4 April 2019 (in NGOs: those under Article 4(1) point 6, 7, 10 of the Public Benefit Act, or those carrying out public tasks under contract). For other foundations it is a voluntary accessibility declaration, but the grant requirement often de facto forces it.

Article 10 of the Act of 4 April 2019 says the statement is drawn up using the template from the annex to Commission Implementing Decision (EU) 2018/1523. Mandatory elements (section 1 of the annex to Decision 2018/1523 and Article 10(3)–(5) of the Act):

The statement must carry specific HTML identifiers (a11y-wstep, a11y-data-publikacja, a11y-osoba, a11y-email, a11y-procedura, etc.) per the "Technical conditions for publishing the accessibility statement" published by the Polish Ministry of Digital Affairs. Version 2.0 of the technical conditions has applied since 2025. The 2020 template will not pass automated monitoring because the Ministry scans statements by identifiers.

Update: by March 31 each year and immediately after a substantive change to the site.

Practically: contact details (email, phone, form) with a person or team responsible for accessibility. Response time 7 days, alternative access if full accessibility is impossible, link to the Ombudsman as the appellate instance after exhausting the internal procedure. For foundations that are not public bodies this is not a legal obligation, but it is good practice and a credibility signal.

For foundations on EU Funds grants, also remember the procedure for reporting non-compliance with the Charter of Fundamental Rights and the UN Convention on the Rights of Persons with Disabilities to the Programme Monitoring Committee, which is independent of the accessibility statement.

Short answer: Lighthouse 42, axe shows 60 issues, the client panics. Fix in three waves: low-hanging fruit (one week), medium distance (2–3 months), long-term strategy (refactor or migration).

These fixes need an editor and a junior frontend developer, no designer, no redesign:

In a week you should bring Lighthouse from 42 to 75–85.

This is where work touches architecture:

After this phase you should be at 90+ Lighthouse and have an honest "partially compliant" statement with a short list of known gaps.

The hardest decision, most often miscalled in both directions. Two heuristics:

Fix, if:

Rebuild from scratch, if:

A third path, often skipped: partial refactor. You keep the CMS, rewrite the frontend (theme, components) with a new WCAG-first design system. Works well on WordPress and other CMSes whose admin you don't want to deal with, but the frontend is the biggest problem.

The most common trap foundations fall into in grant panic. A salesperson calls and says: "You'll get WCAG for $49 a month, we install a widget in 5 minutes." The widget is a colorful "person-with-circle" icon in the corner, letting users change text size, contrast, fonts.

Four reasons it does not work:

The position of WebAIM, Deque, W3C and Lainey Feingold (the leading U.S. accessibility lawyer) is consistent: overlays are harmful and do not satisfy WCAG. Recommendation: do not install. If you already have one, uninstall and put those $600 a year into one day of a developer's WCAG work.

Anonymized for NDA reasons. The foundation operates in healthcare, so formally a public body under the Act of 4 April 2019. The site was built in 2020 on WordPress with a premium theme, Lighthouse 42, axe detected 87 issues, no accessibility statement. The KPO application was in the final review stage and the reviewer wrote explicitly "no WCAG AA compliance and no accessibility statement." Project budget in the high six figures.

First call: two weeks until the deadline, a full external audit not feasible in that time. Decision: prioritize critical issues plus an accessibility statement, honestly described as "partially compliant."

Week one: editor and frontend working in parallel. Alt for every image on the homepage and 30 most-visited subpages (GA4 analytics). Fixed contrast (15 color pairs to change in the design tokens). <label> on every form. aria-label on icons. Focus indicator restored. Skip-to-main added. Cookie banner rewritten.

Week two: captions for three key videos on the homepage (commissioned to a professional transcriber). PDFs of the two latest annual reports rewritten from Word into accessible PDFs. Accessibility statement drafted to the 2.0 template. Self-registration of a complaint about our own site (procedure test) and fixing the issues that uncovered.

Result after two weeks: Lighthouse 89, axe 12 issues (mostly known and addressed in the statement as "to be fixed by date X"), accessibility statement deployed with a footer link, working request-and-complaint procedure. The KPO application went through.

The point we want to underline: it was not about full compliance, it was about credibility. A grant reviewer does not expect 100/100 Lighthouse. They expect the organization to know its gaps, have a remediation plan, and take accessibility seriously. An honest "partially compliant" statement with a concrete list and dates defends better than "fully compliant" with a falsified status.

Three paths depending on where you are today. In all three we work in a WCAG-EM (W3C Evaluation Methodology) compliant format, the standard accepted by domestic and international grant reviewers. For partnerships with U.S. administration or large international corporations we also produce a VPAT 2.5 / ACR (Accessibility Conformance Report).

If you want to take a first look yourself. Use a 20-point checklist for foundation-site pre-screening. Includes a Lighthouse test, keyboard test, contrast test, and a check for the six most common errors. Time: 30–45 minutes, no HTML knowledge required. Write to us, we'll send the PDF checklist.

If you know there is a problem but not how big. Book a 30-minute consultation. We'll walk together through Lighthouse, axe and the top five pages from your analytics, size up the problem and tell you whether remediation is enough or you need a rebuild. Book a free consultation.

If you have a grant deadline or a partnership contract with a public body. Full audit with remediation plan, written WCAG-EM report (criteria list, errors located in code, priority, estimated fix time) plus accessibility statement. Standard delivery 10–14 working days. Request an audit quote.

Market price ranges (so you know what to expect before the call):

More on how we work with foundations and public benefit organizations on our services for nonprofits page. Other EU regulations (NIS2, AI Act, GDPR, MDR) covered in our regulations section.

In each of these three cases we encourage you to read one more thing before contacting us: the wording in the regulations of your specific grant or contract. Nine times out of ten the precise wording of the requirement ("compliance with WCAG 2.1 AA," "digital accessibility per Annex 2 to the Guidelines," "accessibility within the scope of the delegated task") drives the scope of work.