IONOS Website Builder Accessibility Checklist 2026 | WCAG & EAA
Last updated: 2026-06-16
IONOS is one of Europe's largest hosting companies, and its MyWebsite Now and MyWebsite Creator builders power a huge number of small-business sites across Germany, the rest of the EU, and beyond. That European footprint matters because IONOS sites are squarely in the path of the European Accessibility Act, which since June 2025 requires e-commerce and many consumer-facing services to meet accessibility standards effectively equivalent to WCAG 2.1 AA. A bakery, tradesperson, or boutique that built a quick site on IONOS to take bookings or sell online is exactly the kind of business the EAA is reshaping, and most of them have never run an accessibility check.
IONOS offers two builder experiences: MyWebsite Now, an AI-assisted quick builder that generates a templated site from a few questions, and MyWebsite Creator (built on a Jimdo-derived engine), a more flexible drag-and-drop editor. Both generate the underlying HTML for you, so accessibility is governed by the template you start from and the content discipline you apply inside the editor. The recurring failure modes are familiar: template color schemes that fail contrast on buttons and link text, contact and booking forms whose fields lack programmatic labels, image blocks published without alt text, and heading styles chosen for size rather than structure. This checklist covers the issues we see most on IONOS sites, maps each to its WCAG 2.1 AA success criterion, and gives a fix you can apply inside the IONOS editor. Because so many IONOS users are EU-based, we flag where an issue is most likely to matter under EAA enforcement. It is ordered by impact, starting with the form and contrast issues that are both the most common and the most likely to surface in an enforcement complaint.
Common Accessibility Issues
The IONOS form element lets you add fields quickly but often renders them with placeholder text as the only visible identification, and without a programmatic label associated to the input. Screen reader users hear an unlabeled edit field, and once they begin typing the placeholder disappears for sighted users too. Booking and quote-request forms are the most common conversion path on IONOS small-business sites, so this failure directly blocks revenue.
In the IONOS form settings, give every field a visible label rather than relying on placeholder text. Confirm required fields are marked with more than color (add the word 'required' or an asterisk with text). After publishing, inspect the rendered field to confirm the label is associated with the input via for/id or wrapping. Where the native element falls short, use a custom HTML block to add a properly labeled form.
<input type="text" name="name" placeholder="Your name"><label for="contact-name">Your name</label>
<input type="text" id="contact-name" name="name" autocomplete="name">IONOS templates ship with coordinated palettes that look polished but frequently place light text on light accent buttons, or use a muted gray for body and link text that falls below the 4.5:1 minimum. The AI-generated MyWebsite Now sites are particularly prone to this because the palette is chosen for aesthetics, not contrast.
Open the design or style settings and check button text, link text, and body text against their backgrounds with a contrast checker. Adjust the theme colors until normal text reaches 4.5:1 and large text 3:1. Pay special attention to call-to-action buttons and to any text placed over a hero photograph, where you should add a solid or semi-opaque overlay behind the text rather than trusting the image.
In both IONOS builders, text elements expose heading styles, but users tend to pick the size that looks right rather than the correct level. The result is pages with several H1s, jumps from H1 to H3, or section titles left as styled body text, which gives screen reader users a broken document outline and no reliable way to navigate by heading.
Assign one H1 per page (the main page title), then use H2 for each major section and H3 for sub-points, setting the level explicitly in the text element's heading dropdown. If you want a heading to appear smaller, change its font size in styling while keeping the correct semantic level rather than dropping to a lower heading tag.
IONOS image elements do not require alt text, so galleries, hero images, product photos, and logos are routinely published with no text alternative. For an e-commerce IONOS site, missing alt text on product images is both an accessibility failure and a lost opportunity for screen reader shoppers to know what they are buying.
Select each image element and fill in the alternative text field describing the image's content and purpose. Transcribe any text contained in an image (promotional banners, price graphics). Mark purely decorative images with empty alt text so screen readers skip them. For galleries, ensure each item has its own meaningful description.
IONOS templates generate a header navigation that is keyboard-reachable but typically without a skip-to-content link, forcing keyboard and screen reader users to tab through the full menu on every page before reaching the main content. Mobile hamburger menus in some templates also lack a clear expanded/collapsed state announcement.
Where the template allows, add a skip-to-content link as the first focusable element, or add one through a custom HTML/code block that targets the main content region's id. Verify the hamburger toggle communicates its state (aria-expanded) and that the menu can be opened and closed with the keyboard. Confirm the current page is indicated with more than color in the navigation.
EU IONOS sites almost always carry a cookie consent banner, and some banner implementations overlay the page in a way that keyboard focus cannot escape, or place the accept/reject controls in an order that is hard to reach by keyboard. A banner that traps focus or cannot be operated by keyboard blocks the entire site for affected users.
Choose a consent solution that documents keyboard and screen reader support, and test the banner with the keyboard: you must be able to reach and activate both accept and reject controls, and focus must not be trapped. Ensure the banner's text and buttons meet contrast requirements, since consent UIs are frequently low-contrast gray-on-gray.
IONOS Website Builder (MyWebsite)-Specific Tips
- Because most IONOS sites serve EU customers, treat WCAG 2.1 AA as the working target for European Accessibility Act compliance, especially on any page that takes bookings or payments.
- Give every contact and booking form field a visible label in the form settings; placeholder text alone fails both screen readers and sighted users who tab back to check.
- Run the template's button, link, and body colors through a contrast checker before publishing - IONOS and AI-generated palettes fail 4.5:1 frequently.
- Set heading levels explicitly per text element (one H1 per page, H2 for sections) rather than choosing by font size.
- Add alt text to every image element and transcribe text inside promotional or price graphics.
- Test the cookie consent banner with the keyboard - both accept and reject controls must be reachable and focus must not be trapped.
Recommended Tools
WAVE Browser Extension
Run it on each published IONOS page to catch missing form labels, empty alt text, contrast failures, and heading-structure problems in one pass.
WebAIM Contrast Checker
Verify IONOS template button, link, and body colors against the 4.5:1 and 3:1 minimums; coordinated palettes look fine but often fail.
axe DevTools
Automated WCAG scanning that is strong at flagging unlabeled inputs and missing accessible names on IONOS forms and navigation.
Keyboard-only testing (Tab, Enter, Escape)
Walk the whole site - menu, forms, cookie banner, booking flow - with only the keyboard; if you cannot complete a booking, neither can a keyboard-dependent customer.
NVDA + Firefox / VoiceOver + Safari
Screen-reader testing reveals whether form fields announce a name, whether headings form a sensible outline, and what your images convey.
IONOS Website Builder Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Forms contact/booking | Placeholder-only fields | 3.3.2 | Visible label associated to each input | |
| Colors template palettes | Light text on light accent | 1.4.3 | Adjust theme to 4.5:1 / 3:1 | |
| Headings text elements | Size chosen, not level | 1.3.1 | One H1, explicit H2/H3 per element | |
| Images galleries/products | No alt text | 1.1.1 | Describe purpose, transcribe text | |
| Cookie banner EU consent | Focus trap, low contrast | 2.1.2 | Keyboard-operable, passing contrast |
Frequently Asked Questions
Does the European Accessibility Act apply to my IONOS website?
Very possibly, yes. The European Accessibility Act, which applies from June 2025, covers a broad set of consumer-facing products and services, with e-commerce singled out explicitly - so an IONOS site that sells goods, takes bookings, or offers a consumer service to people in the EU is likely in scope. The main relief is for microenterprises (broadly, fewer than 10 staff and under 2 million euro turnover) providing services, but even there, national transposition varies and B2C customer expectations push toward compliance regardless. Because IONOS is a European host with a heavily EU customer base, EAA is the most relevant framework for most IONOS site owners, and WCAG 2.1 AA is the practical technical target it points to. The safe approach is to bring your forms, contrast, headings, and images up to WCAG 2.1 AA rather than betting on an exemption. This is general guidance, not legal advice; consult a qualified attorney about your specific situation.
What's the difference between MyWebsite Now and Creator for accessibility?
MyWebsite Now is the AI-assisted quick builder that generates a templated site from a short questionnaire, while MyWebsite Creator (built on a Jimdo-derived engine) gives you a more hands-on drag-and-drop editor. From an accessibility standpoint the failure modes overlap heavily, but the AI-generated Now sites tend to ship more contrast problems because the palette is chosen for visual appeal without checking ratios, and they give you less granular control to fix individual elements. Creator gives you more access to per-element styling, heading levels, and in some cases custom HTML, which makes it easier to correct labels, contrast, and skip links. Whichever you use, the core checklist is the same: visible form labels, passing contrast, deliberate heading levels, alt text on images, and a keyboard-testable cookie banner and navigation.
Can I add a skip-to-content link or fix form labels on IONOS without coding?
It depends on which builder and plan you use. Visible form labels, contrast adjustments, heading levels, and alt text are all configuration choices you can make in the IONOS editor without any code. A skip-to-content link is harder: if your template does not provide one, you generally need a custom HTML or code element (available on some plans) to insert an anchor link at the top of the page that targets the main content region. The same goes for fully fixing a form whose native markup omits label associations - a custom HTML block lets you build a properly labeled form. The pragmatic path is to make every no-code fix first, run WAVE and a keyboard pass on the published site, and only reach for a code block where the scan still shows failures you cannot resolve through settings.
Further Reading
Other CMS Checklists
- Hostinger-website-builder Accessibility Checklist
- Godaddy-website-builder Accessibility Checklist
- Webnode Accessibility Checklist
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.