City of Tacoma Web Standards
Last Update: 4-11-12
Revision History
Date
05/31/2011
06/15/2011
06/17/2011
10/13/2011
03/14/2012
03/15/2012
March/April
Name
Pam Murray
Pam Murray
Mike Hammoud
Tedd Crist
Tedd Crist
Tedd Crist
Gail Himes
Reason for change
Document Creation
Added comments from ADA Effective Communication Team members
Added Security Standards from OWASP Top 10 Web App Risks
Revisions to Accessibility Standards
Revisions to Accessibility Standards to match Level AA - Cover
Addition of Compliance section and language throughout document
To ensure full compliance with WCAG 2.0 AA; document to include
any web content purchased or supported by the City of Tacoma
Version
1.1
1.1
1.1
1.1
Table of Contents
1.0
INTRODUCTION .......................................................................................................................................................3
2.0
COMPLIANCE……………………………………………………………………………………………….……….……... 3
3.0
WEB STANDARDS ..................................................................................................................................................7
3.1
3.2
3.3
3.4
HTML VALIDATION ...................................................................................................................................................7
CSS AND JAVASCRIPT SUPPORT ...............................................................................................................................6
Include on Every Page .......................................................................................................................................6
ADDITIONAL CONSIDERATIONS ..................................................................................................................................8
4.0
ACCESSIBILITY STANDARDS ...............................................................................................................................8
5.0
SECURITY POLICY ................................................................................................................................................10
2
1.0 Introduction
This document provides minimum standards compliance requirements for City of Tacoma websites and
applications. Web applications developed or purchased (fully or partially) by the City of Tacoma must work
across a variety of computing platforms, ensure compliance with the accessibility standards outlined in this
document, and adhere to City of Tacoma web security policy.
There is a lot more to making sure a web application works on a user's computer than supporting a
particular version of a web browser. Design choices such as using plug-ins and designing for accessibility can
make a significant difference on whether the application deploys successfully to your users.
This guide recommends web application development and selection strategies to ensure the application:
 is accessible to all users;
 is maintainable;
 can readily adapt to changing needs of users;
 meets applicable legal and City of Tacoma policy requirements;
