Webnode Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-06-02
Webnode is a template-driven website builder popular with small businesses and individuals across Europe, and it markets itself heavily on multi-language sites and speed of setup - both of which shape its accessibility profile. The builder works by assembling pages from pre-designed sections (hero, about, services, gallery, contact) that the owner edits in place, so the underlying markup quality is mostly inherited from the template rather than written by the user. That is a double-edged thing: a well-chosen template gives you semantic sections and real buttons, while the editor still lets you break the heading hierarchy by styling text, upload images without alt text, and pick brand colours that fail contrast. The features that most often cause real audit findings are specific to Webnode. Its headline use case, multi-language sites, requires that the lang attribute changes correctly per language and that the language switcher is a properly-labelled, keyboard-operable control - failures here make a screen reader pronounce a whole page in the wrong language. The contact and signup form widgets are central to most Webnode sites and frequently render fields with placeholder-only prompts and no programmatic labels. Image galleries open a lightbox that may not manage focus. And the online store add-on brings product listings, an add-to-cart control, and a checkout that need the same labelling and status-message care as any e-commerce platform. Because Webnode targets non-technical owners, the practical challenge is that most fixes have to be achievable inside the editor - choosing the right section, filling the alt-text field, setting heading levels, picking accessible colours - rather than editing code, and this checklist is written with that constraint in mind. Webnode provides no built-in accessibility checker, so verify changes with a free browser scanner (axe or WAVE) and a keyboard and screen reader pass on the published site.
Common Accessibility Issues
Webnode's editor lets you change the size and weight of text to make it look like a heading, and section templates sometimes use multiple large 'titles' that are not real headings or that skip levels. Screen reader users navigating by headings get no usable page outline, and the page's structure is invisible to assistive technology.
Use the text editor's paragraph/heading style menu (Heading 1, Heading 2, Heading 3) to set true heading levels rather than only enlarging text. Keep one Heading 1 (usually the page or hero title), use Heading 2 for main sections and Heading 3 for sub-sections, and do not skip levels. Check the result with a free headings tool on the live page.
<p class="text-block" style="font-size:40px;font-weight:bold">
Our Services
</p><h2 style="font-size:40px;font-weight:bold">Our Services</h2>Webnode lets owners drop images into sections and galleries quickly, and the alt-text field is optional and easy to skip. Hero images, product photos, and gallery items then reach screen reader users as nothing, or as a filename, leaving them without information that sighted visitors get instantly.
Open each image's settings in the editor and fill the alt text / description field with a short, specific description of what the image shows and why it is there. For purely decorative images (background textures, dividers), leave the alt empty so screen readers skip them. Do not paste the same alt onto every gallery image - describe each one.
<img src="hero.jpg" alt=""> <!-- informative image, empty alt --><img src="hero.jpg"
alt="Baker placing fresh loaves into a shop window display">Multi-language sites are Webnode's signature feature, but two failures are common: the html lang attribute does not change to match the language version a visitor is viewing, and the language switcher is an icon or flag with no text accessible name. A wrong lang makes a screen reader read, say, German content with English pronunciation rules, and an unlabeled switcher is unusable by keyboard and screen reader.
Ensure each language version sets the correct html lang value (lang="de", lang="fr", etc.) so assistive tech pronounces content correctly. Make the language switcher a real link or button list with text names ('Deutsch', 'English') - not flags alone, since flags do not map cleanly to languages - and confirm it is keyboard operable with a visible focus state.
<html lang="en"> <!-- on the German page -->
<a href="/de/"><img src="flag-de.png" alt=""></a><html lang="de">
<nav aria-label="Language">
<a href="/de/" lang="de" aria-current="true">Deutsch</a>
<a href="/en/" lang="en">English</a>
</nav>Webnode's form widget often shows field prompts as placeholder text ('Name', 'Email', 'Message') with no persistent, programmatically associated label. The placeholder disappears on input, so screen reader users may hear 'edit text' with no name, and people with cognitive or memory disabilities lose track of what each field needs - a serious barrier on the contact form most Webnode sites depend on.
In the form widget settings, enable visible labels for each field rather than relying on placeholders, so every input has an associated label in the rendered page. Where the widget only offers placeholders, add a clear visible text label above each field and ensure required fields and error messages are conveyed as text, not colour alone.
<input type="text" name="name" placeholder="Your name">
<input type="email" name="email" placeholder="Your email"><label for="cf-name">Your name</label>
<input type="text" id="cf-name" name="name" autocomplete="name">
<label for="cf-email">Your email</label>
<input type="email" id="cf-email" name="email" autocomplete="email">Webnode templates ship with default palettes, and owners customise button, link, and text colours to match a brand. Light-on-light combinations - pale buttons with white text, light-grey body text, low-contrast link colours - frequently fail the 4.5:1 ratio, making key content and calls to action hard to read for low-vision visitors.
Check each colour pair (button text on button background, body text on its background, link colour on its background) with a free contrast checker. Body and small text need at least 4.5:1, large text 3:1. Adjust the template's colour settings until each pair passes, and make sure links are distinguishable from body text by more than colour alone.
.btn { background:#bcd6ff; color:#ffffff; } /* ~1.8:1 */
body { color:#9b9b9b; } /* ~2.8:1 on white */.btn { background:#1a5fb4; color:#ffffff; } /* >=4.5:1 */
body { color:#333333; } /* >=12:1 on white */Webnode gallery sections open clicked images in a lightbox overlay with next/previous arrows. In many templates the overlay does not move focus into itself, cannot be closed with Escape, traps or strands keyboard focus, and uses icon-only arrows with no accessible name - so keyboard and screen reader users cannot browse or exit the gallery.
Prefer a gallery/template whose lightbox manages focus, or where you can, link images to their full versions instead of a scripted overlay. If you keep the lightbox, ensure it moves focus in on open, traps Tab while open, closes on Escape and via a labelled close button, returns focus on close, and gives its arrows text names ('Previous image', 'Next image').
<a class="gallery-item" onclick="openLightbox(3)">
<img src="g3.jpg" alt="">
</a>
<button class="lb-next"><i class="icon-next"></i></button><a class="gallery-item" href="g3-full.jpg">
<img src="g3.jpg" alt="Wedding venue garden at sunset">
</a>
<button class="lb-next" aria-label="Next image">
<i class="icon-next" aria-hidden="true"></i>
</button>Webnode's online store add-on lists products and provides an add-to-cart control and a checkout. As with most builders, the add-to-cart confirmation and cart-count update are often visual-only, and product option controls and quantity steppers may be icon buttons with no accessible name, so screen reader shoppers cannot tell what they are doing or whether it worked.
Make sure each add-to-cart and quantity control has a text accessible name, and route the 'added to cart' confirmation through an aria-live region so it is announced. Give product option selectors real labels, and run the full store flow - product, cart, checkout - with the keyboard and a screen reader before you start selling.
<div class="add-cart" onclick="add(7)"></div>
<span class="cart-count">1</span> <!-- updates silently --><button type="button" class="add-cart" onclick="add(7)">
Add to cart<span class="sr-only"> - Handmade Soap</span>
</button>
<div role="status" aria-live="polite">Added Handmade Soap to cart</div>Webnode pages stack many sections, and templates often omit a skip-to-content link, forcing keyboard users to tab through the full header and menu on every page. Some templates also place sticky headers or pop-ups that take focus first, so the tab order does not follow the visible reading order.
Add a skip-to-content link as the first focusable element if your template supports custom HTML, or choose a template that includes one, so keyboard users can bypass repeated navigation. Tab through each page after publishing to confirm focus follows the visual order and that any pop-up or cookie banner does not strand focus.
<body>
<header>...long menu...</header>
<main>...</main>
</body><body>
<a class="skip-link" href="#main">Skip to content</a>
<header>...long menu...</header>
<main id="main">...</main>
</body>Webnode-Specific Tips
- Choose your section template with accessibility in mind from the start: because Webnode inherits markup from the template, a section set with real headings, labelled forms, and a focus-managed gallery saves you fixes you cannot make without code later.
- For multi-language sites - Webnode's core feature - verify that each language version sets the correct html lang value and that the language switcher uses text names ('Deutsch', 'English'), not flags alone. A wrong lang attribute breaks screen reader pronunciation for the whole page.
- Fill the alt-text field for every meaningful image in the editor and leave it empty for purely decorative ones; describe each gallery image individually rather than reusing one description.
- Turn on visible labels in the contact/form widget instead of relying on placeholder prompts, and test the form by tabbing through it and listening with a screen reader - the contact form is the conversion point on most Webnode sites.
- Check your customised button, link, and text colours with a free contrast checker before publishing; Webnode's easy colour customisation is the most common source of low-contrast calls to action.
Recommended Tools
WAVE Web Accessibility Evaluation Tool
A free WebAIM tool that visually marks missing alt text, unlabeled form fields, heading-structure problems, and contrast failures directly on your published Webnode page - approachable for non-technical owners who cannot read code.
WebAIM Contrast Checker
A free tool for checking whether your Webnode button, link, and text colours meet WCAG contrast ratios. Paste the foreground and background hex values to confirm at least 4.5:1 for normal text before you publish brand colours.
axe DevTools (browser extension)
A free browser extension that scans a rendered Webnode page for WCAG issues including missing labels, ARIA problems, and language-attribute errors. Useful for verifying multi-language pages set the correct lang and that form fields are labelled.
Where Webnode Accessibility Issues Concentrate
| Plugin / Tool | Area | Builder Risk | What To Check |
|---|---|---|---|
| Headings section text | Styled text vs real headings | Medium - easy to fake a heading with font size | Use Heading 1/2/3 styles, one H1, no skipped levels |
| Multi-language lang + switcher | Per-language pages | High - wrong html lang, flag-only switcher | Correct lang per version, text-named keyboard switcher |
| Forms contact / signup | Form widget fields | High - placeholder-only prompts | Visible labels, text errors, autocomplete attributes |
| Gallery lightbox | Image overlay | Medium - no focus management, icon-only arrows | Focus trap + Escape + return, named prev/next controls |
| Colours brand palette | Customised buttons/text | Medium - light-on-light fails contrast | 4.5:1 normal text, links distinct beyond colour |
Frequently Asked Questions
Is Webnode accessible out of the box?
It depends heavily on the template, because Webnode assembles pages from pre-designed sections and inherits most of its markup from them. A good template gives you semantic sections and real buttons, but the editor still lets you break the heading hierarchy by styling text, upload images with no alt, choose low-contrast brand colours, and use form widgets with placeholder-only fields. No Webnode site is automatically WCAG 2.1 AA compliant; you reach compliance by choosing a solid template and using the editor's accessibility-relevant settings correctly.
Does a Webnode site need to comply with the European Accessibility Act?
Many do. The European Accessibility Act (EAA) has applied since 28 June 2025 and covers consumer-facing services including e-commerce, referencing EN 301 549, which requires WCAG 2.1 Level AA. If your Webnode site sells products or services to EU consumers (including via the online store add-on), it likely falls in scope. Even where the EAA does not strictly apply, WCAG 2.1 AA is the practical standard to aim for. This is general information, not legal advice.
How do I fix headings on a Webnode page?
Use the text editor's style menu to assign real heading levels (Heading 1, Heading 2, Heading 3) instead of only enlarging the font. Each page should have one Heading 1 - usually the page or hero title - with Heading 2 for main sections and Heading 3 for sub-sections beneath them, and you should not skip levels (for example H2 straight to H4). After publishing, check the outline with a free headings tool or the WAVE extension.
My Webnode site is multilingual - what accessibility issues should I watch for?
Two in particular. First, confirm each language version sets the correct html lang attribute (lang="de", lang="fr", and so on) so a screen reader pronounces the content with the right language rules - a page left as lang="en" will be mispronounced. Second, make the language switcher a keyboard-operable list of links or buttons with text names like 'Deutsch' and 'English' rather than flags alone, since flags do not reliably map to languages and icons need an accessible name.
Are Webnode contact forms accessible?
Not automatically. The form widget often uses placeholder text as the only field prompt, which disappears on input and is not a real label, leaving screen reader users with unnamed 'edit text' fields. Turn on visible labels in the widget settings so each input has an associated label, convey required fields and error messages as text rather than colour alone, and test the form by tabbing through it and listening with a screen reader before relying on it.
Can I make a Webnode online store accessible?
Yes, with attention to the same areas as any e-commerce platform. Make sure product option selectors and add-to-cart and quantity controls have text accessible names, route the 'added to cart' confirmation through an aria-live region so it is announced, and give product images meaningful alt text. Then run the full flow - product page, cart, checkout - with the keyboard only and a screen reader, since that is the journey that determines whether a disabled customer can actually buy from you.
Further Reading
- How To Choose Accessible Website Template
- Accessible Forms Guide
- Color Contrast Guide
- Alt Text Guide
- Five Minute Accessibility Audit
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.