REL_-_IES_Web_Standards.pdf

2/4/2016 Institute of Education Sciences (IES) https://members.nces.ed.gov/webstandards/ 1/28

Standards Updated in the last three months No recent updates.

Last revised: 07/11/2012 | Notes

User Role: User User: Erin Pollard

IES Guidelines, Standards and Procedures

The IES Technology team hosts a large number of public and private websites which include content, custom applications, databases and other specialized servers. Public websites include ies.ed.gov, nces.ed.gov, childstats.gov, ope.ed.gov and nationsreportcard.gov. IES standards exist to facilitate one or more of the following:

Manageability (readability, consistency, extensibility)

Standards and processes exist in order to allow IES Support to manage (maintain, troubleshoot, update) our hardware and software infrastructures effectively and efficiently as well as streamline the ongoing processes of updating website content, applications and databases and maintaining their corresponding networks and server hardware.

Security (application, network and data security)

Welldefined security standards help protect data and applications and keep networks, servers and websites secure and meet stringent government information security regulations. The IES Technology team includes a government Computer Security Officer (CSO).

Performance (response time, server load, minimize errors)

IES websites and applications must be able to cope with expected visitor volumes whilst remaining easily manageable by IES Support and extensible by developers in future iterations. Many highprofile publications and applications subject to media and/or political scrutiny are hosted by IES Technology.

User Experience (user interface, web standards, accessibility)

The user's browsing experience is important for website usability and all public government websites must also adhere to Section 508 requirements for accessibility.

Providing crossbrowser support and serving wellformed document types such as XHTML will also help ensure the website is correctly displayed for all users as well as appropriately indexable by search engines.

These standards are subject to change and are updated on a regular basis. If you have any questions and concerns regarding these standards or the policies therein, please contact IESWebSupport@ed.gov

1. Website Standards 2. Policies, Procedures and Resources 3. Application Guidelines

1.1 File and Directory Standards

1.1.1 Directory Structure Layout

1.1.2 File Naming Conventions

1.1.3 Website Default Document

1.1.4 Temporary Files

1.1.5 File Attributes

1.1.6 Supported File Types

1.2 HTML Composition

1.2.1 Cross Browser Compatibility

1.2.2 Screen Resolutions

1.2.3 HTML Editors

1.2.4 DOCTYPE and Encoding Declarations

1.2.5 Comments

1.2.6 Popup Windows

1.2.7 Frames

1.2.8 XHTML DOCTYPE Standards

1.2.9 Secure Sites

1.3 Section 508 and Style Guidelines

1.3.1 Section 508 Technical Standards

1.3.2 Section 508 Tests

1.3.3 ALT and TITLE attributes

1.3.4 Colors

1.3.5 Fonts

1.3.6 Style Sheets

1.3.7 Usability Testing

1.4 Content Composition

1.4.1 Header and Footer

1.4.2 External Links

1.4.3 Internal Links

1.4.4 Website Terminology

1.4.5 Images

1.4.6 Videos

1.4.7 Unicode

1.4.8 Linking to Staff Contact Information

1.5 Search Engine Optimization

1.5.1 Title Tags

1.5.2 Meta Tags

1.5.3 Top of the Page

1.5.4 Themes and Relationships for Web Pages

1.5.5 Popular Search Terms

1.5.6 Title / Meta Tag Example

1.5.7 Page Rendering

2.1 Environment

2.1.1 Systems Environment

2.1.2 Backups and Disaster Recovery

2.1.3 Passwords and ED Security Controls

2.1.4 Remote Access to IESDC

2.1.5 Server Addresses and Configuration

2.2 System Procedures

2.2.1 Kickoff Meetings

2.2.2 VPC (Virtual Private Cloud) Access and

Passwords

2.2.3 Access Requests

2.2.4 Web / Database Updates Requests

2.2.5 Renaming / Moving Files

2.2.6 Staff Directory

2.3 Policies

2.3.1 Survey Collections

2.3.2 Publications and Tables

2.3.3 Data File Specifications

2.3.4 PowerPoint Specifications

2.3.5 Excel Specifications

2.3.6 PDF Specifications

2.3.7 Home Page Data Snapshots

2.3.8 Data Products

2.4 SQL Server Policies and Procedures

2.4.1 Support / Developer Responsibilities

2.4.2 Connecting to Staging SQL Servers

2.4.3 Creating and Delivering New Databases

2.4.4 Updating Database Objects

2.4.5 Transfers Between Staging and Production

2.4.6 Database Permission Levels

2.4.7 Bulk Inserts for Loading Data

2.5 Contacts and Resources

2.5.1 IES Web Liaisons

2.5.2 NCES Web Publishers / Liaisons

2.5.3 Web Analytics

2.5.4 IES Web / Network Support

3.1 SQL Server Database Design

3.1.1 General Guidelines

3.1.2 SQL Naming Conventions

3.1.3 SQL CLR Stored Procedures (SQL Server 2005+)

3.2 SQL Server Database Access

3.2.1 ADO.NET 2.0+ Connection Strings

3.2.2 DSN Connection Strings

3.3 Application Coding Conventions

3.3.1 C# / VB.NET 2.0+

3.3.2 ASP.NET 2.0+

3.3.3 Classic ASP

