EPA Web Standards
EPA's Web Standards govern content and formatting on EPA's website. The Web Style Guide, shows you how
to apply the standards in the WebCMS.
Side bar header: All EPA public web content must adhere to the EPA Web Standards, the U.S. Web Design
System guidelines, and the 21st Century Integrated Digital Experience Act.
• Accessibility
• Accordions
• Audio files use MP3
• Boxes
• Cards
• Contact Us Page
• Contact Us Links
• Email Address Links
• EPA Look and Feel Template
• Glossaries
• Graphics and Images
• Graphic Logos
• Headings
• Hub Links
• Image Maps
• JavaScript
o JavaScript Files and Libraries Review
Process
• Link Text
• Local Styles
• Maps
• Microsite Format
• New Icon
• On This Page/ Table of Contents
• Page Not Found (404 Error Page)
• PDF Accessibility Requirements
• PDF Links
• Pop-ups and New Browser Windows
• Regulatory Template
• Resource Directory Format
• Sidebar
• Standard Web Formats and Proprietary File
Formats
• StoryMaps
• Thank You Page
• Title/Title Tag
• Video (Office of Multimedia)
• Web Area Home Page
• Web Area Name
• Web Area URLs
• Web Forms
• Writing for the Web
EPA Procedures
In addition to web standards EPA also has procedures and
policies for the web.
• External Links
• Analytics Code on all HTML
• Web Content Review Cycle
All procedures and policies
Related Information
• One EPA Web
• Web Style Guide
Web Standard: Accessibility
Definition
Accessibility means that all visitors, including those with disabilities, can easily access our web content.
Content Requirements
• Tables are for data and content only. Do not use tables for layout. Not only is it not accessible, it is not
responsive or good for usability.
• Meet the standards established for the federal government for Web-based intranet and internet information
and applications. Read Section 1194.22 of the Section 508 Standards for Electronic and Information
Technology from the US Access Board.
• Follow the EPA Web Standards for;
o Graphics and Images
o Maps
o Image Maps
o PDF Accessibility Requirements
About this Standard
Original effective date: 10/14/2020
Last approved on: 04/14/2021
Web Council review by: 04/14/2024 (or earlier if deemed necessary)
Related Information
• Intranet Accessibility Resources
• EPA Accessibility Training Classes
• How to Create a Web-Ready PDF
• EPA’s quality assurance tool
• 508 Compliance Guide for Existing PDFs
Other Resources
• GSA's Create Accessible Digital Products
• HHS Accessibility checklists
Web Standard: Accordions
Definition
An accordion is a list of headers that hide or reveal additional content when selected.
Content Requirements
• While accordions are an included component in the U.S. Web Design System, EPA does not permit
accordions on webpages.
• There are very limited exceptions to the Accordion Web Standard that have been approved to meet user
expectations in limited space:
o Top level navigation of the EPA template (see the Example below)
o News Releases search page
o Advanced search result page
Example
Accordions are utilized in the top level navigation of the EPA template (Environmental Topics, Laws &
Regulations, etc.).
About this Standard
Original effective date: 05/11/2022
Last approved on: 05/11/2022
Web Council review by: 05/11/2025 (or earlier if deemed necessary)
Why can’t I use accordions?
EPA does not support the use of accordions due to accessibility concerns and challenges related to "hidden"
content inside accordions. Users sent by a search engine may not see this "hidden" content.
Web Standard: Audio Files Use MP3
Definitions
• Audio files play sound. There are no images.
• Max file size limit is 1000MB.
Content Requirements
• Audio files are MP3.
• Will need a transcript for the information in the MP3 to meet 508 requirements.
• Audio files should be technology agnostic and played by the browser. This means you should not use
proprietary products such as AIFF or WAV.
• You may only use file types for applications which EPA has Terms of Service agreements. Individuals may
not accept most standard on-line terms of service agreements. Terms of Service is negotiated at the Agency
or federal level.
Examples:
Public Service Announcements
About this Standard
Original effective date: 04/08/2015
Last approved on: 03/11/2020
Web Council review by: 03/11/2023 (or earlier if deemed necessary)
Related Content
•
Adding an Audio File with a Text Alternative
• Section 508 Accessibility
Web Standard: Boxes
Definition
Boxes highlight specific web content.
Content Requirements
• Use the boxes found in the EPA stylesheet. They are part of the look and feel and are described fully at:
Style Guide: Boxes
Box Styles
• Alert Box: Emergency alert or other important information. The title must convey the specific alert or
emergency. Use on any page.
• Blog Box: used to pull in EPA blog content. Used primarily on homepages.
• Highlight Box: to highlight one set of related, critical or featured content
• Image box (with or without a caption): sets the image apart from content and floats it left or right
• Multi-purpose box: For content that doesn’t meet any of the other definitions.
• News Box: Lists of recent events, news items, or upcoming calendar events.
• No Style Box: For microsite homepages
• Pull Quote Box: To quote text from the content of the page. You can also use the pull quote author style for
the author.
• Quiz Box: uses the simple box (now Multipurpose Box without Title). Used primarily on homepages.
• Related Information Box: lists of related information, that is not critical or featured content.
o On Homepages:
Use for Related Topics box on resource directory homepage, if used.
No images because this is for less important content.
o On Basic pages: can use an image if needed
• RSS Feed Box: used to pull RSS feeds from EPA newsroom. If 3rd party content is used, you are
responsible for 3rd party content. Used primarily on homepages.
• Simple Box (now Multipurpose Box without Title): contains text or image in the box content. No title or
image header. dark grey border; does not have colored background heading.
• Special One Item Box: Contains one link to one featured event or content feature.
• Summary Box: Identified by no title/header and blue background.
Example
See: Style Guide: Boxes
Web Standard: Cards
Definition
A card acts as an entry point to more detailed information on a topic through the use of a single call to action
(button). An individual card is typically part of a collection of similar cards, not a single card in isolation.
A "Card group" creates a row of cards.
Content Requirements
• Each card group (row) must contain at least two cards (flag layout) or three cards (default layout).
• No more than two card groups (row) should be used on a single webpage.
• Each card must contain only one link.
• Follow the guidance outlined in the Creating Cards How To.
• Follow the Link Text Standard.
Example
See: Creating Cards How To.
About this Standard
Original effective date: 05/11/2022
Last approved on: 05/11/2022
Web Council review by: 05/11/2025 (or earlier if deemed necessary)
Related Information
• Pattern Lab Style Guide: Card component
• Creating Cards How To
Web Standard: Contact Us Page
Definition
Each web area must include a Contact Us page with contact information specific to that area. When a web
area is created in the WebCMS, a Contact Us webpage and accompanying Webform is automatically created.
Content Requirements
• The page title should be Contact Us About (Topic name).
• Contact Us pages must include the following ways of contacting the web area's owner:
o mailing address
o online form for sending questions or comments
• Contact information on the Contact Us page may refer to a group or hotline rather than a specific person.
However, if email addresses are provided, they must be epa.gov.
• The Webform associated with the Contact Us page must be edited to include an email address which will
receive web inquiries.
• Webforms on Contact Us pages must allow for anonymous comments. Do not make the name or email
address fields on the form required elements.
• After submitting a form, the user must receive a follow up confirmation page. This “thank you page” is
automatically generated by the WebCMS, but you can modify the text.
• Contact information must be validated every 90 days.
About this Standard
Original effective date: 03/22/2002
Last approved on: 08/11/2021
Web Council review by: 08/11/2024 (or earlier if deemed necessary)
Related Content
• Web Standard: Web Forms
• Style Guide: Forms
• WebCMS Create and Modify Forms
• Web Standard: Contact Us Links
• Web Content Types and Review Schedule
Web Standard: Contact Us Links
Definitions
The Contact Us link for your web area appears twice on each EPA page: at the top and directly above the
footer. It links to the web area Contact Us page, which provides information about how to contact EPA staff
responsible for the web area content.
Note: There is a Contact Us link in the footer of the template for each page that links to the main EPA Contact
Us page. This link requires no action on your part.
Content Requirements
• Contact Us links are required at the top and bottom of every EPA Web page. Both links must point to the
same Contact Us page.
• Both Contact Us links are automatically added to pages in the WebCMS.
o The top link reads: “CONTACT US”
o The bottom link reads: “Contact Us to ask a question, provide feedback or report a problem.”
• Public facing content outside the WebCMS must have Contact Us links.
About this Standard
Original effective date: 03/22/2002
Last approved on: 06/10/2020
Web Council review by: 06/10/2023 (or earlier if deemed necessary)
Related Content
•
Web Standard: Web Forms
• Style Guide: Forms
Web Standard: Email Address Links
Content Requirements
Write out and link email addresses. Encode email with "mailto:"
Examples
Write out and link email address not person's name.
Yes: Mary Cuppacoffee (cuppacoffee.mary@epa.gov) can provide more information.
No: Mary Cuppacoffee can provide more information.
No: Mary Cuppacoffee (cuppacoffee.mary@epa.gov) can provide more information.
Write out and link email address.
Yes: Send email to baggadoughnuts.joe@epa.gov.
No: Send email to Joe Baggadoughnuts.
About this Standard
Original effective date: 09/28/2005
Last approved on: 02/10/2021
Web Council review by: 02/10/2024 (or earlier if deemed necessary)
Web Standard: Look and Feel Template
According to the 21st Century Integrated Digital Experience Act (IDEA), agencies must adopt the standards
developed by GSA—the US Web Design System (USWDS) for all websites and applications. There are no
waivers or exemptions. EPA must report conformance to this standard to Congress every year.
The standard look and feel of EPA public websites consists of the top (header) and bottom (footer), as well as
individual components. The WebCMS follows this standard and produces this look and feel automatically. All
other EPA applications must also follow this standard and use the components that make up this look and feel.
Content Requirements
• Every public EPA application must use the elements below:
o Global header, at the top:
Banner that identifies your site as an official website of a government organization in the
United States
EPA logo in the upper left
EPA Search box, posting to search.epa.gov, in the upper right
EPA main navigation blue bar, with four links (as of April 2022)
o Global footer, including all links and EPA seal, at the bottom
o USWDS Components
o Analytics: include the Agency's standard Google Analytics Tag Manager tracking code
• Applications should follow all EPA Web Standards and other Web Procedures and meet Section 508
requirements just like all web content.
New applications can download this Pattern Lab page. Existing applications can choose to add the individual
components or the Pattern Lab template. All applications must conform to this standard by 15 October 2023.
About this Standard
Original effective date: 02/11/2015
Last approved on: 05/11/2022
Web Council review by: 05/11/2025 (or earlier if deemed necessary)
Related Information
• Procedure: Complying with EPA.gov “Look and Feel”
• One EPA Microsite Format
• One EPA Resource Directory Format
• Story Maps Guidance
Web Standard: Glossaries
Definition
A glossary is a list of terms and their associated definitions, usually related to a particular program or subject.
In order to foster understanding, numerous EPA Programs make glossaries available on their web pages.
Terminology Services (TS) is a centralized approach for maintenance and display of glossaries at EPA.
Content Requirements
Please note: this standard does not apply to glossaries within or attached to a particular document, but rather
stand-alone, web-based Program glossaries.
• Glossaries must be managed in Terminology Services including glossaries that currently exist only on a web
page. They may not be managed on a static HTML page, nor in a document attached to a web page (e.g.
pdf).
o Note: most EPA Program glossaries have already been loaded into Terminology Services.
• For guidance on how to manage a glossary in Terminology Services, please refer to the Glossary
Management Guide (doc) (10 pp, 3 MB)
Terminology Services is a web-based system and suite of services for creating, maintaining, searching and publishing
glossaries and taxonomies. Terminology Services is backed by an enterprise terminology management tool called
Synaptica. The purpose of this guidance is to give glossary owners the information needed to access and use
Terminology Services’ Synaptica to update glossaries as required by the EPA Web Glossary Standard to support the
display of their glossary through Terminology Service: an efficient way to create, maintain, and house your program
glossary in one location, then link to it from wherever you would like.
• For more information on managing your glossary in Terminology Services, including best practices for
creating and maintaining glossaries, please see: Terminology Services References
• Provide a link from your web page to your glossary within Terminology Services.
• Review/update your glossary at least once a year.
• Before creating a new glossary or revising an existing one, you may want to review the Terminology
Services repository to determine if existing content can be used in creating or standardizing your glossary.
Examples
Exchange Network
About this Standard
Original effective date: 02/08/2012
Last approved on: 10/14/2020
Web Council review by: 10/14/2023 (or earlier if deemed necessary)
Related Information
Terminology Services Frequent Questions
Web Standard: Graphics (Images, photos, infographics)
Definitions
• A graphic is an image, including photos, logos, icons, static maps, infographics, diagrams, charts (including
bar charts, pie charts, flow charts and organizational charts), graphs and other images. For the purposes of
this standard, graphics do not include videos.
• A decorative graphic/photo adds visual appeal to the page, but does not expand visitors’ understanding of
the content. A graphic/photo without a caption is assumed to be decorative.
• An explanatory graphic/photo provides information and expands visitors’ understanding of the content
covered by the page. An explanatory photo should have a caption.
• A banner (or hero image) is an image or series of images located at the top of a web page that spans more
than half the width of the page.
• An Infographic is a graphic visual representation of information or data intended to present information
quickly and clearly.
Graphic Requirements
• Graphics should adhere to the standards set forth in the Image Guidance.
o Resource Directory Format
o Microsite Format
o Image Guidance
• Before developing any multimedia content (video, infographics, animation, GIFs, etc.), please contact your
PROTRAC Approver, Communications Director, and/or Public Affairs Director.
• Do not infringe on copyrights, trademarks, and other intellectual property rights. See Copyright Issues
• Do not stretch the image out of proportion.
• Images should be related to the content.
• Formats: Use only GIF (.gif), JPEG (.jpg, .jpeg), or PNG (.png) formats.
• In the instances where a larger size graphic is necessary to see vital detail, add a link below the graphic with
link text such as, "View a larger version of this image".
• Do not use HTML to manipulate the size of the image, stretching it out of proportion.
• Banners/hero images should only be on microsite homepages. Adding banners to sub-pages gives them a
level of importance that they don’t have. Specific exceptions granted by the Office of Web Communications.
Related Links
• How to add images in the WebCMS
• EPA Copyright
• The requirements in this standard do not apply to videos
(see Web Standard: Videos).
Section 508 Requirements
• Do not use images that include text.
o Do not add text to images that are intended to serve as headers.
• Decorative photos should use empty alt text. The final code should read (alt=””).
• Graphics should have alt text or captions because the image adds context to the page and needs an
explanation.
• Information conveyed in an infographic should also be provided in a text alternative on the same page or in
a section 508 compliant pdf. Users should be aware that the information on the page or pdf is the same
information as in the infographic.
Related Information
• Images in the WebCMS
• Web Standard: Graphic Logos
• Image Guidance (applies to images on One EPA Web site home and hub pages)
• Posting Copyrighted Works on EPA's Website
• You can also search on Flickr for photos that are posted with a U.S. Government works license.
DO NOT DO THIS. Don’t add text to
images. Image demonstrating
graphic as a header. Click on the
image to view a larger version.
Other Visual Standards
•
Web Standard: Maps
• Web Standard: StoryMaps
• Web Standard: Image Maps
• StoryMaps Guidance
If you still have questions, contact EPA’s Section 508 Team.
Examples of Graphic Types
About this Standard
Original effective date: 10/08/2014
Last approved on: 06/09/2021
Web Council review by: 06/09/2024 (or earlier if deemed necessary)
High Quality Images
We are no longer limited by download speeds, so use high quality and large images no bigger than 10MB. If the
system delivers responsive content and the appropriate image size, add the best image you have, and let the system
deliver the appropriate image size depending on device.
Examples of Graphic Types
Example of an infographic. Click on the image to view a larger version.
Web Standard: Logos
Content Requirements
OPA discourages the creation of program logos because they dilute the EPA brand. If you must have one, your
Web Council member and the Office of Public Affairs (OPA) must approve all program logos in advance.
Contact the Office of Web Communications (OWC@epa.gov).
About this Standard
Original effective date: 09/28/2005
Last approved on: 10/14/2020
Web Council review by: 10/14/2023 (or earlier if deemed necessary)
Web Standard: Headings
Definitions
Headings are the headlines used on a page. Headings are used in descending levels of size and emphasis,
enabling clear and precise content organization. They create scannable and easy-to-use pages for all
audiences.
Content Requirements
• The page title of all EPA pages is an <h1> element. Only the page title can be <h1>.
• Use <h2> to <h6> in the proper descending order.
o These headings should be used as you would an outline structure.
o Any skipping of levels breaks the flow of the page for readers. Choosing to use an heading tags out of
order, for purely visual appeal, renders your content less useful and less accessible.
• Headings should use title case (initial upper case letters) for major words.
• Highlighted headings, with a light-blue background color (<h2> through <h6>), are also available in the
WebCMS style sheet.
o Apply consistently to one header size per page. For example, if one <h3> is highlighted, all <h3>s, and
only <h3>s, should be highlighted.
• Do not add hyperlinks to headings.
• Insert anchors in front of text, not by highlighting the entire word or string of words first.
Example
See: Style Guide: Headings
About this Standard
Original effective date: 09/12/2012
Last approved on: 12/09/2020
Web Council review by: 12/09/2023 (or earlier if deemed necessary)
Web Standard: Hub Links
Definition
Hub links take visitors to the home/hub pages of microsites and resource directories on related topics. They
appear in the upper left corner of basic pages created within a resource directory (‘spoke pages’), after the
phrase "Related Topics:". Resource directories do not have any other secondary navigation menus, like
breadcrumbs or sidebar links.
• The first hub link is generated by the Web CMS.
• If another resource directory or microsite links to the same spoke page, another hub link can be manually
added to that resource directory or microsite.
• There is no limit on the number of hub links you are permitted to add.
Example
About this Standard
Original effective date: 09/12/2012
Last approved on: 02/10/2021
Web Council review by: 02/10/2024 (or earlier if deemed necessary)
Related Information
• One EPA Web
• Resource Directory Format
• Adding HubLinks
Web Standard: Image Maps
Definitions
An image map is a static image with clickable areas. An example includes the standard U.S. National Maps but
image maps can be made from any image like RadTown’s Waterfront.
Content Requirements
• All image maps must be responsive.
o All image maps need to include javascript to make it responsive to the screen size and ensures that the
links are in sync with the image. See JavaScript: Responsive Image Maps for the code.
• Image maps and each clickable region must include alt text.
• Pages with image maps must provide an alternative way to access the links in the image map for users
without javascript.
• U.S. map of states or EPA regions must use the standard U.S. National Maps (formerly called ‘Where You
Live’)
About this Standard
Original effective date: 07/08/2020
Last approved on: 07/08/2020
Web Council review by: 07/08/2023 (or earlier if deemed necessary)
Web Standard: JavaScript
Modern JavaScript is a powerful language, and we can do so much with it these days, from simple content and
UI updates to fully-fledged 2D and 3D games. At the same time, you need to ensure that your page and script
are accessible.
A web page containing JavaScript will typically be fully accessible if the functionality of the script is device
independent (does not require only a mouse or only a keyboard) and the information (content) is available to
assistive technologies. Unfortunately, there is no easy fix that can be applied to solve all accessibility problems
associated with JavaScript. The only way to ensure JavaScript accessibility is by evaluating each page that
utilizes scripting and devising a unique solution to any accessibility problem found.
Definitions
JavaScript (JS) is a client-side scripting language. You can use it to validate forms, detect user actions (such
as individual keystrokes), or retrieve data from the server without interfering with the display or behavior of the
open web page. JavaScript can also power entire applications, like Gmail.
Accessibility: It is a common misconception that people with disabilities don't have or 'do' JavaScript, and
thus, that it's acceptable to have inaccessible scripted interfaces, so long as it is accessible with JavaScript
disabled. A 2012 survey by WebAIM of screen reader users found that 98.6% of respondents had JavaScript
enabled . Accessibility guidelines also require scripted interfaces to be accessible. WCAG 2.0 and all
other modern guidelines allow you to require JavaScript, but the scripted content or interactions must be
compliant with the guidelines.
EPA uses jQuery as its main JS library. This library "sits" on top of JS and makes common tasks easier. When
you write in jQuery, you're still writing JS, but what used to be 50 lines may now be one or two. All Drupal
WebCMS content include the master jQuery file. You need not include it separately.
We provide a standard suite of JS files for everyone at the Agency to use. Linking to the EPA master JS files
will improve your site performance, as users will cache a copy of the files. All JS, in content managed by the
Drupal WebCMS, is output at the bottom of the HTML, just before the closing </body> tag. Placing scripts here
speeds up epa.gov for our readers. Area webmasters in the Drupal WebCMS can write JS, per page, as
needed.
Content Requirements
• Do not use too much JavaScript.
o Sometimes you'll see a website where everything has been done with JS: the HTML has been generated
by JS, the CSS styling has been generated by JS, etc. This has all kinds of accessibility and other issues
associated with it, so it is not advised.
• You should not use JS to create or modify styles for your content.
• All JS must go into the Page JavaScript field in Drupal WebCMS; JS in any other field is stripped out.
o JS for your application can go anywhere in the HTML; we recommend you output it at the bottom of the
page or that you defer its loading.
• Web pages should not be dependent on JavaScript to work.
o Functions first check to see if an object is available. If not, then fail silently
o HTML and JavaScript are separated: no inline event handlers
o With JavaScript off, nothing happens; thus, <noscript> is unnecessary
• If you offer advanced functionality and your pages cannot work the same way without JS:
o Ensure that you account for users without JavaScript.
While this does not necessarily mean that all functionality must work without scripting (though this
would clearly be optimal), if it does not work without scripting, you must avoid a confusing or non-
functional presentation that may appear to function, but does not because of lack of JavaScript
support.
o At a minimum, provide text equivalents.
o Provide a phone number or email address to get help.
About this Standard
Original effective date: 09/28/2005
Last approved on: 02/12/2020
Web Council review by: 02/12/2023 (or earlier if deemed necessary)
Related JavaScript Topics
• JavaScript: Before and After Images
• JavaScript: Colorbox
• JavaScript: Creating a Quiz Example
• JavaScript: Data Visualizations
• JavaScript: Datatables
• Javascript: Dropdown Navigation
• JavaScript: Embedding Twitter Timelines
• JavaScript: EPA Blog Feeds
• JavaScript: Federal Register Feeds
• JavaScript: Files and Libraries
• JavaScript: Leaflet
• JavaScript: Responsive Image Maps
• JavaScript: RSS Feeds
• JavaScript: Tablesorter
• JavaScript: Timelines
Related Documents
• JavaScript Files and Libraries Review Process
• JavaScript: Files and Libraries
JavaScript Files and Libraries Review Process
EPA has established this JavaScript (JS) review process and will maintain strict control of JS use in the One
EPA Web environment. Most potential JS files and libraries will undergo review prior to being used in the One
EPA Web environment. Third-party JS, with some exceptions, is not allowed on www.epa.gov.
There are four classes of JavaScript files that can be found in the Drupal WebCMS:
1. library/framework scripts, like jQuery
2. component/plugin scripts that require a library, like jQuery UI, jQuery Colorbox
3. common application-level scripts that are shared among multiple pages and might require the above
4. JavaScript embedded on a single page that might require the above
While JavaScript files and libraries can be easily written and deployed on an EPA server, larger issues are
security, redundancy, and the need for caching.
• An improperly-written JavaScript file can introduce security vulnerabilities which hackers can exploit to cause
damage to the EPA Public Access servers.
• We want to reduce the number of duplicate JS files on the Drupal WebCMS server. (Duplicate JS files occur
when multiple versions of the same JavaScript file(s) are uploaded.)
• We want to reduce duplicate functionality. As an example, there are dozens of lightbox-style scripts that do
the same thing in a different way.
• We want to take advantage of caching—many JS files and libraries are large files, and if each of us link to
and use the same files, we reduce our bandwidth and improve overall visitor experience.
• For these reasons, OMS maintains control over JS files on the WebCMS server. OMS will be reviewing all
uses of JavaScript to ensure appropriate coding style and usage. Approved JavaScript files and libraries are
added to the WebCMS server, and you can link to these approved JavaScript files and libraries from your
EPA web pages.
•
Third-Party JavaScript
Like plaintext HTTP, the ability to pull in arbitrary third party service JavaScript that has full control over session
privacy/integrity, without any meaningful containment mechanisms, is a legacy pattern from a less security-
aware time in web browser development. Such libraries and files represent a significant security risk.
Unfortunately, there's not a simple technical or policy solution, other than prohibiting them completely.
Therefore, EPA prohibits the practice of using third-party JavaScript libraries. Exceptions include Google
Analytics, CrazyEgg, Foresee Verint, and other analytics software.
OMS maintains a set of JavaScript libraries that are kept up-to-date for your use. Well-known third-party
libraries may be added through the process outlined on this page.
The Review Process
OMS cannot help you troubleshoot your JS code. If you're using the included JS, please see the Web Style
Guide for examples and how-tos. If you're writing your own code or submitting a third-party library, you must
know what you're doing. It is your responsibility to ensure that no conflicts exist between your code and the
existing JavaScript already in use for the One EPA template and the Drupal WebCMS application.
All JavaScript files not already in use and approved must be reviewed, and your office will be responsible to
fund that review via a Working Capital Fund service agreement (you will need a registration code). It should not
take more than 10 hours per submission, but you should allow for at least five days for the scanning process
(there's a queue). As scripts are submitted, we will monitor them for candidates to make generally available as
part of our documented / semi-supported library. You, the original submitter, will remain primarily responsible,
and OMS will serve as intelligent librarians, not code-maintainers.
Highly-regarded and well maintained third-party libraries may go through a shorter review process and be
added to the Drupal WebCMS servers by OMS.
Contact the TZ Service Manager in OMS to set up a TZ account to pay for the JavaScript code review under
Working Capital Fund Services. OMS will work with CSRA to give you a cost estimate and a description of
what they will do.
• Criteria for Approval of JavaScript Files and Libraries
• Lifecycle for JavaScript Files and Libraries
1. Development
General Coding Rules
2. Security Checklist and Application Deployment
3. Updating a JavaScript File or Library
4. Retiring/Reactivating a JavaScript File or Library
• Using Standard and Certified JS Files on Production Web Servers
• Using JavaScript for Dynamic (Small) Applications
Criteria for Approval
Any content editor developing and maintaining JavaScript files (i.e., those developed for specific use and from
outside NCC) must certify that the scripts are designed and implemented according to established guidelines
and security standards.
• EPA JavaScript Web Standard
o JavaScript is ideally used to enhance pages and user experience. Pages should be able to display all of
the real content and media when JavaScript is disabled.
o The use of JavaScript is discouraged when server-side coding can accomplish the same end goal.
o JavaScript should not be used to query complex datasets requiring numerous data files.
o JavaScript should not be used to perform complex calculations.
• OMS will approve the following:
o dynamic data presentation, such as from data files: CSV, JSON, XML;
o database calls to an EPA data source via AJAX/jquery;
o interactivity, including forms and form results.
• OMS will disapprove the following:
o Code that does not pass the JSHint (or JSLint) or EPA scanning processes;
o Code that is not properly licensed for use by EPA;
o Code that changes the EPA One Web look-and-feel (local styles are not allowed);
JavaScript that breaks the responsive design template;
JavaScript that injects HTML onto a page with contain local styles;
o Anything already part of the standard libraries or that can be achieved using JS files and libraries already
approved;
o Any packed/minified JavaScript provided for to review.
Lifecycle of a JavaScript File or Library
This section outlines the life cycle of a JavaScript file or library in the Drupal WebCMS environment.
Stage 1. Development
• The Application owner begins development and testing of JS. The EPA specifically provides the Drupal
WebCMS Sandbox server for this purpose. The sandbox server has the same code as the production
environment, decreasing the testing and debugging time. There is no cost to step up a user account on the
sandbox. If you have an account on the production server, you also have an account on the sandbox.
• During development the JavaScript coder should review the security issues as outlined in the JavaScript
Program Security Checklist and Deployment Request Form. JS files will be expected to conform to these
standards. Any script not in compliance with these standards will be disapproved.
• You will first provide the JS files to OMS so that we can load them into the sandbox. A list of dependencies
must be provided to OMS by the developer so that the JavaScript can be loaded in the correct order on the
page. Once the files are available, you will build your page and code.
General Coding Rules
• The long-term value of software is in direct proportion to the quality of the codebase. Over its lifetime, a
program will be handled by many pairs of hands and eyes. If code is able to clearly communicate its
structure and characteristics, it is less likely that it will break when modified in the never-too-distant future.
• Code conventions can help in reducing the brittleness of programs. To the extent possible, follow Douglas
Crockford's coding standards for JavaScript.
Stage 2. Security Checklist and Deployment
• Once development and testing has concluded, the JS owner submits the JavaScript Program Security
Checklist and Deployment Request Form to WebCMS Support (web_cms_support@epa.gov). No work can
take place until you have a registration id/charge code set up for vetting submitted code.
• Submitted JavaScript files will be vetted by our contractors--they will scan your code and page. The code
owner (you) will pay for this vetting, which should not take more than 10 hours of work per code submission.
(Note that this means you pay for every submission, so it's to your benefit to ensure that the submitted code
works.) This review process can take up to five days (there's a queue).
• If the code passes review:
The JS files and libraries will be placed into the production repository (our revision control system). You will
no longer have write access to the code. All changes to code will be recorded. Rollbacks to previous
versions will be possible. You can request a rollback by emailing
WebCMS Support
(web_cms_support@epa.gov).
• If the code fails review:
You will be notified with a copy of the review along with recommendations. The JavaScript then can be
further developed until the security requirements are met. JavaScript that does not meet security and coding
standards will not approved.
• If a JavaScript fails on the production server:
If a JavaScript file or library fails in the production environment, OMS can provide only limited support (e.g.,
assist in the identification of failure points in the code). If problems cannot be fixed quickly, you must retest
the code on EPA's Drupal WebCMS Sandbox server.
Stage 3. Updating a JavaScript File or Library
• As OMS will manage the revision control system, you will no longer have write access to your production JS
file or library. You will modify your JS on the Sandbox server and, when testing is complete, make a JS
Update Request by contacting us.
• After the request has been received and confirmed with you, OMS will run a diff on the two scripts. New
code will be reviewed and tested. If the JavaScript passes review, it will be certified and updated as noted
above. If it does not pass review, you will be notified as above.
• If necessary, you can request that current code be rolled back to a previous version. To rollback, make a JS
Update Request. One caveat: if the code is out of date, it will be subject to a new review before it is restored.
Stage 4. Retiring/Reactivating a JS File or Library
• If a JavaScript is no longer required, you can retire it by submitting a JS Update Request.
• The script will be retired from active use, archived, and available for reactivation. To reactivate it, submit a
JS Update Request. One caveat: if the code is out of date, it will be subject to a new review before it is
restored.
Please note that OMS will review JS usage periodically. If the code has not been used or accessed in
the last 60 days, you will be notified. You can then determine if the JS should remain operational or be
retired.
Using JavaScript for Dynamic (Small) Applications
One reason we're opening up JS for our content editors is captured in the image to the right, which shows an
example of using JS to read and output data from an external data source (whether another EPA server or an
uploaded data file).
DataTables or Highcharts, or other scripts, will help you display this external file-based data.
Examples include the Superfund Where you Live dataset (powered by Datatables and a JSON file), Region 1's
Charles River Buoy dataset (powered by Highcharts and a CSV file).
The flow of JS applications
Web Standard: Local Styles
Local styles are created outside of the standard EPA style sheet. These are not allowed. One EPA Web uses
only EPA standard styles found in the style guide. EPA's official branding is managed by the Office of Public
Affairs. The 21st Century Integrated Digital Experience Act requires a standard look and feel.
See: Style Guide
About this Standard
Original effective date: 09/12/2012
Last approved on: 11/10/2020
Web Council review by: 11/10/2023 (or earlier if deemed necessary)
Related Information
One EPA Web Standalone Template
Web Standard: Maps
Definition
Maps may be:
• Interactive
o EPA’s GeoPlatform
o Leaflet
Leaflet is an open-source and lightweight JavaScript library for mobile friendly interactive maps. This
library is aimed at simple maps. See the
Leaflet JavaScript Library page for more information on
usage and benefits.
• Static map image - a picture of a map
Content Requirements
• Do not use Google maps or other commercial maps. We have no licensing agreement for Google Maps.
• U.S. map of states or EPA regions must use the standard U.S. National Maps (formerly called ‘Where You
Live’)
• Maps will have:
o A title, that includes the word “map”, located above the map in header tag <h2> – <h4>.
o A description in caption text or alt text of what the map displays.
o A link to equivalent content in text form.
• Recommended best practice is to link to equivalent content in text form. Near-Real-Time and Laboratory
Data by State is an example.
About this Standard
Original effective date: 09/12/2012
Last approved on: 07/08/2020
Web Council review by: 07/08/2023 (or earlier if deemed necessary)
Related Information
• EPA GeoResources page (map development)
• StoryMaps
• Web Standard: Image Maps
EPA Microsite Format
A guide to creating microsites that comply with One EPA Web. Be sure you have first considered whether
Resource Directory or Microsite is most appropriate for your content.
On this page:
• Overview
o Definition; Structure
o Microsite Goals
o Principles
o Measures of Success
• Microsite Development
o Editor-in-Chief Responsibilities
o Work Products During Microsite Development
• Requirements of a Microsite
o Content Selection and Style
o Required Content Elements
o Content that Should Not be Included in a Microsite
o Look and Feel / Navigation
o Review
Overview
Definition; Structure
The microsite format presents web content on a topic in a single, consolidated site with self-contained
navigation. Content may come from several EPA offices. All content in a microsite has same look and feel and
same area navigation. Microsites often include multimedia and social media outreach tools.
Web Standards
• Resource Directory Format
• Sidebar
• Web Area Homepage
• Regulatory Template
• Contact Us Page
• Graphics and Images
Microsite Goals
• Provide a unified location for information in a way that addresses the needs of the most significant audiences
for that topic.
• Raise the most appropriate content for targeted audiences to a top level.
• Actively manage the content.
Principles
• An Editor-in-Chief (EIC) is responsible for the development and active management of each microsite,
including reviewing the metadata, managing and reviewing content, fixing broken links, responding to
comments/questions etc.
• The site is actively managed and updated.
• Microsite development includes:
o Reviewing content about a topic on existing areas to see if it needs to be rewritten to a specific
audience, written more for the web, written in more plain language, etc.;
o Identifying information needed to meet the needs of top audiences;
o Incorporating the use of statistics to make decisions;
o Removing duplicative or conflicting content on epa.gov;
o Creating a consolidated resource that, if appropriate, includes information from headquarters
and Regional offices.
Microsite Development
Before you request a Microsite, you will need to complete the following tasks:
• Identify the purpose of the microsite.
• Identify 1-3 top audiences to properly focus content selection; for each of those audiences, identify the
1-3 top tasks they seek to accomplish when they come to epa.gov.
• Determine whether the Office of Public Affairs (OPA) AA will need to review (contact Angela Shogren)
and/or whether any special approvals are necessary for high-profile content.
Editor-in-Chief Responsibilities
• Ensure that metadata for all content, no matter the file type, exists and is appropriate.
• Maintain and update the area, complete metadata review, manage and review content, review results
of usability testing, fix broken links, respond to comments/questions, etc.
• Regularly evaluate content for usefulness and applicability to targeted audiences.
• Read the Step-by-Step Guide for EICs Developing and Maintaining Web Content.
• See Roles and Responsibilities of One EPA Web Editors‐in‐Chief for more information.
Requirements of a Microsite
Required Content Elements
The following content elements are required unless the top tasks identified don't support including them. They
must be linked from the homepage, but the location of the links or content is flexible.
Learn about [Topic Name]
• This is basic information about a topic.
• It should summarize:
o What is the issue?
o Why should you care?
o What is EPA doing about it? (e.g., regulations, partnerships, outreach, enforcement, research,
grants)
o What can you (as a person or as an organization) do about it?
• “What you can do” and “What EPA is doing” content must be linked from the homepage.
• “Learn about” content should not be presented in a question-and-answer format and should not
duplicate FAQ content.
Science and Technology Content
• A page, or part of a page, that provides current and accurate information on what EPA is doing
scientifically.
• Using the phrase "science and technology" is recommended when appropriate. It's acceptable to use
other phrases to describe your science and technology content.
Laws and Regulations Content
• Content about laws and regulations must follow the guidelines set forth in “Creating and Editing
Regulation Pages” and should follow the Regulatory Template Web Standard.
• Laws and Regulations content specific to a topic should be housed in a microsite rather than in EPA's
Laws and Regulations web area.
Geographical Content
• If a microsite is about a particular geographic area (Puget Sound; Libby, MT; Gowanus Canal; Atlanta),
all geographic content should reside there. For example, information about lead in drinking water in the
District of Columbia should reside in the D.C. web area rather than the lead web area or drinking water
web area.
o Exception: content currently stored in a major database (for example, a database of all National
Priority List (NPL) sites) should remain in that database, and you should link to it.
• Integrate with existing geographically-built databases, such as My Environment or Cleanups in My
Community.
o Consider working with the EIC of the My Environment/Envirofacts web area to create queries
specific to the microsite topic.
Contact Us Links
• Contact us links ( at the top and bottom of webpages) go to a page with a contact form. The WebCMS
automatically generates a Contact Us page, although you will need to customize it. See Web Standard:
Contact Us Page.
o You should respond to inquiries within ten business days, and you are strongly encouraged to
set up a confirmation email to acknowledge that the question has been received. Learn how to
set up a confirmation email.
Look and Feel/Navigation
Homepages
• Templates: Homepages’ look and feel must be selected from basic layouts (up to four columns wide)
available in the WebCMS.
• Banners:
o Should be 2048w x 820h pixels. See Image Guidance.
o Use only GIF (.gif), JPEG (.jpg, .jpeg), or PNG (.png) formats.
o Rotating banners are permitted but note that news-related banners are difficult to maintain.
• Homepage content area:
o Do not make your homepage look like a resource directory with a banner on top of it. Do not use
the RD layout on a MS homepage.
o Must have introductory text fewer than 50 words.
o Generally, links in the content area on the home page should go to other information in the
same microsite, rather than to other EPA sites or to external content. External links and links to
other EPA sites should be displayed in right-side boxes or on internal pages.
o Limit dropdown menus in the content area. The global navigation on the top of each page will be
in dropdowns, so additional dropdowns may be overwhelming for visitors.
Left Sidebar Menu
• All webpages in a microsite web area must have a left sidebar menu.
• The WebCMS displays the same left sidebar menu on all pages of the microsite.
• Do not use navigation menus other than the left sidebar. Do not use right-side boxes for navigation
menus.
• All linked text in the sidebar must point to other pages in the same microsite. There are two exceptions:
o A link to a parent/umbrella site may be included. For example, a site on Pesticides Registration
can include a link to Pesticides.
o A link with the link text “Frequent Questions” can go to an appropriate place in the Frequent
Questions Database or can link to your Frequent Questions landing page.
• Left sidebars should include the following links, unless one or more of these types of content is not
appropriate for the identified top audiences:
o Learn about [Topic Name]
o Science and Technology
o Laws and Regulations
o Frequent Questions
o What EPA is Doing
o What You Can Do
• The sidebar should not contain:
o Newsroom
o Recent Additions
o Contact Us, or a term that could be confused with a link to the Contact Us page, like "Contacts"
Other languages
• Do not create webpages in languages other than English.
o If you need to create new content in Spanish, please contact Lina Younes in the Office of Web
Communications. Lina manages espanol.epa.gov.
o If you need to create new web content in languages other than English or Spanish,
please contact Lina Younes. Lina coordinates foreign language content other than Spanish.
Related Information
• Creating a Microsite homepage
• Should Your OneEPA Web Content be a Resource Directory or a
Microsite?
• Web Council Members
• WebCMS Training
• EPA Web Training Classes
Web Standard: New Icon
Definition
A "New!" icon is a small text-based “icon” that indicates a piece of content is new. How the new icon
appears on EPA.gov.
Content Requirements
Using a "New!" icon is optional. If you use one:
• Limit use of "New" icons on a page.
• Do not write text that redundantly suggests newness, e.g., "EPA today initiated ..."
o Your text must be timeless.
• Note: the "New" icon will not appear on browsers that do not have JavaScript enabled. Do not provide a
HTML alternate; this is not critical content.
• The "New!" “icon” will remain visible for 30 days from the date you used.
• The new icon cannot be used for more than 30 days.
About this Standard
Original effective date: 09/28/2005
Last approved on: 05/13/2020
Web Council review by: 05/13/2023 (or earlier if deemed necessary)
Related Information
•
Adding the New! Icon
Web Standard: On this Page/Table of Contents
Definition
"On this Page" is a table of contents, or a list of links, most often found at the top of the page, that links to
information found further down the page.
Content Requirements
• Use a table of contents on pages that contain more than one main section, and that are more than two
screenfuls long.
o As an introduction, before the contents list, write a short blurb for the page (one sentence may be
sufficient) unless the information presented on the page is completely intuitive.
o After the introduction, create a bulleted table of contents with links to each heading. If the page presents
questions and answers, the links will be to the questions.
• If closely related information on this topic is available on other pages, a second “On Other Pages” bulleted
table of contents may also be displayed (see Example 2 below).
• A horizontal rule is added after the table of contents.
Examples
Example 1
Related Information
• Creating an On this Page Table of Contents
Example 2
About this Standard
Original effective date: 09/12/2012
Last approved on: 03/10/2021
Web Council review by: 03/10/2024 (or earlier if deemed necessary)
Web Standard: Page Not Found (404 Error)
Definition
A page that notifies a visitor they have found a broken link.
Content Requirements
• In the WebCMS, there will be a single 404 error page for the Agency.
o This error page applies to https://www.epa.gov/ and www3.epa.gov.
• Applications need a 404 error page.
o Applications should include on their page not found content:
Page title that shows that a person is on a Page not Found page.
A way to find information in the application (for example, a search box for the application).
A link to the application homepage or application search page.
A link to the EPA Homepage in the body of the page.
You can add more information if you think it helps the customers find information.
Example
https://www.epa.gov/compliance/404demo
About this Standard
Original effective date: 01/01/2004
Last approved on: 03/11/2020
Web Council review by: 03/11/2023 (or earlier if deemed necessary)
Web Standard: PDF Accessibility Requirements
Definitions
PDF file: a document saved in the Portable Document Format using Adobe Acrobat (or another such PDF
creator). Typically, PDF files are opened using Adobe Reader. Content created and maintained in the
WebCMS as a webpage is more accessible than a PDF file.
Internal file metadata: the metadata (Title, Author, Subject, Keywords, and Language Designation) that’s
saved with the PDF file itself. Complete file metadata information optimizes search capabilities. e.g. title,
subject key words increasing the chances of a higher search rank.
Content Requirements
• Content should be created in HTML or PDF, not both. HTML is preferred for accessibility, especially for
documents less than 5 pages.
• When linking to a PDF, follow the PDF Linking Standard.
• EPA, like all federal agencies, is required to meet Section 508 requirements.
o Make the PDF content accessible and web ready BEFORE posting.
o In the case of an urgent posting, the uploaded non-compliant PDF must later be replaced with an
accessible and web ready PDF.
o All PDFs created, altered, or updated after 1998 must meet these requirements.
• In order for PDFs to be 508 compliant and accessible, the following minimum requirements must be met:
o Make sure your PDF text is machine readable - Do not post image-only PDF.
Whenever possible, avoid using a digitally signed PDF (locked file). Use /s/ or "original signed by" as
a way to indicate a hard copy signature is on file. Ex: /s/ Charles Bert or Original signed by Charles
Bert.
o The PDF must be tagged to ensure accessibility. Tagging a PDF establishes logical reading order and
structure. Learn more about tagging PDFs.
Alt text is required for images. Alt text for charts, graphs, and other more complex images must fully
describe the information displayed.
o Internal file metadata is required.
To add internal file metadata to the PDF file, follow the metadata directions and complete these fields
in the Document Properties description tab:
• Title
• Author
• Subject
Set the Language designation. This enables screen readers to use the appropriate language.
Select Document Title from the “Show” drop-down box in the Initial View tab. If File Name is selected,
browsers may show the filename instead of the document title.
• In very specific circumstances the minimum requirements cannot be met (e.g., too technical, mathematical
formulas, maps or other images). In rare cases like this, the PDF should include contact information for
users in need of accommodation.
o Contact information should be added as a text box in the PDF, on the front cover or first page of the
PDF document. Include the full URL or email address so it is visible on the page and do not add a
hyperlink. This should be first in the document's reading order.
Example: For assistance in accessing this document, please contact OWC@epa.gov.
o A program office phone number or shared email address must be listed in the contact information.
It is highly recommended to use a shared mailbox instead of an individual EPA employee's email
address. Possible contacts include your library, public information center, public affairs office or
public questions/contact us shared email account. Whatever information you provide, the document
should be traceable back to the program office which produced it.
About this Standard
Original effective date: 07/10/2013
Last approved on: 12/09/2020
Web Council review by: 12/09/2023 (or earlier if deemed necessary)
Related Information
• PDF Metadata Directions
• How to Create a Web-Ready PDF
• Breaking Large PDFs Into Chunks
• Web Standard: PDF Links
• Section 508 Accessibility
• 508 Compliance Guide for Existing PDFs
Other Resources
• GSA's Create Accessible Digital Products
• HHS Accessibility checklists
Web Standard: PDF Links
Definitions
• A PDF is a document in Adobe Portable Document Format (PDF); the filename extension is .pdf
• The Drupal WebCMS adds the PDF link standard requirements (PDF disclaimer, PDF in the link, file size
an
d number of pages after the link) automatically on the document page.
• The EPA PDF linking standard applies to all PDF links including PDF links leaving the EPA.gov site.
Content Requirements
• When linking to PDFs, follow this format: <link>PDF Title (PDF)</link> (xx pp, yy K, About PDF)
• Provide a link to EPA’s “About PDF” page (https://www.epa.gov/home/pdf-files) on any Web page that links
to PDFs. There are two ways to do this:
o Use the PDF disclaimer box:
at the top of a page that includes many PDFs, right before a paragraph or list of PDFs, or
immediately before the first reference to a PDF
o Use the inline disclaimer when the long version is problematic, or where you have only a few PDFs
linked
Format: inline disclaimer: <link>PDF Title (PDF)</link>
(xx pp, yy K, About PDF)
• The "About PDF" link is only required once per page.
• Include the title of the document and the acronym “PDF” in parentheses in the link text. Make sure it's a good
des
criptive title for the PDF you're linking to
• After the link, show the PDF file information in parentheses, listing the number of pages and file size of the
P
DF as unlinked text, separated by commas. (xx pp, yy K,
About PDF)
o For the number of pages, use "1 pg" for a single page. For multiple pages, use "XX pp" with a space
between the number and "pp".
o For file size, use "K" for files smaller than 1000 K and "MB" for files larger than 1000 K. For MB, use at
most one decimal place. Put a space between the number and "K" or "MB."
o You may code the file information in parentheses to appear in a smaller font by using the File Info
disclaimer (class="fileinfo").
• Do not add the file type of PDF, the file size, or the number of pages when linking to a document page. The
doc
ument page is not a PDF file.
Examples:
• Correct link to a PDF: Care For Your Air: A Guide to Indoor Air Quality (PDF) (3 pp, 2 MB, About PDF)
• Correct link to a document page: EPA Region 8 Certified Drinking Water Laboratories: Wyoming / Tribal
Public Water Systems
About this Standard
Original effective date: 07/12/2006
Last approved on: 06/10/2020
Web Council review by: 06/10/2023 (or earlier if deemed necessary)
Section 508
PDFs are required by law to meet Section 508 accessibility requirements. Occasionally, a PDF may not meet those
requirements (e.g., too technical, mathematical formulas, maps or other images). In rare cases like this, the PDF
can be accompanied by contact information for users in need of accommodation.
• If you are posting a non-accessible (not 508 compliant) PDF and you are not posting the same content in
some other accessible format (e.g. HTML or text), provide contact information. (If you include an email
address, follow the EPA standard for linking to email addresses.)
• You may provide contact information in the same box or paragraph as the long disclaimer.
• Contact information is a phone number or an email address where a person could get help with a
document, primarily for purposes of accessibility.
• Possible contacts include your library, public information center, public affairs office or the person who
created the document. Whatever information you provide, the document should be traceable back to the
program office which produced it.
Related Links
• Web Standard: PDF - When to Use, Add Metadata, PDF sections
• WebCMS WYSIWYG editor
Web Standard: Linking to Related Content via
Pop-ups, Overlays, New Browser Tabs/Windows and
Same Browser Tabs/Windows
This standard was previously titled "Pop-ups and New Browser Windows."
Definitions
• Closely related content is content that is intrinsically connected to a subset of content in the existing
window. For example,
o A definition is closely related to the word being defined
o A description is closely related to the name of a process or technology
o An answer key is closely related to a set of quiz questions
o A larger version of an image is closely related to a smaller version of the same image.
o A video is closely related to a still image of that video
o An application is closely related to a description of that application, and to instructions for that
application.
o Location attributes are closely related to the location (point, line or polygon) on a map
• A pop-up is a window, smaller than the full screen, intended to supplement the primary browser window.
• An overlay is a colorbox, lightbox, or other modal box, a window that requires you to do something in it
(including closing it) before you can return to the main window, overlaid on top of the primary browser
window.
• New browser windows or tabs are typically the same size as the original window, and usually have their
own stand-alone information.
Content Requirements
• Do not use pop-ups, overlays, new windows or browser tabs unless the content they display is closely
related to the content in the existing window (see the definition of “closely related content” above).
• Include text identifiers. When displaying closely related content, if the content opens in a pop-up, overlay,
new window or tab, use text identifiers after or nearby the link to warn your visitors that clicking on the
particular link(s) will result in a pop-up, or colorbox, new window or tab opening.
o Exceptions:
Locations on web maps and map applications that, when clicked, result in a pop-up, overlay, or
similar feature, do not need to include text identifiers.
Text to which the "Add Definitions" feature is applied does not need to include a text identifier.
• target="_blank" is a bad security practice. If you must force a new tab/window, also include
rel="noopener noreferrer" to prevent tab hijacking.
Examples
• Sample text identifiers:
o "(link will open in a new browser tab or window)"
o "Note that all links below open in pop-ups."
• View:
o How using the code <a href=”URL of closely related content” target=”_blank” rel="noopener noreferrer">
works to open a new window or tab (as selected by each visitor in his or her browser preferences). Note
that clicking on this example will result in the Web Guide homepage opening in a new window or tab.
o How colorboxes look, using the directions on the Javascript: Colorbox page.
o What visitors see when the Add Definitions feature is used for the term "gamma spectroscopy": gamma
spectroscopy (when the linked term is clicked).
For overlays, see: Style Guide: Colorbox
About this Standard
Original effective date: 09/12/2012
Last approved on: 02/12/2020
Web Council review by: 02/12/2023 (or earlier if deemed necessary)
Web Standard: Regulatory Template
Creating an EPA “Rule” or “Regulation”
On this page:
• Template Elements for “Rule” or “Regulation”
o Rule Title
o Rule Summary
o Rule History
o Additional Resources
o Compliance
o Basic Information [box]
• Standard Dos and Don’ts for Rule-Related Web Content
Template Elements for “Rule” or “Regulation” Pages
The following information should be included on your regulation (final rule) web page. This template should be
used for any final rule published in the Federal Register (FR), or a part of the Code of Federal Regulations
(CFR) that contains several final FR rulemakings. Further instruction about each subheading area and box is
listed below. If you choose to follow this template for a rule that is in development but that is not final, or a
Notice of Proposed Rulemaking (NPRM), some content areas may not apply or may differ, but should be
updated when the proposal is promulgated as a final rule. Items marked with an asterisk [*] are required, but it
is recommended that pages include all sections where information is available.
Rule Title*:
It is helpful if you consistently use the same “Rule Title” on this web page, your Federal Register final rule
document, and other documents about the rule during its development.
Rule Summary*:
Use this area to briefly state the purpose of the rule. Decide whether you wish to link to either the final rule that
was published in the Federal Register or to the CFR section that the rule modifies. Keep in mind that the CFR
is updated annually, so linking to a specific section may be dated when the CFR is updated. A suggested word
limit for your rule summary section is 150-200 words.
How To Use the Rulemaking Template
• View the page on creating and editing the “regulation” page type
Rule History:
Use this area to include history or background of rule, the rule proposal, etc.
• Where possible, if you are seeking public comment, link to Regulations.gov when posting a Notice of
Proposed Rulemaking (NPRM) or similar document that was published in the Federal Register. Each
document posted in Regulations.gov has a unique URL within Regulations.gov.
Additional Resources:
Use this area to list resources or to link to fact sheets, guidance documents, implementation tools, outreach
materials, etc. This area is flexible to make what you choose of it.
Compliance:
Discuss information that the regulated community can use to aid their compliance efforts.
• Consider identifying the industries or sectors affected, with their NAICS codes, both in your content and your
metadata.
• Clearly outline what the regulated community must do to comply with new Rule:
o what they have to do (compliance) and
o what happens if they don't (enforcement).
• Provide additional information for partnerships or initiatives for businesses that want to go the extra mile.
• Consult with the OECA workgroup representative from your rulemaking workgroup to develop appropriate
content for this area.
Basic Information [box]
The Basic Information box is built up of five components, listed below. If you do not wish to use any of the
suggested citations, you may omit it from this box. Hyperlinks to the source data for the first four items below
are recommended. You can add more than one of each component (e.g., more than one FR Citation.)
Legal Authority: The standard format is [## U.S.C. ####], e.g. 42 U.S.C. 5859 or 33 U.S.C. 1231
• For more information on correctly displaying statutory authority, see the Office of Federal Register’s
Document Drafting Handbook, section 2.11
• Carefully consider whether to hyperlink to a specific section of the statute, and see further Dos and Don’ts
guidance below. The generic US Code link is https://www.govinfo.gov/app/collection/uscode.
• You may add information about Legal Authority that’s not from the U.S. Code.
FR Citation: The standard format is [## FR ####] e.g., 75 FR 68049 or 67 FR 593
• When posting signed rules or future Federal Register documents on the web, follow the guidance in Posting
Federal Register Documents on the Internet (.docx).
CFR Citation: The standard format is [40 CFR Part ####] e.g., 40 CFR Part 122 or 40 CFR Parts 79, 80, 85,
86, 600, 1066
• Carefully consider whether to hyperlink to a specific part of the CFR (these links change annually and would
require frequent maintenance), and see further Dos and Don’ts guidance below. The generic CFR link is
https://www.govinfo.gov/app/collection/cfr.
Docket Number: The standard format is [EPA-[HQ or R##]-[Program Office*XXXXX]-20XX-XXXX], e.g., EPA-
HQ-OW-2010–0606 or EPA-R02-OAR-2012-0889.
Effective Date: Please use format MM/DD/YYYY, e.g. 08/12/2013 or 11/04/1999, including when multiple
effective dates apply.
[Note: If the content on your web page relates to a rulemaking proposal, you may wish to include the Comment
Period End Date: (format MM/DD/YYYY).]
Standard Dos and Don’ts for Rule-Related Web Content
• Do link to the official versions of documents published in the Federal Register, US Code, Code of Federal
Regulations (CFR), dockets, etc. Official versions come from the Government Printing Office (GPO) or
Regulations.gov. Do not post your own PDF versions, unless a document is not available digitally from GPO
or Regs.gov.
• Do not provide links to https://www.epa.gov/fedrgstr/ which was discontinued in fall 2014.
• Do not provide links to https://www.federalregister.gov/. The legal disclaimer at this site states that its
content is “not an official, legal edition of the FR.” For this reason, GPO is the source data that should always
be used for Regulation or Rule links.
• Do not link to non-government sites, such as Cornell's U.S. Code site, when referring to U.S. law (statute or
code) or regulation (rule or rulemaking).
• Do follow the guidance in Posting Federal Register Documents on the Internet (.docx) when posting
any signed Federal Register documents on the web, particularly prior to their publication in the FR.
• Do follow EPA web standards for external links to the Federal Register, US Code, Code of Federal
Regulations (CFR), or Regs.gov dockets. If you link to any website that is not hosted by the government,
follow EPA’s procedures for External Site Links.
• Do not recreate content from the EPA-wide Laws and Regulations channel. Any legal or regulatory
summaries you write should be topically oriented; for example: "The Clean Water Act and Puget Sound," not
just "The Clean Water Act" (which is already summarized).
• Do review and include current agency instructions on appropriate metadata for your page.
• Do let the EPA Channels Editor-in-Chief (currently Judy Dew in OMS), and the Laws and Regulations Editor
(currently Caryn Muellerleile in OP) know when you are creating "Laws and Regulations" content, so they
can coordinate updating links and content on other channels and web areas.
About this Standard
Original effective date: 01/05/2015
Last approved on: 02/12/2020
Web Council review by: 02/12/2023 (or earlier if deemed necessary)
EPA Resource Directory Format
This document explains how to create resource directories so that they comply with EPA Web standards, One
EPA Web guidance, and best web practices. Be sure you have first considered whether Resource Directory or
Microsite is most appropriate for your content.
On this page:
• Overview
o Definition; Structure
o Resource Directory Goals
o Principles
• Resource Directory Development
o Editor-in-Chief Responsibilities
• Requirements of a Resource Directory
o General Requirements
o Hub Page Requirements
o Spoke Page Requirements
Overview
Definition; Structure
The resource directory format organizes topics using a simple "hub and spoke" model. Topics presented in this
format have a single navigation page (a hub homepage) that links to the most important related content (spoke
webpages), often including EPA content outside the web area. Spoke pages link back to the hub homepage
(this link is above the page title and is added by the WebCMS in the template). Apart from the links between
the hub homepage and each spoke page, resource directories include little or no internal navigation.
Resource Directory Goals
• Provide a main entry point to a given topic.
• Elevate the most relevant and appropriate content for your audiences to the top level.
• Provide updated and relevant content.
Principles
• The Editor‐in‐chief for the RD web area is responsible for keeping the resource directory up to date,
reviewing metadata, managing and reviewing content, fixing broken links, responding to
comments/questions, etc.
• Not every topic warrants the creation of a resource directory. Individual offices and divisions, both at
headquarters and in the Regions, are expected to work with their Communications Directors, Public
Affairs Directors, and Web Council representatives to determine which topics would be best supported
by the creation of a RD.
• Resource directories will not link to every piece of related web content, only to content most
relevant for the targeted audiences.
• The hub homepage for a particular topic links only to information about subtopics. The exception is that
a hub page can contain a Related Topics section/box. This "Related Topics" section/box can include
links to related resources outside of EPA (please follow the external linking procedure)
• Spoke pages contain very specific information about the RD topic and should be limited in scope. Do
not link to broader content.
Resource Directory Development
Before you request a Resource Directory, you will need to complete the following tasks:
• Identify the purpose for the resource directory.
• Identify one to three top audiences to properly focus content selection.
• Choose content that most directly supports the audiences' top tasks. Note: link to only the most
relevant information, not all information.
• Determine whether the Office of Public Affairs (OPA) AA will need to review (contact Angela Shogren)
and/or whether any special approvals are necessary for high-profile content.
Editor in Chief Responsibilities
• Ensure that metadata exists for all content, no matter the file type, and that it is appropriate. Regularly
review and update the hub homepage, spoke pages, metadata, review results of usability testing, fix
broken links, respond to comments/questions, etc.
• Read the Step-by-Step Guide for EICs Developing and Maintaining Web Content.
• See Roles and Responsibilities of OneEPA Web Editors‐in‐Chief for more information.
Requirements of a Resource Directory
General Requirements
Resource directory hub homepages and all spoke pages are created and maintained in the WebCMS. Local
styles are not permitted. See the EPA Web Standard: Local Styles.
Hub Page Requirements
Look and Feel
The hub page uses the RD home page layout in the WebCMS. When you request that a new website be
created in the WebCMS, if you indicate that you are creating a Resource Directory, the hub page will be
created in the RD homepage layout. Do not use other layouts or modify the RD homepage layout. Only use the
RD homepage layout on web area homepages.
Elements of a Hub Page
• At top, an optional brief text description of the topic. If you include this description, keep it to 50 words
or less. No hero/banner images or other features should be included in this section. Program logos may
be displayed to the right side of the hub page intro text.
• 2 – 6 content sections. These content sections should address top questions and top tasks of your key
audience. If you think your page will have only one content section, please contact Angela Shogren,
who can help you consider the best way to structure your content. Each section includes:
o Title (H2 for heading size). All major words should be capitalized.
o Must have introductory text fewer than 50 words.
o Photo (640w x 200h pixels minimum).
Follow the standards and processes described in the Image Guidance.
Photos that contain text should not be used.
Program logos should not be used in these sections.
o Relevant links:
Link text should clearly explain where the link is going. See more information about good
link text in the Writing for the Web Standard.
Each content section should include no more than five links.
If you find that you have more than five links in a section, replace two or more of
them with a link to a webpage which includes links to multiple pages. Example:
on Pest Control and Pesticide Safety for Consumers, the "Controlling ants, bed
bugs, mosquitoes and other pests" link takes visitors to the landing page Got
Pests? Control Them Safely page.
• Contact us links (top and bottom). These links go to a page with a contact form. The WebCMS
automatically generates a Contact Us page, although you will need to customize it. See Web Standard:
Contact Us Page.
o You should respond to inquiries within ten business days, and you are strongly encouraged to
set up a confirmation email to acknowledge that the question has been received. Learn how to
set up a confirmation email.
Optional Elements for a Hub Homepage
• Maps can be used to display local or regional information in either the main body or the right-side
column.
• List of links to related topics. Three to six links is optimal. This section goes in the right-side column.
Spoke Page Requirements
Some of the spoke pages you link to might be existing pages you own, or pages you link to might be pages
owned by other content owners. Do not duplicate content that already exists. Please work with content owners
or the EIC of the web area if you find content that should be updated. If you have questions or need
assistance, please contact your Web Council Member.
Look and Feel
• Spoke pages link at upper left (above the page name) to all hubs that link to them. Examples of spoke pages
with multiple hub links:
o Nutrients Management Research page
o Report Spills and Environmental Violations page
o Confidential Financial Disclosure Form for Special Government Employees (EPA Form 3110-48)
Selection of New Content, Including Links
• RDs must include a page of general information about the topic ("Basic Information about XXX” or “Learn
about XXXX”); the hub page must link to that page.
• Do not use sidebars, local area footers or other additional local navigation to create navigation among spoke
pages.
• Follow writing for the web principles and EPA web standards.
• Content about laws and regulations must follow the guidelines set forth in Creating and Editing Regulation
Pages and should follow the Regulatory Template Web Standard.
• Limit inline links (i.e., links in the middle of a paragraph). Most links should be below or to the right of the
related content so that:
o You can provide your viewers with more context.
o Viewers and screen readers can scan linked content more easily.
o Link text is descriptive and accessible in plain language.
• Other languages:
o Do not create new spoke pages in languages other than English.
If you need to create new content in Spanish, please contact Lina Younes in the Office of Web
Communications. Lina manages espanol.epa.gov.
If you need to create new web content in languages other than English or Spanish, please contact
Lina Younes. Lina coordinates foreign language content other than Spanish.
Web Standard: Sidebar
Definitions
The sidebar navigation is the vertical list of links in the left panel of some webpages. Microsite webpages are
required to have sidebar navigation, except the homepage and pages using the wide template.
Content Requirements
• The sidebar is part of the EPA look and feel. Do not modify it.
• The left sidebar must be identical on all webpages within a microsite web area.
• Use title case (initial capital letters) for all major words. Do not use all caps.
• Use standard language terms on the sidebar menu to link to content:
o Frequent Questions. Do not use the acronym, “FAQ”, "Frequently Asked Questions",
"Common Questions", "Key Questions" or any term other than "Frequent Questions".
o Newsroom. Links only to the Newsroom or News Release web areas. Do not use “What’s New
in [topic name]).”
o Publications. Links to EPA-produced publications.
• Do not use acronyms unless
o the acronym is more familiar than the phrase the acronym stands for (e.g., "PCBs" is a more
familiar term than "polychlorinated biphenyls") or
o the acronym is explained in the area name at the top of the page (Persistent Bioaccumulative
and Toxic (PBT) Chemical Program).
• All text used on the left sidebar navigation must be an active link.
• If you have a basic information or Learn About… webpage in your web area, you must include it in the
sidebar navigation.
• Use the page name for the sidebar menu.
• Keep navigation simple.
o The left sidebar navigation can be the main navigation for the web area. If you decide to include
additional navigation, put the links on the top of the page in a pipeline list. Do not use right‐side
boxes for navigation menus. Consider including a right side “Related Info” box on individual
pages when you wish to link to related content.
o If a section of content has a substantial hierarchy, consider creating a web area for it.
• The sidebar navigation should not contain entries which link to:
o Search pages or search boxes
o PDFs or other web files (Excel, Word, etc.)
o Outside web areas, except to a homepage of a parent web area or to the relevant glossary page
in Terminology Services
o www3.epa.gov outdated content
o Snapshots of www.epa.gov
o Graphics
o The web area’s "Contact Us" page
NOTE: You may link to lists of program contacts. Label these links with specific
descriptions like "State Contacts" as opposed to "Contacts" or "Contact Us." If you are
soliciting comments, then use sidebar language like "Send Comments" or "Comment on
the Rule" instead of "Contact Us."
About this Standard
Original effective date: 09/28/2005
Last approved on: 06/10/2020
Web Council review by: 06/10/2023 (or earlier if deemed necessary)
Related Information
• One EPA Web Microsite Format
• Creating Web Area Sidebar Navigation in the WebCMS
• One EPA Web: Purpose, Audiences, Top Tasks Example
Web Standard: Standard Web Formats and Proprietary
File Formats
Definitions
The EPA standard formats for publishing information on the Web are HTML and PDF. Many programs create
file formats with unique file extensions (e.g.; .doc, .pptx, .zip). Proprietary formats (e.g.; .docx, .xls, .ppt, .exe)
should be used only when necessary e.g., when providing forms or other documents that users may need to
edit or files for installing software. These files are rarely updated and are more likely to become redundant,
outdated or trivial. Consider carefully before publishing these types of files.
Content Requirements
• Scan files for viruses before loading.
• When linking to other file formats, follow this format: <link>Document Title (DOCX)</link>
• You may only use file types for applications which EPA has a Terms of Service agreement. Terms of
Service are negotiated at the Agency or federal level.
About this Standard
Original effective date: 09/12/2012
Last approved on: 08/12/2020
Web Council review by: 08/12/2023 (or earlier if deemed necessary)
Related Information
• WebCMS Training: Adding Files to Pages
• Free Viewers and Readers to Read and Print EPA Information
Add proprietary format disclaimer and link to the EPA formats page.
• Option 1: Add a Multipurpose box to the page that contains: You
may need additional software to view some of the links on this page.
See EPA’s Free Viewers and Readers page.
• Option 2: Inline disclaimer (e.g.): Document Title (DOCX) Free
Viewers
Web Standard: StoryMaps
Definition
StoryMaps, which include Esri StoryMaps and ArcGIS StoryMaps, are map-centric data presentation tools.
StoryMaps allow developers to blend multiple forms of media with map products to more effectively
communicate environmental data.
Content Requirements
• Approval is required for StoryMaps at two stages. The first approval must take place before work
begins (concept stage), and a second approval is needed before the StoryMap is made publicly
available.
o The first review takes place at the concept stage before work begins on the StoryMap. Before
presenting your concept, consider why StoryMaps are critical to your content goals and cannot
be met by a WebCMS-based alternative. Learn more about identifying a concept and submitting
your concept for review.
o The second is the final review, which occurs when the StoryMap is final (or near-final), before
the StoryMap becomes publicly available. Learn more about final approval of your StoryMap.
• StoryMaps must:
o Be hosted within the EPA GeoPlatform Online (GPO). Data used by the StoryMap must also be
hosted within an EPA system.
o Include a substantive geographic component that is described with relevant narrative, graphics,
and/or other multimedia content.
o Substantially enhance data presentation in a narrative format.
o Describe case studies, success stories, geospatial trainings, and/or other similar stories or
topics in a manner that adheres to Agency best practices and standards
o Adhere to EPA's Writing for the Web Standard.
o Adhere to the Data Visualization Accessibility Procedure
o Include the required elements (including necessary Section 508 compliance and accessibility
requirements) listed on the StoryMap Guidance and Publication Requirements.
o Include the agency Web analytics code to ensure that it is compliant with the Digital Analytics
Program (DAP).
o Follow the EPA Style Guide for Documenting GeoPlatform Online Content Items.
Related Information
• StoryMap Guidance and Resources
• EPA GeoPlatform Online
• Web Standard: Maps
• Web Standard: Writing for the Web
About this Standard
Original effective date: 10/14/2020
Last approved on: 07/13/2022
Web Council review by: 07/13/2025 (or earlier if deemed necessary)
Web Standard: Thank You Page
Definition
A page that users get when they submit a form that thanks them for their input or request.
Content Requirements
• For every form, there should be a follow-up page thanking the reader for submitting the information and
offering links to continue browsing.
• At a minimum, in the main body of the page, offer a link to the area’s homepage.
• In the WebCMS, this page is automatically created with the Contact Us Form. You can modify if needed.
Example
A form-generated Thank You page in Drupal WebCMS
About this Standard
Original effective date: 01/01/2004
Last approved on: 02/09/2022
Web Council review by: 02/09/2025 (or earlier if deemed necessary)
Related Information
WebCMS Directions for editing thank you page.
Web Standard: Videos
EPA Videos
• No videos will be uploaded to Drupal WebCMS; all videos will be posted on EPA's YouTube channel. This
includes webinars, trainings, tutorials and demos. Questions? Contact Jini Ryan in the Office of
Multimedia. Videos may also be posted on EPA Facebook accounts.
• For specific standards and guidance, see the links to the Office of Multimedia Video Standards and
Guidelines below.
• You may be interested in the YouTube Guidance, as well.
Linking to/Embedding External Videos
• No embedding: EPA's Office of General Counsel has concluded that embedding videos from third parties
into EPA’s website constitutes endorsement or preferential treatment. An employee who permits such
embedding could be violating the Standards of Ethical Conduct for Employees of the Executive Branch, 5
CFR Part 2635, specifically the misuse of position standards. EPA's YouTube channel is not considered a
third party.
• Linking: All links to external videos are subject to the same rules as any other external links. See the
External Site Links procedure for more information. All image maps must be responsive.
Office of Multimedia (OM) Video Standards and Guidelines
• OM home page
• Standards and guidelines page
Web Standard: Web Area Home Page
Definitions
The page that serves as the introduction to a web area, such as resource directory and microsite homepages.
Content Requirements
See the resource directory standard and microsite standard for their requirements.
• Resource Directory Format
• Microsite Format
All web area home pages must:
• Be written for the general public (for an 8th grade reading level).
• Have introductory text fewer than 50 words.
• primarily include links to related top task content.
o Follow EPA’s link text standard.
About this Standard
Original effective date: 01/01/2004
Last approved on: 07/08/2020
Web Council review by: 07/08/2023 (or earlier if deemed necessary)
Related Information
• One EPA Web Principles that Guide Content
Development
• Requesting a new web area
o Should Your One EPA Web Content be a
Resource Directory or a Microsite?
Web Standard: Web Area Name
Definition
The name of the web area, located at the top of the page, that briefly describes the topic of the Web area.
Content Requirements
• Must be unique. Please refer to the Web Plan(WebCMS Users only) before requesting a new web area.
• Reflects the topic of the web area, not the organization providing the information.
• Shows the scope of the information accurately, but as short as possible.
• Is used on all pages within a web area.
• Use geographical designations when needed.
o For example: San Francisco Bay Delta, Border2020 or New Bedford Harbor
• Use title case (initial capital letters); do not use all upper or lower case.
• Spell out web area names and include acronyms at the end (in parentheses). You can then use the acronym
in the page content and sidebars.
About this Standard
Original effective date: 03/28/2009
Last approved on: 06/08/2022
Web Council review by: 06/08/2025 (or earlier if deemed necessary)
Related Content
• Instructions to Complete the Web Area Request Form
• Form to request new web area
• Web Areas and Homepages
• To change a web area name, please coordinate
with OWC.
Web Standard: Web Area URLs
Definitions
• URLs are Universal Resource Locators, the address where a website lives.
• This standard refers to www.epa.gov only.
• The URLs will be in the form: https://www.epa.gov/web-area-name/page-title
• WebCMS automatically creates the URL based on the short name (defined after OWC approval when the
web area is created).
o A different URL (called a 'URL overwrite') can be created, if desired.
o Any name change requires approval by OWC.
Content Requirements
• Each web area can only have one URL.
o There will not be multiple URLs for the same web area.
• Use all lowercase letters. The URL will be changed automatically to lowercase if typed with any uppercase
letters.
o Using mixed- or uppercase causes issues for search engines, users, and analytics tracking.
• Use descriptive words. You want people to find the site using search.
Examples
• Water Research can be: (pick one)
o /water-research/
o /waterresearch/
o /h2oresearch/
• CAMEO (Computer-Aided Management of Emergency Operations) can be: (pick one)
o /computer-aided-management-emergency-operations/
o /cameo/
Related Information
• Web Area Request Form
• URLs and Aliases on www
About this Standard
Original effective date: 11/14/2012
Last approved on: 04/13/2022
Web Council review by: 04/13/2025 (or earlier if deemed necessary)
Web Standard: Web Forms
Definitions
Webforms are used to send questions or comments, register or submit registration information, or request
software. Contact Us forms are treated separately. See the Web Standard: Contact Us Page.
Content Requirements
• Pages using Webforms must include an EPA email contact in case the form fails to work.
• Title the Webform appropriately, describing its purpose.
• Use title case (initial capital letters) for labels. Never use all caps.
• Reset/cancel buttons should not be used, as they make it too easy for visitors to reset the form, losing their
submission.
• If you request an email address or phone number in the Webform, be sure to use the appropriate field in
the Webform for validation
• Every Webform is required to return a confirmation message, aka a “thank you” page.
o You can customize the page but it’s not required.
About this Standard
Original effective date: 06/26/2011
Last approved on: 07/13/2022
Web Council review by: 07/13/2025 (or earlier if deemed necessary)
Related Information
•
Web Standard: Contact Us Page and Links
• WebCMS Create and Modify Forms
• Customizing the Thank You Page
Web Standard: Writing for the Web
Definitions
Writing for the web is using plain language with your audience in mind. Writing for the web is ensuring that
content is organized so that it is scannable on screen and answers your audience’s top tasks in a way that they
can understand. Headers and links are particularly important, as visitors rely on them when scanning the page.
Content Requirements
Write for Your Audiences
• Clearly define top audiences and top tasks for each page. Ensure that the content addresses the interests
and tasks for your top audiences. Learn how to define purpose, audience and top tasks when developing
web content.
Choose Words Carefully
• Use familiar words and short phrases, keeping your audience in mind.
• Avoid unexplained jargon.
• Capitalize only proper nouns.
• Follow standard rules of grammar and punctuation and EPA style guidelines. EPA follows the AP Stylebook
first, and the U.S. Government Printing Office Style Manual second.
• Write for an 8th-grade reading level on pages for non-technical audiences. SiteImprove report or Word can
tell you about the reading level of your content.
Learn how to access and use SiteImprove.
• Use short sentences and paragraphs. Aim for no more than 25 words per sentence, 70-75 words per
paragraph.
• Use active voice. Write “the board proposed the legislation” not “the regulation was proposed by the board.”
• Make text timeless (e.g. avoid words like recently or today, etc.).
• Do not create strings of more than three nouns or adjectives in a row (called compound adjectives, or noun
sandwiches). Examples of noun sandwiches:
o Everglades Construction Project Stormwater Treatment Area National Pollutant Discharge Elimination
System Watershed Permit and Supporting Documentation
o Five Year Review Community Training Module Speaker Notes
Define Your Content with a Unique Page Title
• Use unique page titles so search engines and visitors can easily find your content.
• Do not use words like More, Additional, Other, Related or Further at the start of page titles.
Design the Page for Scanning Using Headers
• Break up the webpage content into sections. Headings should accurately describe the content of each
section of the page.
o Follow the Headings Web standard.
• Use anchor links to help visitors navigate longer pages.
o Follow the On this Page/Table of Contents Web standard.
• Place the information that is most important to your audience at the beginning of the page and then provide
additional details further down.
• Use bulleted and/or numbered lists wherever you have a series, list, or sequence of three or more items or
points.
o If a list is more than 7 items, it is preferred to add subheadings to break up content for readability.
Write Clear and Descriptive Links
• Use link text that matches or closely matches the title of the page or page section it takes visitors to. Do not
use “More info” or “Learn more” as link text.
o Use descriptive terms to tell visitors what they’ll get before they click on a link (for example, report,
testimony, brochure, etc.).
• When linking to other file formats, follow this format: Document Title (DOCX), including the file extension in
the link (video or audio, PDF, DOC, etc.).
• Links outside of epa.gov must meet the requirements set out by the External Site Links procedure.
• Do not use the website address (URL) for link text unless you are trying to get your visitor to remember the
URL (AirNow.gov).
• Avoid using in-line links. Instead, add links below or beside the content as an additional, descriptive
sentence.
• When linking to related content, send visitors to the most specific, topically relevant webpage (and not a web
area homepage).
• Avoid linking to the same content more than once on a page. If you must, use the same descriptive, clear,
link text for both links.
• Do not use the same link text for different links on the same page.
Related EPA Information
• EPA Web Style Guide
• Successfully Preparing Your Content for OWC
Review
• AP Stylebook
About this Standard
Original effective date: 01/01/2004
Last approved on: 04/13/2022
Web Council review by: 04/13/2025 (or earlier if deemed necessary)
Related Information from Other
Sources
The following links exit the site
• Plainlanguage.gov
• Usability.gov: Writing for the Web
• U.S. Government Printing Office Style Manual