2.0
Compliance
A compliant City of Tacoma web site must satisfy all of the requirements as set forth in sections 3.0 – Web
Standards, 4.0 - Accessibility Standards, and 5.0 – Security Standards of this document; all web content will
conform to World Wide Web (W3C) Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines
(WCAG) 2.0 Level AA as demonstrated by the submission of a report giving the validation results using the
tools noted in each of the Validation sections noted below. The Accessibility Validation report must provide the
appropriate message stating that the site / page successfully meets the WCAG 2.0 Level AA compliance as
provided by the tool with no messages of any level, including warnings, to be present.
Proof of Conformance to W3C WAI WCAG Level 2.0 AA
Site / Page Code and CSS Validation:
Site / Page Code Validation (use one of the four following options):
ACHECKER http://achecker.ca/checker/index.php
ACHECKER is an online validation tool. This tool points out the lines of code that cause
accessibility issues and provides information on how to correct the error.
WAVE http://wave.webaim.org/
WAVE is an online validation tool. To use this tool navigate to the WAVE page and insert the URL
of the page to be validated. This tool shows the read order and any images without alt text.
Web Design Group (WDG) HTML Validator http://www.htmlhelp.com/tools/validator/
A full site or page validator for all HTML DOC types.
W3C Markup http://validator.w3.org/
W3C is a Markup Validation Service tool. This tool includes options to test a URL, upload a file, or
validate the direct input. Additional options allow messages to be sorted sequentially or by group.
Demonstrable results:
Receipt of the appropriate message stating that the site / page successfully meets the WCAG 2.0
Level AA or W3C accessibility compliance as provided by the tool with no messages of any level,
including warnings.
3
CSS Validation: (use the following validator or a City approved equivalent)
CSS validator: http://jigsaw.w3.org/css-validator
CSS validation service.
Demonstrable results:
Receipt of the appropriate message stating that the site / page successfully meets the WCAG 2.0
Level AA or W3C accessibility compliance as provided by the tool with no messages of any level,
including warnings
Screen Reader Validation:
Internet Explorer: (Use one of the two following options)
NVDA - www.nvda-project.org/
WebAnywhere: - http://wa.cs.washington.edu
Fire Fox: (Use this to listen to site / page with Fire Fox)
Fire Vox - http://www.firevox.clcworld.net/
Demonstrable results:
Clearly understood and functional (with a mouse and without the use of a mouse (mouse
removed):
 Skip to main content link present.
 Alternative text present for all images. Text must convey any content including a
separate descriptive page for complex pictures or tables.
 Clearly understood navigation link text which tells if a link is going to a new site or
opening in a new window.
 No image path or link path is read out loud.
 Readable transcriptions of audio as well as audio descriptions of visually meaningful
video content included for any video.
 Screen reader can be stopped, paused, and resumed at any point on the page.
 Headings, labels and links are easily discernible and describe topic or purpose and
convey meaningful level of information.
 Labels or instructions are clearly provided in readable text form where input is required
and any error message is provided in text form that can be read by the screen reader.
 All tables have column and row headers which describe the data in the cells and are tied
to each data cell while being read by the screen reader.
 Any alternative audio description or text is provided so that it is heard in sync with any
video presented.
 The page reads in a logical and meaningful sequence.
 No sensory dependent instructions are given such as click on red, small, or round button
to stop; green, square or button in top right corner to go.
Color Usage (Contrast and Distinguishable) Validation:
Contrast:
Site (Use one of the two following options)
Snook.ca Colour Contrast Tool http://www.snook.ca/technical/colour_contrast/colour.html
The color contrast tool allows a user to specify a foreground and a background color and
determine if they provide enough of a contrast 'when viewed by someone having color deficits
or when viewed on a black and white screen.
4
Juicy Studio’s Luminosity Colour Contrast Ratio Analyser
http://juicystudio.com/services/luminositycontrastratio.php
Provides a similar function to the Color Contrast Tool mentioned above.
CSS (If CSS is used, use this to validate the CSS for color contrast)
Juicy Studio: CSS Color Contrast Test http://juicystudio.com/services/csstest.php
Web-based tool to check CSS code for appropriate contrast.
Color Blindness: (use the following)
Colorblind Web Page Filter (wickline),
Colorblind simulator is designed to show you what your page looks like to someone with a
particular form of colorblindness. Content should be readable and elements clearly able to be
discerned when viewed through the filter. An example of a poor design would be a page that
relies on color for information that cannot be discriminated by those with colorblindness.
Demonstrable results:
Ensure your site meets or exceed the requirements for contrast and color blind compliance as
stated within the tool’s evaluation criteria. Please note that each tool has its own range of values
and specific criteria for the site to be considered compliant.
In order for a Web page to conform to WCAG 2.0, all of the following conformance requirements must be
satisfied:
1.
Conformance Level: The following level of conformance is met in full.
 Level AA: For Level AA conformance, the web page satisfies all the Level A and Level AA
Success Criteria, or a Level AA conforming alternate version is provided.
 Note 1: Although conformance can only be achieved at the stated level, authors are encouraged
to report (in their claim) any progress toward meeting success criteria from all levels beyond the
achieved minimum level of conformance.
 Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be
achieved if part of a Web page is excluded.
 Note 1: For the purpose of determining conformance, alternatives to part of a page's content are
considered part of the page when the alternatives can be obtained directly from the page, e.g., a
long description or an alternative presentation of a video.
 Note 2: Authors of web pages that cannot conform due to content outside of the author's control
may consider a Statement of Partial Conformance.
2.
Complete processes:
When a web page is one of a series of web pages presenting a process (i.e., a sequence of steps that
need to be completed in order to accomplish an activity), all web pages in the process conform at the
specified level or better. (Conformance is not possible at a particular level if any page in the process
does not conform at that level or better.)
Example: An online store has a series of pages that are used to select and purchase products. All
pages in the series from selection to checkout must conform for a particular page that is part of the
process to conform
5
3.0
Web Standards
"Web Standards" in this section refer to the protocols and languages such as HTML, cascading style sheet
(CSS), and JavaScript that are used to render a web page in a browser and any language affecting the
structure, rendering, and manipulating of the page both server side or browser side.
3.1
HTML Validation
HTML output must conform to one of the following HTML mark up specifications: HTML 4.01, W3C
XHTML 1.0 transitional or strict document type, or W3C XHTML 1.1. (No XHTML frameset doctype).
Character encoding will be UTF-8.
A site may optionally use HTML 5. If the page uses HTML 5 markup, functionality must be in place to
ensure that HTML 5 specific elements degrade gracefully when the page renders.
A compliant site must minimally support Internet Explorer 7.0, IE7. Features targeted to IE7 usually
work well in other browsers such as FireFox version 3, Google Chrome 4 or Safari, version 3.2 and
above. However, browsers other than Internet Explorer are not yet formally supported by the ITD
Infrastructure teams.
Testing the application for cross browser and OS compatibility is a critical step in the application's
development life cycle. It is recommended that web pages be tested against validators as well.
A compliant site must, as a minimum, test successfully on the text-only browser Lynx; the JAWS
Screen reader in Internet Explorer (Windows OS); and the VoiceOver in Safari (Mac OS).
3.2
CSS and JavaScript Support
A compliant site must validate to W3C CSS 1.0 or 2.1 CSS specification. CSS should be used for visual
layout. Tables should be used to present tabular data, not to facilitate visual layout. Alternative
stylesheets will be developed for printers and mobile devices. A compliant site must continue to be
usable when CSS is not available or turned off. A compliant site must ensure, as a minimum, that any
CSS syntax used on pages works across all browsers listed in Section 3.1.
Web pages shall use web safe fonts with additional consideration for mobile access. Sans-Serif web
fonts are preferred. The font-family property shall be set using CSS and should hold several font names
as a "fallback" system, to ensure maximum compatibility between browsers/operating systems. (Start
with the desired font and end with a generic family, to let the browser pick a similar font in the generic
family, if no other fonts are available. For example: p{font-family: Verdana, Geneva, sans-serif). A
compliant site must provide the ability to substantially increase font size. In addition, a compliant site
must ensure, as a minimum, that any JavaScript used on pages works across all browsers listed in
Section 3.1.
3.3
Include on Every Page
The following is required on each page:
 A link to the City of Tacoma’s Web Policy and Accessibility Statement
 A link to the City of Tacoma’s Conditions & Use
 A copyright notice
3.4
Additional Requirements
6
A compliant site must adhere to the following criteria:
 Supporting web documents such as PDF files will be stored on a network file server and
streamed to the web server
 Databases and back end file storage will only be accessed via web services
 The web application will not require any browser plug-ins.
 Content that will be displayed on multiple web sites or pages or that is stored in a database will
be served to the web site using web services.
 Web page images shall be saved at 72 dpi resolution.
 All pages shall set (as a minimum) the page title and page description metatags for search
engine indexing:
 Web pages may be optimized for a monitor resolution of 1024x768 but shall be designed using
a liquid layout that stretches well for any resolution, from 800x600 to 1280x1024.
7
4.0
Accessibility Standards
Designing for accessibility means making site content available to people with a variety of disabilities. In the
United States, there are more than 30 million people with disabilities who can be affected by the design of
computer software.
Designing or purchasing inaccessible applications, can prevent people with disabilities from fully participating
in government and place the City of Tacoma at risk for legal action. Accessible applications support universal
design strategies and the City of Tacoma’s web policy and accessibility statement.
At a minimum, all web content must comply with Sections 504 and 508 of the Rehabilitation Act, conform to
World Wide Web (W3C) Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines (WCAG) 2.0
Level AA, and adhere to the following:
1.
Provide alt attributes alone or, in rare cases with the longdesc attribute for meaningful images.
An alt attribute is a short description of an image that a screen reader can "read" to the user. Images
that don't add any meaning to the web page, such as divider lines, should have empty alt attributes:
<img src="images/divider.gif" width="800" height="10" alt="" /> If an image conveys complex
information, such as a graph, use a brief ALT attribute and link the image to a longer page, (but not in a
new window), with an extended explanation using the longdesc attribute. The alt attribute should be
sufficient to allow users to decide whether they want to follow the link given by the longdesc attribute.
2.
Use headings appropriately to convey hierarchy.
Use <h1> through <h6> tags for page headings, and be sure to use them in the proper order (e.g.,
<h1> precedes <h2>). Use CSS to style heading tags: <h1>Retirement Benefits</h1>
3.
Style text with CSS rather than use images.
Do not create graphics that look like text. Use text and style it with CSS instead: <h2
class="introBlurb">The City of Tacoma encourages businesses to dream big.</h2>
4.
Make sure the site is readable with style sheets disabled,
Images turned off, and in black and white mode.
If you disable CSS, images and / or set the site to black and white the site must be readable and
logical. It may be less visually appealing, but the site should not be confusing or lose information.
5.
Use skip navigation links.
"Skip nav" links allow users to jump to the content and skip the repetitive navigation links. You can
display the skip nav link at the top of a page or use CSS to hide it until the link is active. DO NOT use
display: none; to hide the skip nav link, or else it will also be hidden from screen reader users! Instead,
use a negative value for margin-left to "hide" the link until it has focus. <p id="skipNav"><a
href="#mainContent">Skip to Main Content</a></p>
6.
Use device-independent code.
Design the site for keyboard only use or mouse only use. Do not assume that a visitor will use a
particular input device. The onchange, onhover, onmouseover, and onmouseout JavaScript event
handlers require use of a mouse. Instead, use the onselect, onfocus, and onblur handlers, which work
8
7.
with either a keyboard or mouse. The onclick handler must be used in conjunction with other link and
form elements.
JavaScript should have an alternate presentation.
If JavaScript is used on a web page, provide the equivalent value for users who do not have JavaScript
on their browsers. A common method is to add <noscript> tags immediately after the closing </script>
tag.
8.
Label form elements.
Visually impaired people may need a screen reader to associate a form's input elements and labels. If
the input elements aren't labeled appropriately, the user may complete the wrong field or be unable to
access the form. <label id="name"> Name (first and last name):</label> <input type="text" id="name"
value="name" size="20" />
Ensure the tab order is natural and intuitive. If the design does not allow a natural flow use the tab
index to set the tab flow accordingly.
9.
Caption all video and audio.
Provide synchronized captions for all video and audio files. Meaningful images in videos must include
an audio description to describe the video for the blind or vision impaired.
10.
Don't rely on color alone to convey meaning.
Convey site information using text rather than color references. Avoid instances of "Click the green
button to proceed."
11.
Ensure appropriate color contrast.
Use one of the tools noted in the compliance section above to measure the contrast among graphics,
fonts, and backgrounds on your page. Users can change the site's contrast to suit their needs when
plain text is used instead of images of text (see item #3).
12.
Mark up data tables correctly.
Tables are reserved for tabular data, not page layouts. Designate row and column headers with <th>.
Use the <thead>, <tbody> and <tfooter> tags. Use the scope or id/header attribute to associate data
with the appropriate header(s). A header row must be provided for all data tables with two or more
logical data levels.
13.
Use descriptive text for links.
Screen reading software scans a page for links and provides the list to the user. "Click here" links are
useless when separated from their context. Use descriptive text such as "Explore our academic
programs."
14.
Identify links to PDFs, Word documents, Excel spreadsheets, etc.
This is important for screen reader users, but it's also useful for sighted viewers who may not want to
open another application Include the document designation in the link so that it will be read by screen
readers: <a href="documents/mission.pdf">City of Tacoma Mission Statement (pdf)</a> Ensure PDF is
accessible, properly tagged, booked marked and linking page has link to appropriate PDF reader.
9
15. Open off-site links in the same browser window.
Modern browsers offer tabbed browsing, so a user has control over whether to open a link in a new tab
or new window. By forcing an off-site link to open in a new browser window, users lose control of their
navigation. Additionally, some older versions of screen reading software do not notify users when they
open a new browser window. Users won't know what has happened until they try to use the "Back"
button and find they can't go back. Because screen reading software can be expensive, an upgrade to
a new version may not be feasible.
16. Don't use frames. If you must use them, correctly mark up frames and iframes.
Frames introduce accessibility issues for many screen readers. Add title attributes to all <frame> and
<iframe> tags. If you must use frames, provide equivalent content (or a link to it) within the <noframes>
tags. Similarly, when you're using iframes, provide equivalent content (or a link to it) within the <iframe>
tags. This allows a user to access the content directly if his/her browser doesn't support frames or
iframes.
17. Give a user sufficient time to respond to timed content.
When a timed response is required, alert users and give them sufficient time to respond.
18. Don't create flickering pages or multimedia.
To prevent seizures among optically sensitive users, don't create any pages or multimedia that flicker
between 3 to 55 times per second. Elements that flicker include: animated gifs, text that has been
formatted to blink or scroll and Macromedia Flash animations.
19. Validate HTML and CSS.
Code and Check for IT accessibility compliance.
Test entire site for compliance (see section 2.0 Compliance of this document) and provide results to the
City of Tacoma staff person in charge of this site / project.
20. Ensure City of Tacoma IT web requirements are met.
5.0
Security Standards
All software on any City of Tacoma websites or on any sites hosted by the City of Tacoma shall follow secure
coding practices as outlined in “A Guide to Building Secure Web Applications and Services” by the Open Web
Application Security Project. This doc is available on www.OWASP.org.
A compliant City of Tacoma web site must:



Protect database queries from SQL injections.
Detect for Cross-Site-Scripting Vulnerability, by keeping untrusted data separate from active
browser content.
Use a single set of strong authentication and session management controls, to prevent Broken
Authentication and Session Management.
10








Have a secure configuration defined and deployed for the application, frameworks, application
server, web server, database server, and platform. This includes keeping all software up to date,
including all code libraries used by the application.
Use secured direct object references to an internal implementation object, such as a file, directory,
or database key.
Use SSL to protect secure transmissions of logins and secure data.
Ensure that document headers, footers, or any other portion of the document can NOT disclose a
login id. For example: a document footer with f:\users\isxyz\ should not be allowed.
Applications need to perform a check on URL access rights before rendering protected links and
buttons, need to perform access control checks each time these pages are accessed.
Use proper validation when redirecting and forwarding users to other pages and Websites.
Ensure that document properties do not contain initials or the login id of the document author.
Adhere to all City of Tacoma Network and Security Policies.
11