AHRQ Publishing and Communications Guidelines, Appendix 2-E. Web Site Deployment Checklist

You Are Here: AHRQ Home > News & Information > Information Quality Guidelines > AHRQ Publishing and Communications Guidelines >

AHRQ Publishing and Communications Guidelines

Appendix 2-E. Web Site Deployment Checklist

Please note: This checklist must be submitted with each contract deliverable.

Section I: Web Site/Project Information

Project Name:
Project Manager:
Web Site URL:
Planned Deployment Date:
Project Start Date:
Project End Date:

Description or purpose of application/page (select all that apply):

[ ] Web home page	[ ] Policy page
[ ] Information page	[ ] Employment listings
[ ] Online form	[ ] Graphics page (i.e., maps, photographs, etc.)
[ ] Search page	[ ] Interface page for multimedia
[ ] Search results page	[ ] Web-based application
[ ] FAQ page	[ ] Data-driven application
[ ] Other (describe):

Is this an Internet, Intranet, or Extranet application/page?

[ ] Internet (Public access)
[ ] Intranet (Internal access, behind firewall)
[ ] Extranet (Deployed over Internet but with restricted access to limited user group)

How many visitors do you plan to have monthly?

Number of monthly visits (approximate): _________________________
[ ] Do not track usage or unknown

Return to Section Contents

Section II: Deployment Checklist

The following section outlines requirements that must be addressed prior to deploying Agency Web-based IT applications or Web sites.

