Zoho Sites Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-06-16
Zoho Sites is the website builder inside the broader Zoho business suite, and it tends to be chosen by companies already using Zoho CRM, Zoho Forms, or Zoho Bookings who want a marketing site that plugs into those tools. That integration is its strength and its accessibility weak point at once: a typical Zoho Sites page is a drag-and-drop layout with one or more embedded Zoho widgets (a contact form, a booking calendar, a CRM web form) stitched in, and each of those embeds brings its own markup that you do not fully control from the page editor. Accessibility on a Zoho Sites site therefore has two layers: the content you build in the editor, and the widgets you embed from elsewhere in the suite.
In the page editor itself, the recurring issues mirror other drag-and-drop builders: heading elements picked for size instead of structure, template color schemes that fail contrast on buttons and links, images dropped in without alt text, and navigation that lacks a skip link. The embedded-widget layer adds its own problems, most often Zoho Forms and Zoho Bookings widgets whose fields rely on placeholder text or whose date pickers and calendars are difficult to operate by keyboard. This checklist covers both layers, maps each issue to its WCAG 2.1 AA success criterion, and gives a fix you can apply either in the Zoho Sites editor or in the source widget's settings. It is ordered by impact, with form and contrast issues first, because those are the elements most likely to block a real customer and most likely to appear in an accessibility complaint. Where a fix lives in a different Zoho product rather than Zoho Sites, we say so.
Common Accessibility Issues
Zoho Sites pages commonly embed a Zoho Forms contact form or a Zoho Bookings calendar. These widgets frequently render fields with placeholder-only identification and date pickers that are difficult to label, so screen reader users encounter unlabeled edit fields and a booking calendar that does not announce the selected date. Because booking and contact are the primary conversion paths, this directly blocks customers.
Fix the form at its source: in Zoho Forms, turn on visible field labels rather than placeholder-only display, mark required fields with text, and check the embedded result. For Zoho Bookings, test the date and time selection with the keyboard and a screen reader; if the native calendar cannot be operated by keyboard, provide an alternative contact method (a phone number or labeled fallback form) so the booking task is completable.
<input type="text" name="Name" placeholder="Name"><label for="zf-name">Name</label>
<input type="text" id="zf-name" name="Name" autocomplete="name">Zoho Sites text elements let you apply heading styles by visual size, so pages end up with multiple H1s, skipped levels, or section titles left as styled body text. Screen reader users who navigate by heading get an unreliable outline and cannot jump efficiently between sections.
Use exactly one H1 per page (the main page heading), then H2 for each major section and H3 for sub-points. In the text element settings, set the heading level explicitly rather than just enlarging the font. If you want a smaller-looking heading, reduce its font size in styling while keeping the correct semantic level.
Zoho Sites themes include coordinated color schemes where button text, link colors, and lighter body text frequently fall below the 4.5:1 minimum for normal text. Text placed over hero images is especially likely to fail because the background varies across the photo.
Check button text, link colors, and body text against their backgrounds with a contrast checker, and adjust the theme colors until normal text reaches 4.5:1 and large text 3:1. For text over images, add a solid or semi-opaque overlay behind the text rather than relying on the photo. Verify hover and visited link states if you customize them.
The Zoho Sites image element does not require alt text, so hero images, team photos, product shots, and promotional banners are often published with no text alternative. Banners that contain text (sale announcements, value propositions) are especially harmful when that text is not transcribed.
Select each image element and add alternative text describing its content and purpose, transcribing any text baked into the image. Set purely decorative images to empty alt text so screen readers skip them. For image-heavy galleries, give each item a meaningful description rather than a filename.
Zoho Sites templates generate header navigation that is keyboard-reachable but usually omits a skip-to-content link, so keyboard and screen reader users tab through the entire menu on every page before reaching the content. The mobile hamburger toggle in some themes does not clearly communicate whether the menu is expanded or collapsed.
Where the editor or a custom code element allows, add a skip-to-content link as the first focusable element targeting the main content region. Confirm the hamburger toggle exposes its expanded/collapsed state (aria-expanded) and can be operated by keyboard. Indicate the current page in the navigation with more than color alone.
Zoho Sites lets you drop in custom HTML and third-party embeds (maps, chat widgets, social feeds). These are a frequent source of unnamed buttons, iframes without titles, and interactive controls with no accessible name, since the embedded code is outside the builder's styling and is rarely tested.
Give every iframe a descriptive title attribute, ensure embedded interactive controls have accessible names (aria-label or visible text), and test any third-party widget with a screen reader and keyboard before publishing. If a chat or map widget cannot be made operable, provide an accessible alternative such as a labeled phone number, address text, or a standard contact form.
Zoho Sites-Specific Tips
- Remember a Zoho Sites page has two accessibility layers: the content you build in the editor and the Zoho widgets you embed - fix embedded Zoho Forms and Bookings issues in their source product, not just on the page.
- Turn on visible field labels in Zoho Forms rather than placeholder-only display, and test Zoho Bookings calendars with the keyboard before relying on them as your only booking path.
- Set heading levels explicitly per text element (one H1 per page, H2 for sections) instead of choosing by font size.
- Run theme button, link, and body colors through a contrast checker; coordinated Zoho themes often miss 4.5:1.
- Add alt text to every image and transcribe text inside promotional banners.
- Give every custom HTML iframe a title attribute and confirm embedded chat, map, and social widgets have accessible names and keyboard support.
Recommended Tools
WAVE Browser Extension
Run it on each published Zoho Sites page to catch missing form labels, untitled iframes, empty alt text, and contrast failures in one pass.
WebAIM Contrast Checker
Verify Zoho theme button, link, and body colors against the 4.5:1 and 3:1 minimums before publishing.
axe DevTools
Automated WCAG scanning that reliably flags unlabeled inputs, missing iframe titles, and controls without an accessible name on embedded widgets.
Keyboard-only testing (Tab, Enter, Escape)
Walk the whole site - menu, embedded form, booking calendar, chat widget - 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 embedded form fields announce a name, whether the booking calendar is usable, and what your images convey.
Zoho Sites Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Embedded forms Zoho Forms/Bookings | Placeholder fields, hard calendar | 3.3.2 | Labels at source; keyboard-test booking | |
| Headings text elements | Size chosen, not level | 1.3.1 | One H1, explicit H2/H3 per element | |
| Colors theme schemes | Button/link below 4.5:1 | 1.4.3 | Adjust theme to 4.5:1 / 3:1 | |
| Images banners/photos | No alt text | 1.1.1 | Describe purpose, transcribe text | |
| Custom embeds maps/chat/HTML | Untitled iframe, unnamed controls | 4.1.2 | Title iframes, name controls, test |
Frequently Asked Questions
Who is responsible for accessibility when I embed a Zoho Forms or Bookings widget?
From a legal and practical standpoint, you are, because the embedded widget renders on your website and is part of the experience your visitors have. Accessibility law looks at whether a user can complete a task on your site, not at which Zoho product generated a particular form or calendar. If a screen reader user cannot fill in your embedded Zoho contact form, or a keyboard user cannot pick a slot in your Zoho Bookings calendar, that is a barrier on your site. The good news is that because these are Zoho products you control, you can often fix them at the source: enable visible labels in Zoho Forms, mark required fields with text, and test the Bookings calendar with the keyboard. Where a widget cannot be made fully operable, provide an accessible fallback such as a labeled standard form or a phone number so the task remains completable. This is general guidance, not legal advice; consult a qualified attorney about your specific situation.
Can I add a skip-to-content link and fix labels on Zoho Sites without code?
Some fixes are pure configuration and some need a code element. Heading levels, contrast adjustments, alt text, and turning on visible labels in Zoho Forms are all no-code changes you make in the relevant editor. A skip-to-content link usually needs a custom HTML element that inserts an anchor targeting your main content region, since Zoho Sites templates rarely include one by default. Likewise, adding a title to a custom iframe or giving an embedded control an accessible name is done in the custom HTML block. The efficient approach is to apply every no-code fix first - labels, contrast, headings, alt text - then run WAVE and a keyboard pass on the published site, and only use a custom HTML element where the scan still shows failures you cannot reach through settings.
Does WCAG and the EAA apply to a Zoho Sites business site?
Yes, in the same way they apply to any business website. In the US, ADA Title III demand letters and lawsuits regularly target the exact elements Zoho Sites businesses rely on: unlabeled forms, low-contrast buttons, inaccessible booking calendars, and untitled embeds. In the EU, the European Accessibility Act, in force from June 2025, brings e-commerce and many consumer services within scope, so a Zoho Sites site selling goods or taking bookings from EU consumers is very likely covered, with a limited microenterprise carve-out for service providers. WCAG 2.1 AA is the practical technical target under both frameworks. Because Zoho Sites pages combine builder content with embedded widgets, the safe path is to bring both layers up to WCAG 2.1 AA rather than assuming the embedded Zoho components are accessible out of the box. This is general guidance, not legal advice; consult a qualified attorney about your specific situation.
Further Reading
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.