3.3.4 JavaScript and JavaScript Libraries

3.4 Application Development Guidelines

3.4.1 C# / VB.NET 2.0+

3.4.2 ASP.NET 2.0+

3.4.3 Classic ASP

3.5 Website Components

3.5.1 Graphing Component Corda PopChart, Highwire

3.5.2 User File Uploads SoftArtisans FileUp

3.5.3 Search Engine Google Search Appliance

3.5.4 IES.Common.dll

3.6 State Management and Load Balancing

3.6.1 Cookies

3.6.2 Network Load Balancing

3.7 Application Deployment and Configuration

3.7.1 ASP.NET 2.0+ Deployment

3.7.2 ASP.NET 2.0+ Configuration (web.config)

3.8 Application Security

3.8.1 Input Validation

1. Website Standards

All website developers should be familiar with these general standards before beginning any work on IES/NCES websites. Additional standards in Section 3 apply to the many pages on the IES/NCES websites that are served by datadriven, dynamic web applications (written in classic ASP or ASP.NET 2.0/3.5).

1.1 File and Directory Standards

1.1.1 Directory Structure Layout

https://members.nces.ed.gov/supporttools/memberaccounts/viewmember.asp?id=erepollard&lasturl=%2fwebstandards%2fdefault.aspx mailto:ieswebsupport@ed.gov https://members.nces.ed.gov/webstandards/ 2/28

Last revised: 08/03/2009

Last revised before April 2009

Last revised before April 2009

Last revised before April 2009

Last revised: 08/19/2015 | Notes

In the interests of reducing maintenance and bringing about directory standardization to the IES/NCES website, individual program areas are directed to break down their web sections into a more manageable directory structure. At a minimum, separate folders must be provided for images, PDF files, data and include files. Any additional files requiring special access or handling should also be placed in their own subdirectory structure. Do not put any of these components inside the root and do not mix files within a subdirectory (e.g. PDFs with .asp pages). Additionally, the name NET should never be used as a folder name. It is used for other purposes in our environment and as such is a prohibited folder name. If your site does not follow this structure it will not be moved over to the production area. All DLLs need to be registered in the components directory through the Members site. The default naming convention is as follows:

1. images all GIF, JPG, PNG and SVG images.

2. PDF all PDF files

3. inc all classic ASP server side includes (note that include files must follow naming conventions).

4. css Cascading Style Sheet (*.css) files.

5. js JavaScript / JScript (*.js) files.

6. data all downloadable components. These should be further broken out by: xls for Excel, ppt for PowerPoint, and zip for zip files. Word and text files are not acceptable formats for the website with the exception of text files for record layout documentation.

7. dev old or unused files (these will never appear on the IES/NCES production website)

8. source or sourcecode used for source code repositories when deployments involve precompiled code

The directory structure listed above may be repeated as needed in any subdirectories or other applications. For applications sharing a common set of files (e.g. CSS files, icons, etc.), a higherlevel directory may be referenced (e.g. nces.ed.gov/css/ or /common/images/).

Any files or directories that are not referenced by our website should be deleted or placed in the dev directory. If you choose to use Interdev or FrontPage to create web pages, you will notice creation of several three letter directories preceded by an underscore such as _vti and _ctf. In addition to these, files such as vssver.scc, and _notes which are created by applications but not needed to run web pages will not be moved over to the IES/NCES production web server and must be deleted from the Staging server before a request will be actioned.

Files and folders with the following extensions must never be used in production in any circumstances:

dev or any variation of development old bak, or any variation of backup test copy notes ftp

If any of these are used they must remain in development. Requests that include such files intermingled with legitimate files will be rejected.

Only necessary files should exist in your website's directories. Do NOT leave extraneous files or directories in your website. This includes temporary files and source control marker files.

Top of Page | Contents | 1.1 File and Directory Standards | View this Standard Only

1.1.2 File Naming Conventions

Keep all filenames in lower case. Make your filenames intuitive to the people who will be seeing them ("orgchart2000" rather than "oc2k") this will help make your information easy to search for and find. Try to be descriptive in your file name, but not verbose. One word names are always best, but useless when cryptic.

Most special characters are not supported in file names for the web on our servers. Web names (URLs) should be alphanumeric (letters and numbers). Examples of Special Characters not supported (this is not a complete list) include: (*) asterisks, (?) question marks, (!) exclamation point, and (@) at signs.

More than one dot or period (.) in a filename is prohibited. This character should be reserved for offsetting the file extension (filename.asp).

Spaces in filenames are prohibited. If you need to separate words in a file name, use underscore ( _ ) or dash ( ) characters.

As a rule use only letters, numbers and underscores. Anything else appearing in a request could be returned for renaming.

DO NOT change file or directory names arbitrarily. Once a file is named it should retain that name when possible. This will result in broken links, as other parts of the site may be pointing to existing files.

Top of Page | Contents | 1.1 File and Directory Standards | View this Standard Only

1.1.3 Website Default Document