#	Concept, Project Initiation, and Planning	Yes	No	N/A
1	Has a Project Initiation Document been completed and submitted to AHRQ IT? If yes, provide date of submission:
2	Has a Project Work Plan or comparable planning document been developed and approved? If yes, provide date approved.
3	Is AHRQ the appropriate agency to produce and maintain this content? (Generally, AHRQ does not support or maintain grantee work.)
4	Who are the intended audiences?
5	Describe the resources necessary to complete and maintain the application or Web site. Are these resources available through AHRQ? Who will maintain the application?
#	Requirements and Design	Yes	No	N/A
6	Does the draft content and proposed design address HHS Web standards (http://www.hhs.gov/web/policies/standardscategory.html)?
7	Does the draft content and proposed design meet legal requirements and incorporate Federal best practices? These include: OMB Policies for Federal Public Web Sites: http://www.usa.gov/webcontent/reqs_bestpractices/omb_policies.shtml Section 508 Standards for Accessible Design: http://www.hhs.gov/usability/pdfs/guidelines.html. Research-Based Web Design & Usability Guidelines: http://www.hhs.gov/usability/pdfs/guidelines.html. HHS Web Policies: http://www.hhs.gov/web/policies/webpolicies/.
8	Has usability testing been considered and/or scheduled? If yes, provide additional information regarding testing dates, outcomes, modifications, or plans.
9	Are all requirements adequately defined and documented? (System Requirements Document, Requirements Traceability Matrix) If yes, provide date of documents submission.
10.	Has the proposed design and architecturally significant components been adequately defined and documented (System Design Document)?
#	Testing, Implementation, and Deployment	Yes	No	N/A
11	Is this site fully functional (no broken links, missing content, etc.)?
12	Is there a defined approach for testing the application or Web site (Test Plan, Test Scripts)?
13	Has usability testing (including user acceptance testing) been performed and all issues addressed?
14	Does the final content and design meet all HHS Web standards?
15	Has AHRQ IT or the Web Communications Division of the Office of the Assistant Secretary for Public Affairs (ASPA) been contacted for clarification, a usability waiver, or exemption? Has/Have the clarification(s), waiver(s), or exemption(s) been documented?
16	Has a report showing the results of usability and/or user acceptance been submitted or attached to this checklist? Note: All exceptions/waivers must be documented.
17	Has 508 testing been performed and all issues addressed? If yes, provide date and outcome.
18	Has the Office on Disability been contacted for clarification, a waiver, or exemption? (Exemptions are typically reserved for bioterrorism, disaster recovery, or national defense/security projects.)
19	Is there a user guide or other help-related documentation available for the intended users/audience?
20	Is there documentation available that provides guidance and defines procedures related to the operational implementation of the application or Web site (Operations Manual)?
21	Is there documentation available that identifies and describes general release information and inventory of software to be released (Version Description Document, Bill of Materials)? If yes, give date provided to AHRQ.
#	Clearances, Security/Privacy Requirements, and Operations and Maintenance	Yes	No	N/A
22	Have all policy or legal clearance issues been addressed? This includes: Secretarial approval. Office of the General Counsel. ASPA communications contract clearance. ASPA print publication clearance.
23	Depending on proposed content, have all legal issues been addressed? Go to http://www.firstgov.gov/webcontent/reqs_bestpractices/laws_regs.shtml.
24	If personally identifiable information is being collected or displayed, has a Privacy Impact Assessment been created?
25	If answered "yes" to question #24, has a System of Records Notice been created and submitted to the Federal Register? Provide date of submission.
26	Have all Agency and departmental security requirements been addressed (Certification and Accreditation, System Security Plan, National Institute of Standards and Technology (NIST) guidance, common controls, etc.)? Provide all copies of documentation.
27	Is the Agency ready to assume maintenance responsibilities of the application or Web site?
Checklist Comments:
[Insert explanations if any questions above were answered "NO" or "N/A"]
Review Meeting Required?	\|_\|	Yes	Review Meeting Date:
Review Meeting Required?	\|_\|	No	Review Meeting Date:

Return to Section Contents

Section III: Section 508 Checklist—Accessibility

This checklist can be used to review each Web page on public Web sites, Extranets, or Intranets for compliance with Section 508 of the Rehabilitation Act. A review can be conducted in anywhere from 5 to 20 minutes, depending on the complexity of the page, and the review process will go faster for successive pages. It is designed to help you do a section-by-section analysis and validate the standards for Web-based resources required by the Access Board: http://www.access-board.gov/sec508/standards.htm. Technical guidance by the Access Board is recommended at: http://www.access-board.gov/sec508/guide/1194.22.htm. The Accessibility Checklist at the end of this document provides additional information on requirements. HHS accessibility standards are at: http://www.hhs.gov/web/508/.

Note: Documentation that supports compliance with all Section 508 checkpoints must be provided prior to production deployment (Test Reports, etc.).

#	Web Accessibility—Non-HTML (PDF, PPT, Word…) Files	Yes	No	N/A
1	For each file, is an accessible alternative (HTML) available or is the native file accessible?
2	Is a link to the appropriate plug-in/viewer provided?
#	Web Accessibility—Electronic Forms	Yes	No	N/A
2	Do all form fields have explicit <LABEL> tags?
4	Do all form fields have a tab index attribute?
5	Do forms fields allow a person using assistive technology to access information, field elements, and functionality for completion and submission of the form including all directions and cues?
6	If form fields are inaccessible to people with disabilities, is there an alternative accessible form or a link to an accessible form?
#	Web Accessibility—Tables	Yes	No	N/A
7	Have tables used for design layout been checked to see if the tables read in a linear method?
8	Do tabular tables use the "summary" attribute and/or tag?
9	Does each table cell provide identification of row and column headers?
#	Web Accessibility—Frames	Yes	No	N/A
10	Does the Web page use frames? HHS should not use frames on its Web pages: http://www.hhs.gov/web/policies/webstandards/frames.html
#	Web Accessibility—Scripts, Plug-ins, Applets	Yes	No	N/A
11	If the page uses scripts, is the script accessible to the screen reader or is there equivalent text provided?
12	Do applets, such as a JAVA applet, contain the same information and functionality in an accessible format?
13	If a plug-in, such as Flash®, Windows Media®, RealAudio®, etc., is used, is a link provided to download the plug-in?
14	If a plug-in is required, does the plug-in comply with Section 508, 1194.21 (Software Applications and Operating Systems)? Go to http://www.access-board.gov/sec508/guide/1194.21.htm.
15	If the product is an application or tool, is it accessible or is an alternative provided that contains the same information and functionality in an accessible format?
#	Web Accessibility—Non-Text Elements	Yes	No	N/A
16	Do all non-text elements have text equivalent descriptions using the "alt" attribute or an alternative method for equivalent description?
#	Web Accessibility—Image Maps	Yes	No	N/A
17	Does the page have duplicate text links for all links within the server-side image?
18	Is there a timetable to replace server-side images with client-side images (except where the regions cannot be defined with an available geometric shape)?
19	Do client-side images use the "alt" attribute to provide text equivalent description and/or an alternative method to provide text equivalent description?
#	Web Accessibility—Multimedia	Yes	No	N/A
20	Is text captioning provided for audible output and audible output provided for visual information?
21	If multimedia content is used, is the audible and video output synchronized to the dynamic content?
#	Web Accessibility—Color	Yes	No	N/A
22	Is the page navigable and understandable without the use of color?
#	Web Accessibility—Navigation and Design	Yes	No	N/A
23	Do pages provide a method for assistive technology to skip repetitive links including navigational links?
24	Do links to descriptive headings or URLs read "Go to,""Select," or "Visit" (rather than "Click here" or "More")?
25	If the page requires a fixed time for response before the page "times out," is the user alerted that he or she will be timed out and given sufficient time to indicate that more time is needed?
26	Does the "include content," such as applets, plug-ins, or animation, cause the screen to flicker with a frequency greater than 2 Hz or less than 55 Hz?
27	If this page cannot be made accessible, is a "text only" version available that is updated the same time the inaccessible page is updated?
#	Web Accessibility—Style Sheets	Yes	No	N/A
28	If the page has style sheets, are they viewable by a user's browser that does not support style sheets?
29	Does the style sheet interfere with style sheets set by the user's browser?

Tips for Accessibility Testing

AHRQ and HHS use automated tools to test accessibility, but they cannot identify all accessibility issues and they also find false positives. Human review is needed to ensure accurate assessment.

After resolving accessibility problems found with automatic testing:

Use an assistive technology device (such as a screen reader) to determine whether information can be interpreted correctly on the Web page:
- JAWS for Windows® (http://www.freedomscientific.com/)
- Window-Eyes (http://www.GWmicro.com/)
- IBM Home Reader 4.0 (http://www.ibm.com)
Test the Web pages with the keyboard only, rather than an event-driven device (mouse, etc).
Test the Web pages with sounds, graphics, and style sheets turned off.

Code Validation

Validate code before deploying it or submitting it as a deliverable. Use:

W3C validator: http://validator.w3.org/
WDG validator: http://htmlhelp.com/tools/validator/

Validate against the HTML 4.01 or XHTML 1.1 Transitional DOCTYPE.

Return to Section Contents

Section IV: Issues

[Record all deployment issues in the project's Action Item Log or use the space provided.]

Return to Section Contents

Section V: Approval and Verification

Project Manager:	_______________________	___________________________	___________________
	(Signature)	(Title)	(Date)
Director of Applications Development:	_______________________	___________________________	___________________
	(Signature)	(Title)	(Date)
Web Communications Division Review Date:	________________________
	(Date)
Final Deployment Date:	________________________
	(Date)

Accessibility Checklist

The following checklist has been provided to assist with ensuring site accessibility and successful accessibility testing. The checklist is organized by checkpoints outlined in Section 508 of the Rehabilitation Act.

Paragraph Checkpoints	Meaning	Checklist
(a) A text equivalent for every non-text element shall be provided (e.g., via "alt," "longdesc," or in element content).	Any graphics added to your site will need to have an "alt tag" (alternative text) within your HTML code. This tag describes details of the graphic. If the graphic is decorative only, you need to place an empty "alt tag" in your HTML code (" "). Example of graphic that adds value: <img src="secretary.jpg alt="The H H S Secretary at the latest News Conference"> (Note: acronyms should contain spaces or the screen reader will try to read the acronym as a word.) Example of graphic for decoration: <img src="yellowsun.jpg" alt=" ">. (Note: Placing this null value will allow the screen reader to skip over the graphic.)	Every image, video file, audio file, plug-in, etc., has an alt tag. Complex graphics (graphs, charts, etc.) are accompanied by detailed text descriptions. The alt descriptions describe the purpose of the objects. If an image is also used as a link, make sure the alt tag describes the graphic and the link destination. Decorative graphics with no other function have empty alt descriptions (alt=" ").
(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.	Multimedia files include audio and video presentations. Video files should have an alternative that is synchronized to the original presentation. Audio files must have a transcript.	Add synchronized captions to videos. Add audio descriptions. Create text transcript for audio. Create a link to the video rather than embedding it into Web pages. Link to the media player download. Link to the text transcript.
(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.	When colors are used as the sole method for identifying screen elements or controls, persons who are color blind as well as those people who are blind or have low vision may find the web page unusable. This provision requires that some other method of identification, such as text labels, must be combined with the use of color.	Two tests: (1) View the page on a black and white monitor. (2) Print out the page on a black and white printer. Both methods will quickly show if the removal of color affects usability.
(d) Documents shall be organized so they are readable without requiring an associated style sheet.	Style sheets can enable users to define specific viewing preferences to accommodate their disability. For instance, users with low vision may create their own style sheet so all text is displayed in an extra large font with white characters on a black background.	Ensure that Web pages do not interfere with user-defined style sheets.
(e) Redundant text links shall be provided for each active region of a server-side image map.	When a Web page uses a server-side image map to present the user with a selection of options, browsers cannot indicate to the user the URL that will be followed when a region of the map is activated. Redundant text links are needed to provide access to the page for anyone not able to see or accurately click on the image map.	Provide a redundant text link for each active region of a server-side image map.
(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.	If you are using a graphic that has "hot-spots" for links. Ex. You may have a graphic of the United States and have area links for each State.	Does the page provide alternative links to the Image Map? Do the <area> tags contain an alt attribute?
(g) Row and column headers shall be identified for data tables.	Tables that contain data in columns and rows need to have the headings for the table. Simple tables (with one column or row of headings) must use scope attributes to associate data cells with column/row headings. Example: Use <th> table header tags for your headings and the <td> table data tags for the data within the tables.	Data tables have the column and row headers appropriately identified (using the <th> tag). Tables used strictly for layout purposes do NOT have header rows or columns.
(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.	Another way to accomplish identifying data cells uses the headers and ID attributes. This method is NOT recommended for simple tables. The headers and ID method should only be used when there is more than one logical level in a table, and when more than two headers need to be linked with a data cell. Complex tables (where the scope attribute does not accurately link the data cells with correct column/row headings) must have ID and header attributes to associate data cells with column/row headings.	Table cells are associated with the appropriate headers (e.g., with the ID, headers, scope, and/or axis HTML attributes).
(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.	Because of the potentially serious nature of seizures, developers should be extra careful to avoid any graphics, animations, movies, or other objects which have strobing, flickering, or flashing effects. Developers should also avoid graphics which may induce nausea or dizziness.	Make sure the page does not contain repeatedly flashing images. Check to make sure the page does not contain a strobe effect.
(k) A text-only page, with equivalent information or functionality, shall be provided to make a Web site comply with the provisions of these standards, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.	Provide an accessible alternative (in HTML) for non-HTML files unless that file is fully accessible.	Every non-HTML file must be accessible, either by having an accessible alternative or be fully accessible itself.
(m) When a Web page requires that an applet, plug-in, or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).	If you are linking to any files that are not HTML, you need to provide the download for the plug-in on the page. Example: File Title (Word File, X MB; Word Viewer) PowerPoint® Viewer: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=048dc840-14e1-467d-8dca-19d2a8fd7485 Excel Viewer: http://www.microsoft.com/downloads/details.aspx?FamilyID=1cd6acf9-ce06-4e1c-8dcf-f33f669dbc3a&DisplayLang=en Word Viewer: http://www.microsoft.com/downloads/details.aspx?FamilyID=95e24c87-8732-48d5-8689-ab826e7b8fdf&DisplayLang=en PDF Reader: http://www.adobe.com/products/acrobat/readstep2.html	A link is provided to a disability-accessible page where the plug-in can be downloaded. All Java applets, scripts, and plug-ins (including Acrobat® PDF files and PowerPoint® files, etc.) and the content within them are accessible to assistive technologies, or else an alternative means of accessing equivalent content is provided.
(n) When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.	When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.	When form controls are text input fields use explicit LABEL elements. When text is not available use the title attribute. Include any special instructions within field labels. Make sure that form fields are in a logical tab order.

Return to Section Contents
Return to Guidelines Contents
Proceed to Next Section