By John Cady and Jane Vincent
Google Sites is an easy-to-use tool for creating web pages. It has a basic interface that allows text, pictures, links, and other standard features to be added without knowledge of HTML. Its editor also permits some use of HTML code. The M+Google page has links to instructions for using Sites.
However, at this time, the built-in accessibility of this tool is not as advanced as that of many other popular web content management systems used on campus. Additionally, there are some accessibility issues that cannot be resolved due to technical limitations imposed by the tool, and the techniques required to overcome other issues often reduce the user-friendliness and collaborative qualities that make Google Sites attractive. Although WCAG 2.0 Level AA compliance is not achievable in websites produced by Google Sites at this time, there are always steps one can take to increase a site’s accessibility.
Note: we do not yet have information on the ability of assistive technology users to use Sites for creating web pages. When this has been evaluated, information will be posted.
If you are considering using Google Sites to produce a website, here are specifics about implementing accessibility best practices in this tool:
WCAG Guideline(s): Using semantic markup to mark emphasized or special text, Using HTML according to spec
Issue: When a content author emphasizes a piece of text in Google Sites by highlighting it and clicking either the bold (“B”) or italics (“I”) button, Sites renders this with the deprecated <b> or <i> html tags. This may cause problems for some screen readers or other assistive technology, which look for the standard semantically based <strong> and <em> tags.
Work-around: None (unless you want to place the text to be emphasized inside an HTML Box). If you try to adjust the HTML of regular text by clicking the <html> button in the editor, Sites disallows the changes of <b> to <strong> and <i> to <em>.
WCAG Guideline(s): Bypass blocks
Issue: Users ought to have a way to recognize blocks of regularly repeating content (e.g., the header and navigation bar at the top of a page) and skip past them to the main content. Techniques for achieving this include employing skip-navigation links, the map element, and document landmark roles. However, implementing such measures to permit the bypassing of page navigation requires access to parts of the page to which Sites does not permit.
Work-around: None currently.
WCAG Guideline(s): Use a cascading style sheet (CSS)
Issue: Accessibility guidelines usually recommend use of an external CSS, but both external and embedded style sheets require access to the <head> section, which Sites does not permit.
Work-around: Provide style information inline. Unfortunately, this method requires a new style declaration every time the style is used, and not all CSS selectors are allowed.
WCAG Guideline(s): Using table markup to present tabular information, Using the scope attribute to associate header cells and data cells in data tables, and Using the summary attribute of the table element to give an overview of data tables
Issue: The table tool in Google Sites neither allows declaration of table summary, header rows (<th>) or scope, nor will the HTML button on the editor permit one to add these tags/attributes by hand. Though the HTML button may appear to function during editing, when the code is saved these tags/attributes are removed.
Work-around: Use the HTML Box feature to create the table in HTML, employing the best practices for tables. The disadvantage to this method is that the table will then only be editable via HTML, not by the table tool.
WCAG Guideline(s): Check the <h1> heading and heading hierarchy
Issue: Sites provides a field for inputting the page title. However, this field is marked up as an <h3> header, whereas accessibility guidelines indicate that the page title should be <h1>. Beginning the page with an <h3> tag also undermines proper heading hierarchy.
Work-around: None currently. If an <h1> header is added in the HTML code and the field is left blank, the page title will not appear in the browser, which users will likely find more problematic.
WCAG Guideline(s): Text alternatives for non-text content
Issue: In the Sites “Insert image” feature, there is an option for inputting an alt attribute. In some cases, you may want to set it to alt=”” (see the text alternatives for images decision tree). However, if this alt attribute this field is left empty in Sites, the image tag will be left completely without an alt attribute. Yet WCAG 2.0 requires some alt attribute, even if it’s null (alt=””).
Work-around: To insert a null alt attribute, you must place a space in the alt field in Sites Insert Image dialog.
WCAG Guideline(s): Adding a LANG attribute to the <HTML> tag
Issue: Sites does not permit access to the <HTML> tag for editing.
Work-around: Use the HTML editor to add a LANG attribute to a <div> or <span> tag at the very beginning of the <body> section. End this tag just before the closing </body> tag. If you change the language mid-page, make sure to close the original <div> or <span> before adding a new one, then use <div> or <span> to change the language back to the original.
WCAG Guideline(s): Giving users advanced warning when opening a new window
Issue: Sites’ link feature provides a tempting “Open this link in a new window” checkbox. However, WCAG 2.0 requires that users be warned before clicking links that open new windows.
Work-around: Be sure your content authors know that if they check the new window checkbox, they must use the technique in example 1 on this page to warn users that a new window will open when they click the link. (The technique in example 2 would be more ideal as it would warn sighted users in addition to screen reader users, but it likely cannot be achieved using inline styles.)
WCAG Guideline(s): Info and relationships, Parsing: elements are nested according to their specifications
Issue: When creating unordered and/or ordered lists that contain multiple levels, care must be taken to ensure that the HTML is generated properly, since Sites often gets it wrong. If wrong, screen reader users may not be able to understand the hierarchy of the list.
Work-around: Be sure to check the HTML of the list once you’re done editing it by clicking on the <HTML> button in the editor. A proper nested list looks like option 2 here.
WCAG Guideline(s): Using HTML according to spec, Ensuring that opening and closing tags are used according to specification
Issue: Sites declares its pages to conform to the XHTML 1.0 Transitional spec. However, it produces pages with consistent validation errors:
• No character encoding declared at the document level
• Unsupported attributes in tags, missing required attributes in tags, invalid attribute values
• Multiple opening (<html>) and closing (</html>) html tags
We are not certain whether these errors pose problems for current assistive technologies, but by not maximizing compatibility with current and future user agents, they risk creating issues.
Work-around: None currently.
If you have questions about web accessibility, please contact Scott Williams, Web Accessibility Coordinator, at email@example.com or 764-0051. Scott can also add you to the mailing list for the U-M Web Accessibility Working Group (WAWG), which meets on the first Tuesday of each month and also shares information through its listserv.
We will be updating this page as other issues are found. If you have updates or suggestions for this page, please send them to Jane Vincent at firstname.lastname@example.org.