A default document is the web page that is displayed when a browser request (URL) does not include a specific file name. The IES/NCES web servers search directories for the default document name Default.aspx for ASP.NET 2.0+ applications, and index.asp for all other applications. All IES/NCES websites must follow this convention. (e.g. http://ies.ed.gov displays http://ies.ed.gov/index.asp)

Top of Page | Contents | 1.1 File and Directory Standards | View this Standard Only

1.1.4 Temporary Files

Many applications are developed for the NCES website that make use of the creation of temporary files. These files might include data tables or graphs. Regardless of the content for these temporary files they must all be stored in one central location in the IES/NCES web environment. A folder has been designated called tempfiles in which all temporary files must be stored. The path for these temporary files is off the root of the NCES website located at: /tempfiles/foldernameforyourapplication. You cannot place these tempfiles within the web share of a specific application. The tempfiles folder is automatically emptied out twice a day at 7:00 am and 7:00 pm. For help in setting this up please contact IES Web / Network Support.

Top of Page | Contents | 1.1 File and Directory Standards | View this Standard Only

1.1.5 File Attributes

IES Support will control and maintain filelevel attributes for applications. Therefore, when modifying or uploading files, they MUST NOT be set to Readonly or Hidden.

Also, do not enable any other of Windows' Advanced Attributes (Archive and Index / Compress or Encrypt attributes) for files. Beware of files copied from source control programs (e.g. Microsoft Visual Source Safe) as these may be set to Readonly when retrieved from source control databases.

Top of Page | Contents | 1.1 File and Directory Standards | View this Standard Only

1.1.6 Supported File Types

Standard web content such as HTML files, plain text files, JavaScript (.js), Cascading Style Sheets (.css) and images (JPG, GIF, PNG and SVG) are supported as well as PDF files. These other file types are also served and supported by the IES/NCES websites:

Active Server Pages (.asp) All ASP versions that are supported by Windows Server 2012 are allowed.

ASP.NET (.aspx, .ascx, .ashx, .master, etc.) Standard ASP.NET 2.0/3.5/4.0/4.5 content is supported, including user controls, MasterPages and HTTP handlers (.ashx), as well as XML Web Services when they are not used for public serving of data (most approved web services are internal only). (.NET) Remoting is NOT currently used (but may be in future).

Macromedia Flash (.swf) Macromedia Flash is a standard for multimedia playback featuring vectorbased images, keyframe animation, MP3compressed audio, and a host of interactivity elements. The Flash clientside plugin can perform streaming animation and audio playback. Flash media files are usually assigned the extension SWF and are stored on the serverside (similar to an embedded graphic). Flash can be used on the IES/NCES website after first securing approval from the NCES webmaster for any planned application. However, a nonflash alternative must accompany any flash application.

Note: When using Flash, the <object> must have a wmode parameter set to opaque and must also be embedded with the opaque parameter. i.e.

<param name="wmode" value="opaque" /> https://members.nces.ed.gov/webstandards/?id=s1.1.1 https://members.nces.ed.gov/webstandards/?id=s1.1.2 https://members.nces.ed.gov/webstandards/?id=s1.1.3 https://members.nces.ed.gov/webstandards/?id=s1.1.4 https://members.nces.ed.gov/webstandards/?id=s1.1.5 https://members.nces.ed.gov/webstandards/ 3/28

Last revised: 08/19/2015 | Notes

Last revised: 07/11/2012 | Notes

<embed wmode="opaque" src="movie/movie.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/xshockwaveflash" width="0" height="0"></embed>

This is to prevent Flash objects overlaying over the top of any HTML content (such as the drop down navigation hover menus in the HFS).

Microsoft Office (.xls, .doc, etc.) Microsoft Office files are allowed. When possible, it is preferred that Microsoft Office files be compatible with early versions of the software (so use .doc rather than .docx and .xls rather than .xlsx).

Binaries (.dll, .exe, .ocx) With the exception of standard ASP.NET 2.0+ DLLs, the NCES webmaster must approve all binaries deployed within a program area.

Furthermore, these extensions must be separated into a Script subdirectory within a site, or, at the webmaster's discretion, moved to the global Script subdirectory. Full documentation (as well as source code) must be provided with the extension describing, at a minimum, what the extension does, why it is needed, and any necessary security precautions. Any custom ActiveX COM/DLL objects require testing on our Staging server before they can be registered on our web servers.

XML and XSLT (.xml, .xsl) small amounts of nonsensitive data may be stored as XML on the web server. XML Transformations performed using XSLT are permitted.

The following file types are NOT supported and may not be used:

FrontPage and Interdev Extensions These are not loaded on the production server and their use is prohibited. Configuration subdirectories (e.g. vti_cnf) will not be deployed into production websites.

ColdFusion, Perl, Python, PHP, CGI None of these technologies are supported on IES websites.

Java Applets For performance, accessibility and security reasons, Java Applets (or any applications requiring the user to have Java Virtual Machine installed) are not permitted on the website. (JavaScript is allowed.)

VB Script Files (.vbs) All VBScript must be incorporated into ASP pages (.asp).

ASP.NET 1.x The only versions of the .NET Framework supported are 2.0+. No older versions will be installed on IES servers.

Top of Page | Contents | 1.1 File and Directory Standards | View this Standard Only

1.2 HTML Composition

1.2.1 Cross Browser Compatibility

All IES/NCES hosted web pages must be accessible, at a minimum, by the following web browsers:

1. Google Chrome or Safari (WebKit layout engine)

2. Microsoft Internet Explorer version 9.0 and higher (Trident layout engine)

3. Mozilla Firefox 35 and higher (Gecko layout engine)

Standard users at the Department of Education currently have access to Chrome 42.0.2311.90, Internet Explorer 9 and Firefox 31.5.3.

Browser usage for the month of April 2015 to nces.ed.gov, by visits, according to Google Analytics:

Chrome 48.5%

40.0.2214.115 13.74%

41.0.2272.89 10.35%

41.0.2272.101 8.46% Other 15.95% Safari 19.89% Safari 8 7.43% Safari 7 2.19% Safari 8.03 2.27% Other 8.51% Internet Explorer 18.08%

IE11 10.81%

IE9 2.46%

IE10 2.41%

Other 2.10% Firefox 10.94%

FF 36 6.87%

FF 35 1.87%

FF 31 0.51%

Other 1.69%

More recent statistics on browser usage are available for approved members on the Members Site homepage under Site Usage Reports.

To help achieve this:

All website content should be XHTML 1.0 and use uptodate widely supported standards, such as validated CSS avoid using deprecated tags (e.g. <font> <center> <u> <strike>), keep all tags and attributes in lowercase, enclose all attributes in double quotes (e.g. nowrap="nowrap") and close all tags (e.g. <br/>).

To convey emphasis in content, either use the <strong> and <em> tags or use a style (via a <span> tag, for example), instead of <b> and <i> tags. <b> and <i> tags convey only a visual style onscreen and while they may be useful for purely visual elements in certain applications, for general content on the IES/NCES website they should not be used.

Check clientside (JavaScript) functionality never use browser specific JavaScript. For example, use document.getElementById instead of document.all, which is only supported by IE; never use the const keyword, which is Mozillaspecific.

Use existing stylesheets that have been tested for cross browser compatibility.

Use HTML tables for content requiring tabular layouts, and <div> tags with CSS for other layout only where practical. In many cases, <div> tags may not be practical for layout, especially for cross browser compatibility. Also, to comply with Section 508 requirements, pages should be readable without stylesheets.

Using complex <div> layouts may make pages unreadable without stylesheets.

Make use of the W3C Markup Validation Service to validate your HTML, CSS and check for broken links.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.2 Screen Resolutions

The IES website is designed for a minimum screen resolution of 800 by 600 pixels, which is large enough to cover the vast majority of users.

Screen resolution statistics for users of the NCES home page as of June 2012 are:

1. 1280 x 1024 37.03%

2. 1280 x 800 9.07%

3. 1366 x 768 8.88%

4. 1024 x 768 7.83% https://members.nces.ed.gov/webstandards/?id=s1.1.6 http://validator.w3.org/ https://members.nces.ed.gov/webstandards/?id=s1.2.1 https://members.nces.ed.gov/webstandards/ 4/28

Last revised: 07/11/2012 | Notes

Last revised before April 2009

Last revised: 10/21/2011 | Notes

Last revised: 07/11/2012 | Notes

Last revised before April 2009

5. 1440 x 900 5.99%

6. 1920 x 1080 4.96%

7. 1680 x 1050 4.31%

8. 1600 x 900 2.91%

9. 2560 x 1024 2.06%

10. 1152 x 864 1.54%

Horizontal scrolling should not be necessary to view pages at this resolution. Table should not have absolute widths. By default, page widths are set by IES global style sheets. (They do not exceed 750 pixels.) This will ensure no horizontal scrolling occurs.

It is not a good idea to have several pages of text on a single web page that forces the user to scroll and scroll and scroll some more. However, if you find that you do have several pages of text then they should be organized in a logical manner with a contents area that provides headings, links to text (or graphics or data) and a "Top" button following each section. This will permit the user to go directly to their area of interest and then return to the table of contents to continue with their selection. An example of this can be found at: http://nces.ed.gov/surveys/ruraled/Definitions.asp.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.3 HTML Editors

While IES does not prohibit using any particular HTML editor for creating web pages, it is important to note that no custom FrontPage, Interdev, DreamWeaver, etc.

objects nor extensions (such as Search, ImageMap, etc.) will be supported on our site. In addition, you may find that these tools generate extraneous folders such as vti_*. If you are using one of these editors you must remove such folders from the IES Staging server. See Supported File Types for a list of allowed files. Some programs used to create or edit HTML (e.g. Microsoft Word, some WYSIWYG editors) will also generate a lot of extraneous code. Beware of these.

An HTML editor that we have found to produce "clean" code is Adobe Dreamweaver. You may also use any textbased editor that generates "clean" code.

Note: For ASP.NET 2.0+ web applications, Microsoft Visual Studio 2005 or later is recommended.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.4 DOCTYPE and Encoding Declarations

The first line of every HTML document must be a DOCTYPE declaration (document type declaration). This informs the validator which version of HTML you're using.

DOCTYPEs are a key component of compliant web pages: your markup and CSS won't validate without them. The opening html tag should also have the correct XML namespace URL. For example, for a typical XHTML 1.0 Transitional document:

<!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">

IES webpages should use XHTML 1.0 Transitional as a baseline default, although pages may also be written in XHTML 1.0 Strict. Do not use Frameset DOCTYPEs unless necessary (see 1.2.7 on usage of Frames), and never use older DOCTYPEs (e.g. HTML 3.2).

You must also specify a specific character set in addition to the DOCTYPE. A simple technique to mitigate exposure to crosssite scripting attacks is to explicitly declare which character set should be used on your HTML page. If a character set is not explicitly defined, any character encoding may be used and due to the many variations of character encoding, it becomes very difficult to filter out unwanted characters. All IES web pages should use the 8bit ASCII ISO88591 character set, which would be specified by including this line:

<meta httpequiv="ContentType" content="text/html; charset=ISO88591">

Additional meta tags are used throughout IES websites for search purposes see the section on Search Engine Optimization Meta Tags for details.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.5 Comments

Use HTML comments only when you need to see the comment in the output HTML. Do not leave comments in any content that is served to the client, especially HTML source. This includes notes, bits of serverside code, and other sensitive information such as user IDs, passwords, file paths, database locations, etc. Sensitive information should only be stored in appropriate serverside files for example, ADO.NET database connection strings will be stored in rootlevel web application configuration files. Basic comments in CSS files or JavaScript are allowed.

Tip: When editing an asp/aspx file in Visual Studio, you can use the CtrlK, CtrlC keystroke combination to comment a block of text and by default it will use ASP instead of HTML comments.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.6 Popup Windows

The following rules apply to any popup windows you use:

Popup windows must not include an address line for a URL.

Popup windows must be set to open in the far upper lefthand corner of all browsers. For an example, see the help link on http://nces.ed.gov/nationsreportcard/naepdata/. This requirement fits with the IES standard of centerjustified pages, especially for users who are not adept at moving and resizing windows. To create popups that account for Firefox and IE's varying JavaScript syntax, the screenx, screeny, top, and left parameters need to be included in the window.open statement as follows:

window.open('testpage.htm','myExample6','width=200,height=200,screenX=0,screenY=0, top=0,left=0');

Using this syntax, Firefox will ignore the top and left parameters and look only at screenx and screeny. IE will do the opposite.

A "close window" button must be included immediately after the last line of text in the popup window.

DO NOT include the IES/NCES header or footer.

The correct meta tag MUST be included to prevent the popup from being included in sitewide searches. These pages should not be included in any search indexing.

Include a mechanism to focus on the popup when it is loaded to ensure that the window is not lost behind other windows, for example: onload='self.focus();' in the <body> tag of the html page of the popup window. (Don't put this code in the <body> tag of the page that creates the popup window!)

<body onload='self.focus();' vlink="#s0000FF" bgcolor="#sFFFFF4">

If you want the user to be able to print from that window, include a print option button.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.7 Frames

Designing web pages with frames enables the display of multiple scrollable panels on a single screen. Frames divide web pages into separate regions that can display content independently. However, frames present navigation and accessibility problems. They typically don't work as well on lowresolution screens because the content must be compressed into smaller frames and because they require multiple page loads, they can also increase download time.

For these reasons the use of frames is not allowed on the IES/NCES website, unless there no other design option exists. These special exceptions must be approved during the predesign phase by the NCES webmaster before any actual work is done. You may also be asked to provide an alternative accessible nonframes version, http://nces.ed.gov/surveys/ruraled/Definitions.asp https://members.nces.ed.gov/webstandards/?id=s1.2.2 https://members.nces.ed.gov/webstandards/?id=s1.2.3 https://members.nces.ed.gov/webstandards/?id=s1.2.4 https://members.nces.ed.gov/webstandards/?id=s1.2.5 http://nces.ed.gov/nationsreportcard/naepdata/ https://members.nces.ed.gov/webstandards/?id=s1.2.6 https://members.nces.ed.gov/webstandards/ 5/28

Last revised: 08/17/2009 | Notes both as a default for browsers that do not support frames and as a prominent link users may choose from the frames version.

If a special exception is approved, you must provide context and orientation information to help users understand the elements. This includes:

1. Title each frame to facilitate frame identification and navigation. For example, in HTML use the "title" attribute on FRAME elements.

2. Describe the purpose of each frame and how each frame relates to another if it is not obvious from frame titles alone. For example, in HTML, use "longdesc," or a description link.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.8 XHTML DOCTYPE Standards

As of August 13, 2008 all pages on ies.ed.gov and nces.ed.gov were required to use XHTML 1.0 (Transitional or Strict) as their standard DOCTYPE (previously HTML

4.01 was acceptable). XHTML gives us better coding possibilities, enforces better coding practices, and increases platform compatibility. All pages must be tested and in working order in browsers in our required compatibility list.

Below are the two doctypes you can choose from:

Transitional:

<!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd">

Strict:

<!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1strict.dtd">

This code must be entered EXACTLY as it appears above.

Note: In order to validate as XHTML you should also include the XML namespace attribute on your opening HTML tag:

<html xmlns="http://www.w3.org/1999/xhtml">

If you are familiar with working in HTML 4.01, changing to XHTML 1.0 may alter or break some visual aspects of some web pages, which will require minor changes to the html code and css styles. In most cases using XHTML instead of HTML will have no affect on the look or function of your web pages. Pages need not fully validate to XHTML 1.0, but they do need to render as expected.

Specific issues to look out for if you are unfamiliar with the XHTML DOCTYPE:

Comment tags Comment tags should be rendered as <!Your Comment >. Avoid using extraneous comments, and stick to comments that will help other developers identify key pieces of content. For instance, more than 41 dashes in a row, will break webpages in Firefox.

Divs falling below content If, on a columned page set with divs, the right column is falling beneath the left column, adjust the div sizes and test in all browsers (hint: avoid mixing set widths with percentage based widths).

Empty tags Tags should not be left empty, (i.e., if you need a blank cell in a table, <td></td>). All empty tags should have a nonbreaking space inserted, (i.e., <td>&nbsp; </td>).

Suggested guidelines for developing valid XHTML pages:

ALL documents must have a DOCTYPE declared before the opening <html> tag appears and the correct XML namespace URL (xmlns attribute) on the opening <html> tag.

The most common characters that require escaping are &, < and >.Use &amp; instead of &. A common mistake is to have URLs with unescaped ampersands.

e.g., <a href="foo.php?chapter=1&amp;section=2">Here & There</a> instead of: <a href="foo.php?chapter=1&section=2">Here & There</a>

Tags must be closed in the same order they are opened.

<strong><em>text</em></strong> instead of: <strong><em>text</strong></em>

Also, block and inline elements must be correctly nested. e.g., <p><strong>text</strong></p> instead of: <strong><p>text</p></strong>

Do not omit tags that are required as part of the tag's definition. e.g., use <table><tr><td>content</td></tr></table> instead of: <table><td>content</td></table> and

<ul><li>listitem</li><li>listitem 2</li></ul> instead of: <li>listitem<li>listitem 2

All tags and attributes must be lowercase e.g., <meta name="rating" content="General"> instead of: <META NAME="rating" CONTENT="General">.

(Note: the DOCTYPE declaration is not a tag, and must be in uppercase.)

Attributes must always have a value, and the value must be in double quotes, not single quotes (or no marks at all). e.g., <input checked="checked" /> instead of: <input checked /> or <input checked='checked' /> or <input checked=checked />

All tags must be closed. This includes tags that are often left unclosed such as <img>, <input>, <link>, <br>, <hr>, <p>, <meta>, etc.

e.g., <p>paragraph 1</p><p>paragraph 2</p>instead of https://members.nces.ed.gov/webstandards/?id=s1.2.7 https://members.nces.ed.gov/webstandards/ 6/28

Last revised: 08/19/2015 | Notes

Last revised before April 2009

Last revised: 08/19/2015 | Notes

<p>paragraph 1<p>paragraph 2

In many cases you can use the selfclosing tag format for to make it easier: e.g., <img src="test.jpg" height="32" width="32" alt=" " /> instead of: <img src="test.jpg" height="32" width="32" alt=" ">, and

<br /> instead of: <br>. (Note: <br /> is preferred instead of <br/>.)

Note: script and meta tags should never be selfclosing, in order to avoid browser and search engine spider compatibility issues.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.2.9 Secure Sites

NCES supports 256bit Secure Socket Layer (SSL) encryption via its F5 Networks Big IP load balancing server. To facilitate encryption and server authentication, valid certificates signed by a trusted certificate authority are required.

When the client browser is engaged in a secure connection, a small padlock symbol will be visible in the address bar of the browser window. Doubleclicking (for Internet Explorer) or clicking (for Firefox and Chrome) on the padlock will generate a dialog window containing information about the certificate used by the server for the purpose of encryption.

Top of Page | Contents | 1.2 HTML Composition | View this Standard Only

1.3 Section 508 and Style Guidelines

Section 508 regulations cover IT accessibility requirements for Federal agencies and have been in effect since June 2001. Essentially they require that information technology be equally usable by members of the public with and without disabilities as well as Federal employees with and without disabilities. For IES/NCES websites, this means that text labels and descriptors be provided for all graphics or graphical representations, amongst other considerations.

In addition to Section 508 requirements, style guidelines are provided for IES/NCES websites' designs. With IES/NCES websites hosting over 70,000 static pages contained in approximately 150 major directories, these have been created to promote consistency and good design principles through all our websites and must be followed.

You are responsible for the pages on your website. Please check your pages for compliance (see specific details below in this section) and correct them before your next update request.

1.3.1 Section 508 Technical Standards

These are the standards that apply to IES/NCES websites, taken from 1194.22 Webbased intranet and internet information and applications of Section 508:

(a) A text equivalent for every nontext element shall be provided (e.g., via "alt", "longdesc", or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

(e) Redundant text links shall be provided for each active region of a serverside image map.

(f) Clientside image maps shall be provided instead of serverside image maps except where the regions cannot be defined with an available geometric shape.

(g) Row and column headers shall be identified for data tables.

(h) Table markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. Defining row and column headers, defining the scope attribute and using ID and header attributes, will make the tables 508 compliant.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k) A textonly page, with equivalent information or functionality, shall be provided to make a website comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the textonly page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plugin or other application be present on the client system to interpret page content, the page must provide a link to a plugin or applet that complies with §1194.21(a) through (l).

(n) When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive navigation links.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

More information is available through the link to the Federal IT Accessibility Initiative at: http://www.section508.gov/

This tutorial , written for the Information Technology Technical Assistance and Training Center, funded in support of Section 508 by NIDRR and GSA at Georgia Institute of Technology, Center for Rehabilitation Technology, shows you how to make your web pages accessible and meet Section 508 standards.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.3.2 Section 508 Tests

All web pages that are submitted for review should at a minimum pass certain tests. Visit http://www.w3.org/WAI/ER/tools/complete to find tools that analyze web pages for their accessibility to people with disabilities.

The types of errors reported by tools vary, but the following items must be included or submissions will be considered as failing Web accessibility requirements for people with disabilities by IES/NCES content review staff:

Provide alternative text for all images Provide alternative text for all image map hotspots Do not use frames (they are prohibited on the IES/NCES websites).

Make sure that users can tab to all navigation on the page.

Complex data tools should offer an Accessible Version (for an example, see the NAEP Data Explorer).

For PDF specific information on 508 Compatibility, see Standard 2.3.6.

The W3C Markup Validation Service can also be used to help check your content.

https://members.nces.ed.gov/webstandards/?id=s1.2.8 https://members.nces.ed.gov/webstandards/?id=s1.2.9 http://www.section508.gov/ http://jimthatcher.com/webcourse1.htm https://members.nces.ed.gov/webstandards/?id=s1.3.1 http://www.w3.org/WAI/ER/tools/complete http://nces.ed.gov/nationsreportcard/naepdata/ http://validator.w3.org/ https://members.nces.ed.gov/webstandards/ 7/28

Last revised before April 2009

Last revised before April 2009

Last revised before April 2009

Last revised: 10/21/2011 | Notes

Sites should also be tested by a text reader such as JAWS.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.3.3 ALT and TITLE attributes

Note: Although ALT and TITLE are displayed here in capital letters they should always be written in lowercase throughout any HTML document, as with any HTML attribute.

The ALT attribute is designed to be an alternative text description for images. It must be present for all image elements, Java applets, Flash files, video files, audio files, plugins etc. ALT attributes are essential for addressing accessibility issues and satisfying Section 508 requirements for users with disabilities. It may also convince those with their graphics turned off to load the image. The ALT attribute provides context for your images, especially when used for navigation bars, buttons, and other graphical navigational elements. ALT text is displayed instead of the image in textbased browsers like Lynx, and in place of the image if the image is not displayed in most regular browsers.

Use empty ALT attribute text to identify images such as decorative graphics with functional information: alt=" " (i.e., quote space quote do not leave out the space!).

Screen readers bypass this empty ALT, cutting down the aural clutter/confusion that a graphicintensive page may otherwise generate. At the same time visual ALT attributes will 'pop' up, letting a user know where there are design element level graphics. This convention should be used for images that would otherwise be labeled:

"left" or "right" or "spacer" or "border" or similar things.

DO use an English language description such as "picture of boy", or "photo of Secretary Duncan at IES".

DO use ALT text such as "go to What's New" instead of just "What's New" if the image represents a link.

DO use, as a minimum, the title of the table or graph as the ALT image for an image that is a table or graph.

DO limit the length of your ALT texts. If the text description is too long or complicated to go into an ALT attribute, consider first including the text in the page. If this is not feasible, include the text as a link use both the longdesc attribute (with the longdesc text being the link) and append a descriptive link (a standard href) after the image as well (since the longdesc attribute is not supported by all screen readers and has no visual representation on most browsers). Using "D" links is not recommended.

DO NOT use the file name of a graphic (e.g. horishort440.GIF) as its ALT text.

DO NOT use generic words such as "table" or "graph" for a table or graph's ALT text.

DO NOT use the ALT text as a popup tooltip for images. The TITLE attribute may be used instead (but note that it is up to a particular browser's interpretation of the W3C Specification on how the TITLE text is displayed).

DO NOT use blank ALT text (alt="") in any situation.

The TITLE attribute may be used to include additional descriptive information for most structural HTML elements including links and images. Unlike the ALT attribute, it is not required. TITLE text is rendered as a popup tooltip in many browsers although this is not part of their specification, and may vary from browsertobrowser. They may also be read as page content keywords by search engine ranking algorithms.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.3.4 Colors

When designing web pages for the IES/NCES website you must use white as a body background color. No other body background colors may be used. This helps provide the IES/NCES website with a consistent look and feel. When users are on a site and the site changes drastically in terms of color (as well as other things) they no longer feel they are on the same site and they potentially get confused as to their current location. Nonwhite background colors make readability an issue, especially with certain computers and resolutions.

The simplest approach to selecting a color scheme is to limit oneself to only 3 or 4 colors (in addition to black and white), using a primarily monochromatic scheme.

Choose a base color for the main scheme and find one or two other shades of the same color family to tone with it. Determine whether the selected colors come from the yellows group (generally warmer colors) or the blues group (cooler colors). Make sure that the chosen shades contrast enough to be readable when used as text on top of another shade, or on white. Then select an accent color (as may be used for followed links) from the 'other' group of colors.

Also keep in mind that an estimated 7 to 10% of men have some form of color blindness. This can cause difficulties distinguishing between colors commonly red and green (95% of color blind cases), or yellow and blue, and in rare cases an inability to perceive any colors at all. You are recommended to avoid foreground/background color combinations that would make the text hard to read for people with color blindness.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.3.5 Fonts

Do NOT use HTML <font> tags to set font properties (in fact, do not use them all). Cascading Style Sheets (CSS) should always be used for visual styles.

Typeface: use a sans serif typeface, such as Helvetica, Arial, Univers or News Gothic, which is not condensed. Avoid the use of serif (e.g. Times New Roman), novelty (e.g. Old English Text), and display (e.g. Bodoni Poster) typefaces.

Use medium or bold face type.

Present body text in initial capitalization. Use all capital letters and italics in headlines only (OK for publication titles as well). Use underlining for links only.

Aligning text to the left is preferable to center or right alignment.

When using the CSS fontfamily property, specify several different fonts (we recommend at least 3) in the order you want them accessed in case a user's computer does not have them installed. List specific font family names first (e.g. arial, helvetica) and use a generic family name (sansserif is recommended) as the last in your list.

Also note the following font size suggestions adapted from the World Wide Web Consortium :

Do not specify the font size in pt, or other absolute length units. They render inconsistently across platforms and can't be resized by the browser. Only specify the font size for pages that need a fixed physical size (e.g. print media).

Use relative length units such as percent or em, or, even better, set a base fontsize for the document and use absolute size ([ xxsmall | xsmall | small | medium | large | xlarge | xxlarge ]) or relative size ([ larger | smaller ]) when defining the font size for a particular element within the document.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.3.6 Style Sheets

All newly developed and updated IES/NCES web pages must use our global style sheets, which will provide the correct positioning and styling of page content. All IES/NCES pages using the latest Header Footer Service (HFS) will automatically link to the correct basic style sheet (hfsMain.css). Other existing style sheets will be phased out (other than the members site style sheet https://members.nces.ed.gov/inc/membersstyle.css). Wellwritten style sheets provide consistency and flexibility with a website's visual design, while adding support for DHTML and other web technologies and are typically cached by a client's browser, increasing performance.

We encourage you to use your own style sheets in your applications, with the following rules:

1. Do NOT set global styles or classes on HTML elements. That is, do not set styles or classes on <body>, <a>, <p>, <div>, <input>, etc...

Don’t use:

a, a:visited { margintop:6px; marginbottom:6px;

Instead, use classes:

a.space, a.space:visited { margintop:6px; marginbottom:6px; https://members.nces.ed.gov/webstandards/?id=s1.3.2 https://members.nces.ed.gov/webstandards/?id=s1.3.3 https://members.nces.ed.gov/webstandards/?id=s1.3.4 http://www.w3.org/QA/Tips/font-size https://members.nces.ed.gov/webstandards/?id=s1.3.5 https://members.nces.ed.gov/webstandards/ 8/28

Last revised before April 2009

Last revised: 10/21/2011 | Notes

2. Style sheets must not interfere with the display and function of the standard IES/NCES header and footer rendered by the HFS.

3. All pages must be tested to confirm that the style sheets do not cause display or functional errors in Internet Explorer 7+, Mozilla Firefox 3+ and Safari/Google

Chrome and recommend you testing your pages in each of these browsers (minor display differences such as alignment issues are okay).

Note: Section 508 requires that IES/NCES web pages must be laid out so they are readable without requiring any style sheets.

4. All links to style sheets should be inside the <head> section of your XHTML document, not inside the <body> section.

Requests pertaining to content that breaks these rules may not be approved. These rules apply to all newly developed, indevelopment, or updated web content.

To help you create functional and effective style sheets that adhere to the above rules and are consistent with the IES/NCES websites, we recommend the following guidelines when creating and using style sheets in your web pages:

Use <div> tags to lay out your pages as opposed to using tables. Tables should be used for tabular information, not to line up to columns of text.

Avoid specifically underlining any text. Links and only links should be displayed with underlines.

Use a consistent naming convention for your CSS classes. In new applications try using a prefix to differentiate your styles from other applications, such as:

.dasTitle, .dasBodytext, etc. Do not use "ies" or "hfs" as prefixes, as these are reserved for IES/NCES class names.

Use ID tags for programming purposes only, not in place of a class. IDs should be unique and therefore used for elements that will appear once on a page.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.3.7 Usability Testing

In addition to accessibility testing, usability tests are useful for all websites and major new applications in particular. It is virtually impossible to tell how users will react to websites without having them try to perform what is expected of them. One type of usability test that is currently popular is conducted in a fully functional lab environment with a live site. For each test six to eight users who fit the target population for the website are found. Once the users are found they come to the lab individually and perform a series of tasks with the website. The ability of the website to allow users to easily find them and quickly perform a task is observed and measured. Some of the variables measured are speed to complete a task and accuracy of task completion. The user's overall opinion of the site is also recorded. Issues from each task attempted are recorded and recommendations for addressing these issues are made. IES/NCES has access to a usability lab at the Bureau of Labor Statistics. If you would like to arrange for its use please contact Brian Taylor (202) 5027498.

Top of Page | Contents | 1.3 Section 508 and Style Guidelines | View this Standard Only

1.4 Content Composition

This section covers the authoring and updating of general web content (especially HTML and multimedia). Design Templates for web publications are also available on the Members site. For additional rules and standards specific to sections of the IES/NCES websites (e.g. surveys, publications and tables), see Policies. For additional rules governing ASP conventions, please see Classic ASP Coding Conventions.

1.4.1 Header and Footer

IES/NCES has an established standard header and footer that must be included on all pages of the IES website.