Google Sites Accessibility Checklist 2026 | WCAG 2.1 AA & Section 508
Last updated: 2026-05-25
Google Sites is the free website builder bundled with Google Workspace, and it is everywhere it can be free: school class pages, university department sites, club and nonprofit pages, internal team hubs, and quick small-business landing pages. That audience is exactly the one most likely to be told it must be accessible - K-12 and higher education fall under Section 508 and ADA Title II, public-sector teams have the April 2026 and 2027 Title II deadlines, and EU organizations are now inside European Accessibility Act enforcement. The tradeoff Google Sites makes is simplicity over control: you cannot edit the raw HTML, install plugins, or add custom CSS, so you cannot code your way out of a problem the way you can on WordPress or a static framework. What you get instead is a small set of author decisions that almost entirely determine whether the site passes. The good news is that the modern Google Sites engine produces reasonably semantic markup, sets a skip link, and generally keeps keyboard focus working - so the failures are concentrated in content choices rather than broken widgets. The recurring problems are: theme and accent colors that fall below the minimum contrast ratio, images inserted without alt text, section titles and text boxes styled to look like headings without using the real Title/Heading/Subheading styles (or used out of order), embedded Google Docs, Slides, Forms, and Maps whose own accessibility the site inherits, generic 'click here' link text, and layout tables or data presented without proper structure. This checklist walks through each decision an author actually controls in the Google Sites editor and shows how to get it right before you publish.
Common Accessibility Issues
Google Sites ships built-in themes and lets you pick accent and text colors, and several of the default combinations - light gray body text, pale accent buttons, low-contrast text placed over background images in a banner section - fall below the 4.5:1 ratio for normal text and 3:1 for large text and UI components. Because you cannot override colors with custom CSS, an author who picks a low-contrast theme variant ships an inaccessible site with no code-level escape hatch.
Before committing to a theme, check the body text, link, and button color pairings with a contrast checker (WebAIM Contrast Checker). Choose the theme style/color variant whose text meets 4.5:1 against its background. For banner or section backgrounds that use an image, set a solid color block or the theme's built-in overlay behind text rather than placing text directly on a busy photo, and verify the actual rendered contrast, not the swatch.
Google Sites lets you add images, logos, and image carousels quickly, and the alt text field is optional and easy to skip. Informative images - screenshots, flyers, charts, images that contain text such as an event poster - then reach screen reader users as nothing, or as a filename. The carousel element compounds this because each slide is its own image needing its own description.
Select each image, open the three-dot menu (or right-click) and choose Add alt text, then write a description that conveys the image's purpose and any text it contains. For an event flyer, put the key details (event name, date, time, location) in the alt text or, better, in real text on the page next to the image. Mark purely decorative images as decorative so assistive technology skips them. Give every carousel slide its own meaningful alt text.
Spring Concert flyer image inserted with the alt text field left blank.Alt text: "Spring Concert, Friday June 12 at 7pm in the school auditorium, free admission." Key details also typed as real text beside the image.Authors frequently enlarge or bold text in a text box to make it look like a heading, or use the Title/Heading/Subheading styles in the wrong order (jumping from Title straight to Subheading, or using Heading repeatedly with no Title). Screen reader users navigate by real headings, so visually-styled text that is not a true heading is invisible to that navigation, and an out-of-order outline is confusing.
Use the built-in text styles from the toolbar - Title, Heading, Subheading, Normal text - rather than manually resizing Normal text. Use one Title as the page's main heading, then Heading for major sections and Subheading for subsections, in order, without skipping. Do not pick a style purely because of its size; pick it for its place in the document structure. Review the page by tabbing and with a screen reader's headings list before publishing.
A major Google Sites pattern is embedding Workspace content - a Doc, a Slides deck, a Sheet, or a Google Form - directly in the page. The site inherits the accessibility of that embedded artifact. A Doc with no real headings, a slide deck with unlabeled images, or a Form with questions that are not clearly labeled all become accessibility failures on the published site, often inside an iframe a screen reader user has to enter.
Fix accessibility in the source artifact first: give Docs real heading styles and alt text, give Slides reading-order and alt text, and build Forms with clear question text (Forms uses the question text as the label). Prefer embedding content you control and have remediated. Where the embed is essentially a document, consider linking to it with descriptive link text in addition to (or instead of) embedding, so users can open it in the native, more accessible viewer.
The Embed feature (embed by URL or by code) and embedded Google Maps render as iframes. When a screen reader user reaches an iframe with no accessible name, it is announced only as 'frame', giving no idea what it contains - a map, a video, a calendar, a booking widget. Several embeds on one page become a list of indistinguishable 'frame' stops.
When you embed by code, ensure the iframe has a meaningful title attribute (for example title="Map to the community center"). For embeds that do not let you set a title, add a real text heading or caption immediately before the embed describing what it is, so the surrounding context tells the user what the frame contains. Keep the number of separate embeds on a single page small.
<iframe src="https://www.google.com/maps/embed?..."></iframe><iframe src="https://www.google.com/maps/embed?..." title="Map showing the community center at 14 Oak Street"></iframe>Authors often link the words 'click here', 'read more', 'this link', or a raw pasted URL. Screen reader users frequently pull up a list of all links on a page to navigate; a list full of 'click here' or long unreadable URLs gives no information about where any link goes, and pasted URLs are read out character by character.
Write link text that describes the destination and makes sense out of context: 'Download the enrollment form (PDF)' instead of 'click here'. When you paste a URL, select the descriptive words you want and apply the link to them rather than displaying the bare URL. Avoid using the identical link text for links that go to different places.
Google Sites offers a table element. Two problems recur: using a table purely to position content side by side (a layout table), which adds meaningless table semantics for screen reader users; and presenting genuine tabular data without header cells, so a screen reader cannot associate a value with its column or row.
For side-by-side layout, use the built-in multi-column section layouts rather than a table. Reserve tables for genuine tabular data - schedules, price lists, comparisons - and make sure the top row (and where relevant the first column) functions as headers so each cell is announced with its column/row context. Keep tables simple; avoid merged cells where possible.
Google Sites-Specific Tips
- You cannot add custom CSS or edit HTML in Google Sites, so accessibility is decided almost entirely by author choices - theme/color selection, alt text, heading styles, link text, and what you embed. Get those right at authoring time because there is no code-level fix later.
- Pick the theme color variant that passes contrast before you build out pages; changing it after the fact reflows every section. Verify the rendered text contrast, not just the color swatch.
- Remediate embedded Google Docs, Slides, Sheets, and Forms in their source app first - the published site inherits whatever accessibility (or lack of it) those artifacts have.
- Use the toolbar text styles (Title, Heading, Subheading, Normal) for structure rather than manually enlarging text, and keep the levels in order with one Title per page.
- Give embeds and Maps a descriptive iframe title where you can, or a clear text caption immediately before the embed where you cannot, so they are not announced as a bare 'frame'.
- Preview the published site with the keyboard only and with a screen reader (VoiceOver on Mac/iOS, NVDA on Windows). Most remaining issues surface in the first few minutes of that pass.
- If the site is for a school, public body, or EU organization, pair it with an accessibility statement and keep evidence of what you checked; Google Sites' simplicity does not exempt the content from Section 508, ADA Title II, or the EAA.
Recommended Tools
WebAIM Contrast Checker
A free web tool to test foreground/background color pairs against the WCAG 4.5:1 and 3:1 thresholds before you commit to a Google Sites theme color variant.
axe DevTools
A free Chrome/Firefox/Edge extension that scans the published Google Sites page and flags missing alt text, contrast failures, missing iframe names, and structural issues with WCAG references.
WAVE Browser Extension
WebAIM's free extension annotates the live published page inline, showing alt text, heading structure, and contrast issues directly on top of the rendered Google Site.
Google Sites Accessibility: What You Control vs. What's Fixed
| Plugin / Tool | Area | Default Behavior | Your Responsibility |
|---|---|---|---|
| Markup & focus 1.3.1 / 2.4.7 | Reasonably semantic output, skip link, working keyboard focus | Don't break it - use real heading styles in order rather than resized text | |
| Color & contrast 1.4.3 | Some default theme variants fail contrast; no custom CSS to override | Pick a contrast-passing theme color variant before building | |
| Images 1.1.1 | Alt text field is optional and easy to skip | Add meaningful alt text to every informative image and each carousel slide | |
| Embeds (Docs, Forms, Maps) 1.3.1 / 4.1.2 | Site inherits the embed's accessibility; iframes may lack names | Remediate the source artifact; add iframe title or a text caption | |
| Links 2.4.4 | Lets you paste bare URLs or 'click here' | Write descriptive link text that makes sense out of context |
Frequently Asked Questions
Is Google Sites accessible by default?
The modern Google Sites engine starts you off better than most builders: it produces reasonably semantic markup, adds a skip link, keeps keyboard focus working, and the editor itself is usable with assistive technology. But 'better starting point' is not 'compliant site'. The accessibility of a published Google Site is decided almost entirely by author choices - whether you wrote alt text, picked a contrast-passing theme color, used real heading styles in order, and remediated whatever Docs or Forms you embedded. A site built carelessly on Google Sites will still fail WCAG 2.1 AA.
Can I add custom CSS or edit the HTML in Google Sites to fix accessibility issues?
No. Google Sites deliberately does not expose custom CSS, raw HTML editing, or a plugin system. That is the platform's main constraint for accessibility: you cannot code around a problem the way you can on WordPress or a static framework. The flip side is that there are fewer ways to break things and the fixes are all author-facing - choose accessible colors, add alt text, use heading styles correctly, write good link text, and remediate embeds. The 'Embed code' feature lets you add an HTML snippet (for example an iframe with a title attribute), but it does not let you restyle or restructure the rest of the page.
Does Google Sites meet Section 508 and ADA requirements for schools?
Google Sites can be used to build a site that meets Section 508 and WCAG 2.1 AA, but the platform does not guarantee it - the content you add determines the outcome. Schools, universities, and public bodies are covered by Section 508 and ADA Title II (with phased Title II deadlines in April 2026 and April 2027), so a class page or department site built on Google Sites is subject to the same expectations as any other. Use the checklist above, then verify with axe DevTools and a screen reader pass. This is general information, not legal advice - confirm your specific obligations with your institution's compliance office.
What about Google Forms, Docs, and Slides embedded in my site?
Your published site inherits their accessibility. An embedded Doc with no real headings, a Slides deck with unlabeled images, or a Form with vague question text all become barriers on the live site - often inside an iframe a screen reader user must enter. Fix the source artifact first: give Docs heading styles and alt text, give Slides a correct reading order and image descriptions, and write clear Form question text (Google Forms uses the question text as the field's label). For document-like content, also consider a descriptive link to open it in the native viewer.
How do I test my Google Site for accessibility?
Publish the site, then run a layered check on the live URL. Start with axe DevTools and WAVE in the browser to catch missing alt text, contrast failures, missing iframe titles, and structural problems automatically. Use the WebAIM Contrast Checker on any color pair you are unsure about. Then do a manual pass: navigate the whole page with the keyboard only, confirming focus stays visible and reaches everything, and listen to a screen reader pass with VoiceOver (Mac/iOS) or NVDA (Windows). Most issues automated tools miss show up within the first few minutes of screen reader use.
Further Reading
- Five Minute Accessibility Audit
- How To Choose Accessible Website Template
- Test Website Voiceover No Coding
- Color Contrast Guide
- Accessible Documents Word Google Docs
- Screen Reader Friendly Website Guide
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.