Hostinger Website Builder Accessibility Checklist 2026 | WCAG & EAA
Last updated: 2026-05-26
Hostinger Website Builder is the AI-first drag-and-drop builder that grew out of Zyro and is now bundled with Hostinger's hosting plans. Its pitch is speed: describe your business, let the AI generate a multi-page site with copy and images, then rearrange everything by dragging elements around a grid. That convenience is exactly what makes accessibility tricky, because the two things the builder does best - generating content automatically and letting you place elements anywhere visually - are also the two things most likely to produce barriers if you do not check them. AI-generated copy and images tend to ship with generic or missing alt text and with headings chosen for visual impact rather than a logical outline, so the page can look polished while reading as a jumble to a screen reader. The drag-and-drop grid positions elements visually, but the order a screen reader and keyboard follow is the underlying source order, which can diverge from what you see on screen once you start moving blocks - so a layout that reads top-to-bottom by eye can jump around for someone tabbing through it. Templates set your colour palette and typographic scale up front, and not every preset meets the 4.5:1 contrast ratio for normal text, especially light text on pastel hero sections. On top of that, the builder is deliberately low-code: you get limited or no access to the underlying HTML on most plans, so the usual developer fixes (adding ARIA, correcting a heading level in markup, hand-tuning focus order) are often not available, and you have to work within the controls the editor exposes. This checklist focuses on the choices you actually control in Hostinger Website Builder so a small-business site built on it can move toward WCAG 2.1 AA, EN 301 549, and EAA expectations.
Common Accessibility Issues
When the AI builder generates a site, the images it places - and any you add from the stock library or AI image generator - typically arrive with empty or auto-filled alt text that does not describe what the image communicates. Decorative AI backgrounds are sometimes treated as content, and informative images (product shots, team photos, infographics) reach screen reader users as nothing or as a filename.
Open each image's settings in the editor and write alt text that conveys what the image means in context, not 'AI generated image'. Mark purely decorative images so they are hidden from assistive technology where the builder allows it. Treat the AI's output as a first draft: every image needs a human alt-text decision before the site goes live.
The grid editor positions elements where you drop them visually, but assistive technology follows the underlying source order, not the on-screen position. Once you start moving blocks around to fine-tune the look, the order a keyboard user tabs through and the order a screen reader reads can diverge from the visual layout, so content that looks sequential by eye becomes confusing or illogical when navigated linearly.
After arranging a page, Tab through it from the top and confirm focus moves in a sensible order that matches the visual flow; do the same with a screen reader. If the order is wrong, rebuild the section using the builder's column/section structure rather than free positioning, since structured sections keep visual and source order aligned far better than arbitrary placement. Keep layouts simple enough that reading order is predictable.
Headings in the builder are often styled by choosing a text size or a 'Heading/Subheading' preset, which means the visible heading level can be picked for impact rather than structure. Pages end up with multiple H1s (one per AI-generated section), skipped levels, or large text that is not a heading at all, breaking the outline screen reader users navigate by.
Use the heading controls to set one H1 per page (the main page title) and H2/H3 for sections and sub-sections in logical order, rather than choosing a size. Where the editor exposes a heading-level setting separate from font size, set the level for structure and the size for appearance. Review each page's heading sequence and fix any duplicate H1s or skipped levels the AI introduced.
Templates ship with a colour palette and typographic scale, and several presets place light text on pastel or image-backed hero sections, or use a muted grey for body text, that does not meet the 4.5:1 contrast ratio for normal text (3:1 for large text). Buttons and link states can fail too. The site looks on-brand but is hard to read for users with low vision.
Check text and interactive elements against their backgrounds with a contrast checker and adjust the builder's global colour palette so body text reaches at least 4.5:1 and large text 3:1. Pay special attention to text over hero images - add an overlay or solid panel behind the text. Because the palette is global, fixing it once in the site styles corrects contrast across the whole site.
Contact forms and e-commerce checkout fields in the builder frequently rely on placeholder text as the only label and show validation feedback in a way that is not tied to the field that failed. Placeholders disappear on focus and are not reliable labels, and unassociated errors are hard for screen reader and keyboard users to find and fix - a real problem on the checkout path where a lost sale is a direct cost.
Configure each form field with a visible, persistent label rather than relying on the placeholder, using whatever label or field-name option the builder provides. Keep instructions and required-field markers in text, not colour alone. Test the form and the store checkout end to end with the keyboard and a screen reader, and if a critical field cannot be labelled within the builder, consider an external accessible form embed.
Hostinger Website Builder is intentionally low-code, so on most plans you cannot edit the underlying HTML to add ARIA attributes, correct a heading level in markup, or hand-tune focus order. That means some accessibility issues can only be addressed through the controls the editor exposes, and a few may not be fixable on the platform at all - a real constraint to understand before you commit a compliance-sensitive site to it.
Solve as much as possible with the editor's own settings (heading levels, alt text, colour palette, structured sections) since those are the levers you have. Use any custom-code or embed feature your plan offers for specific accessible components (for example an embedded accessible form). Where the platform genuinely cannot meet a requirement, document the limitation, and for sites with strict legal exposure weigh a builder or CMS that gives you more control.
Hostinger Website Builder-Specific Tips
- Treat everything the AI generates as a first draft: it produces polished-looking pages, but images arrive without meaningful alt text and headings are sized for impact, so every AI page needs a human accessibility pass before launch.
- Prefer the builder's structured sections and columns over free drag-and-drop positioning - structured layouts keep the visual order and the keyboard/screen-reader reading order aligned, while arbitrary placement pulls them apart.
- Always Tab through a finished page from the top and confirm focus order matches the visual flow; the grid editor lets you place things anywhere, but assistive tech follows source order, not pixels.
- Fix colour contrast once in the global palette rather than per element - several templates ship light text on pastel or image backgrounds that fail 4.5:1, and a global change corrects the whole site.
- Set heading levels by structure (one H1, then H2/H3 in order) using the heading controls, separately from font size, and remove the duplicate H1s the AI tends to add to every section.
- Know the platform's limits before you commit: on most plans you cannot edit the HTML to add ARIA or fix focus order, so some issues can only be solved through editor settings - factor that into the decision for any compliance-sensitive site.
Recommended Tools
axe DevTools (browser extension)
Run Deque's free extension on your published Hostinger site to catch missing alt text, contrast failures, and structural issues you cannot see in the visual editor.
WebAIM Contrast Checker
Paste your template's text and background colours to confirm body text reaches 4.5:1 and large text 3:1 before you lock in the global palette.
WAVE Evaluation Tool
WAVE overlays alt-text, heading, and contrast problems directly on the rendered page, which is useful for reviewing AI-generated content that looks fine but reads poorly.
Hostinger Website Builder: Convenience vs Accessibility Risk
| Plugin / Tool | Feature | What It Does | Accessibility Risk to Manage |
|---|---|---|---|
| AI site generation 1.1.1 | Builds pages, copy, and images from a prompt | Missing alt text and illogical heading levels by default | |
| Drag-and-drop grid 1.3.2 | Place any element anywhere visually | Reading order can diverge from the visual layout | |
| Templates 1.4.3 | Preset palettes and type scales | Some presets fail 4.5:1 text contrast | |
| Forms & store 3.3.1 | Contact forms and checkout fields | Placeholder-only labels and unassociated errors | |
| Code access 4.1.2 | Low-code editor, limited HTML access | Some manual ARIA/focus fixes are not possible |
Frequently Asked Questions
Is a site built with Hostinger Website Builder accessible by default?
No. The AI builder produces a polished-looking site quickly, but it does not produce an accessible one by default. Generated images arrive without meaningful alt text, headings are sized for visual impact rather than set as a logical outline, some template palettes fail colour contrast, and drag-and-drop positioning can put the keyboard and screen reader reading order out of sync with what you see. The site can absolutely be made more accessible, but only by reviewing and correcting these things with the editor's controls after the AI has done its first pass - the default output is a starting point, not a compliant site.
Why does my drag-and-drop layout confuse screen readers?
Because screen readers and keyboards follow the underlying source order of the page, not the visual position where you dropped each element. The grid editor lets you place blocks anywhere, so once you start fine-tuning a layout, the order assistive technology reads can drift away from the order your eye follows. The fix is to build with the builder's structured sections and columns instead of free positioning, which keeps visual and source order aligned, and to always Tab through a finished page to confirm focus moves in a sensible, matching order.
Can I add ARIA or edit the HTML in Hostinger Website Builder?
Generally not on the standard plans. Hostinger Website Builder is deliberately low-code, so you usually cannot reach the underlying HTML to add ARIA attributes, change a heading level in markup, or hand-tune focus order - the way a developer would on WordPress or a hand-coded site. You work within the controls the editor exposes: heading-level settings, alt text fields, the global colour palette, and structured sections. Some plans offer a custom-code or embed block you can use for specific accessible components, but if a requirement simply cannot be met within the editor, that is a real platform limitation to weigh before committing a compliance-sensitive site.
Does Hostinger Website Builder meet the EAA and WCAG 2.1 AA?
The platform does not guarantee conformance, and its low-code nature means some fixes available on other platforms are not available here, so reaching full WCAG 2.1 AA / EN 301 549 conformance can be harder. That said, a small, well-checked site can get a long way: write real alt text, set a proper heading structure, fix the global palette for contrast, keep layouts structured so reading order holds, and label forms and checkout fields clearly. Audit the published site with axe or WAVE plus a manual keyboard and screen reader pass. If your business carries significant legal exposure under the EAA or ADA, weigh whether a platform with full code access would let you close the remaining gaps more reliably.
Further Reading
- How To Choose Accessible Website Template
- Wix Accessibility Seven Issues
- Ai Product Landing Pages Accessibility Scan
- Color Contrast Guide
- Alt Text Guide
- Accessible Forms Guide
Other CMS Checklists
- Wix Accessibility Checklist
- Weebly Accessibility Checklist
- Godaddy-website-builder Accessibility Checklist
- Jimdo 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.