Web templates for Departments

Technical guidelines

Validation and accessibility

The WAI define their levels of accessibility as A, AA or AAA, which are directly linked to whether they pass Priority 1, 2 and 3 requirements (see http://www.w3.org/WAI/ for more information) for universal access to the information on those pages. The institutional policy and statement for accessibility (see http://www.cam.ac.uk/site/) say that a compliance level of AA or AAA is the institutional aim for web pages, and it is the case that most University web sites should be in the process of being made compliant at the AA level. All department sites and those prepared by external contractors should take reasonable steps to ensure their websites are compliant. In summer 2010 the policy and statement will be updated for WCAG 2.0 - guidelines are in preparation and will be published at the same URL as is currently used. This change should not cause a problem for those that are already compliant with the current levels of compliance.

For more help on accessibility background, testing and solutions, see http://www.w3.org/WAI/ and advice at http://diveintoaccessibility.info/ Our suggested accessibility checkers are http://www.totalvalidator.com/ and EvalAccess (http://sipt07.si.ehu.es/evalaccess2/index.html)

The University webstyle templates (http://www.cam.ac.uk/about/webstyle/) are valid xhtml - the DTD at the top of the file declares the level of xhtml that the code is written to. To check validity your pages must have a DTD - the HTML checker at W3 is available at http://validator.w3.org/ or via the Firefox web developers toolbar. You must check validity after you have finished your pages to ensure they are suitable for publishing.

Quick checklist for accessibility and usability

  • Organise pages using consistent structural mark-up. Make sure link text is clear, then you won't have to add title tags for the links.
  • Web information should be system and browser independent and should be validated. Pages should be checked for compatibility on a range of browsers, screen resolutions, colour depths and operating systems, and with text-only browsers (such as lynx). They should have an agreed DTD and be tested valid code.
  • Use of an external CSS is expected but only in accordance with the accessibility guidelines above, especially in relation to cross-browser compatibility. CSS2 styles or @includes can be used to supply CSS solutions for newer browsers where they will cause no difficulties to users with older browsers. Style sheets should be validated.
  • Where graphics are used, appropriate 'alt' text must be supplied for all images (use empty alt text [alt=" "] for purely decorative images or spacer gifs, should there be any). Graphics should be optimised and compressed so the download time is as short as possible. If using image maps, use client-side with text hot-spots. If using multimedia, add transcripts for audio and video - captions as well if this is possible.
  • Absolute font faces and font sizes should not be used on web pages. Use the stylesheets provided and font faces and type sizes will be properly represented.
  • If using data tables, bear in mind that they are read row-by-row when rendered by a speaking or line mode browser (or when indexed by a search engine). Ensure the layout makes sense when read in this way (analysis with WAVE [http://wave.webaim.org/index.jsp] numbers the elements of the page in the order a browser will display it). Use summaries to describe the use of each table.
  • If information is in a format that renders it inaccessible to some users, such as Flash, the information must be made available via another, accessible, route. Neither Javascript nor Java applets should be used to present information. If JavaScript is used for other purposes, ensure the pages will run in a fully comprehensible way without JavaScript.
  • Always add metadata and use a succinct and expressive title. Special care should be taken to add title and metadata to pdfs.
  • Valid HTML entities should be used for all non-(7-bit) ASCII characters, including those in urls.

XHTML

The templates used and provided here are all using XHTML 1 strict. If XHTML is used in the way it is on these pages (most particularly, with a space preceding the terminating / in self-closing elements such as meta and image tags), it will not give any problems for older browsers and may provide some 'future proofing' for your pages. A very easy way of converting existing pages is to use HTML Tidy, which is available for many platforms (http://tidy.sourceforge.net/) and built into some html editors and tools. HTML Tidy will convert your existing page and write a new version - there are various options you can specify during the conversion process. Once converted, you can cut and paste the content into the new templates. HTML pages can be used in conjunction with XHTML pages, providing the DTD at the top of the page and the mark-up are correct

An easy way of validating pages directly from the browser is to use Firefox or Mozilla and the web developer toolbar (which installs into it) - see https://addons.mozilla.org/en-US/firefox/addon/60 for the toolbar. A developer toolbar is built in to Safari and ie8. For Microsoft Internet Explorer web developer tools are built into ie8 and upwards (see http://www.visionaustralia.org.au/ais/toolbar/ for accessibility toolbar).

The title of this document is: Use of University of Cambridge web design: Technical guidelines
URL: http://www.cam.ac.uk/about/webstyle/tech.html

Last updated: 12 April 2010