UK Home Academics Athletics UK's Chandler Medical Center Research Site Index Search UK


Computing Policy
Copyright and Fair Use
Graphics Standards
Web Policy
Web Standards and Guidelines

Additional Information

CGI Programming and Server Scripts
Data Types
Forms With AnyForm
Forms With Fileform
Groups of Providers
Image Consent Form (PDF)
Image Maps and Sensitive Images
Images and Graphics
Latin Character Entities
Moved Pages
Page Access Counter
Parts - Images for Your Pages
Restricting Access to Web Pages
Sample Page for UK Departments
Scanned Text
Searching Your Pages
Server Notes
Webpubs-L Mailing List


Guides, Tutorials, & Validators

Alertbox: Current Issues in Web Usability
Bare Bones Guide to HTML
HTML Validation Service
HTML 4.0 Reference
HyperText Markup Language
Net Mechanic
Ten-Minute Guide to HTML
Web Style Guide

References & Standards

HTML 4.01
HTML 3.2
HTML 2.0

Other Items of Interest

Center for Applied Special Technology (CAST)
Computer Incident Advisory Capability (CIAC)
Copyright Basics(from LOC)
Cornell University: I.T. Rights and Responsibilities
Princeton University: I.T. Resources and Internet Access




The World Wide Web (WWW) is a hypertext, multimedia way to access and distribute information on campus and around the world on the Internet. Our main web server is at and the complete URL (uniform resource locator) is:

University departments, faculty, classes, and organizations, including registered student organizations, can have space on the campus server. (Individual students can have web pages on the student web server - see for more information.)

There is no charge for this service, but if your disk space requirements will exceed a few dozen megabytes, please let us know. The web server does not have the resources to act as a general file server, archive, or backup! When the amount of available disk space on becomes low large files will be arbitrarily erased without notice.

Your use of the University's web servers must conform to the University's Web Policy and like all University computing resources, must comply with the Computing Resources Policy.

To become a web information provider you must request a web userid (a U-connect userid won't help) from user account services at the Help Desk in McVey Hall.

Each person who will be working on files on the web server must have their own web userid in their own name issued to them by user accounts services. The University computing policy generally prohibits sharing userids or passwords. The purpose of a web userid is to identify and authenticate an individual person with access to the server and not to define a URL.

To provide information for the web server you may need at least a little familiarity with Unix. You can do your editing and preparation on any system you prefer (Mac, VM/CMS, Windows, etc.), but the files will eventually be put on a Unix system and you will need to be able to use FTP (File Transfer Protocol) or log on there and use a few commands to prepare them for use by the server.

The recommended and supported web browser at the University of Kentucky is Netscape Navigator, which is available for Macintosh, Unix, and Windows systems. Microsoft Internet Explorer is also widely used on campus. Other browsers are also in use as well and you generally shouldn't use non-standard, browser-specific features.

Our web server is Apache running under Unix. It does not support Microsoft's Active Server Pages (ASP). PHP and Python are available.

We cannot support or recommend the use of any web page creation tools or HTML editors, such as Dreamweaver, Adobe Pagemill, Microsoft Front Page, Netscape Navigator Gold, etc., and we do not provide any server code that they may require. You can use these products with our server if you desire and can do so without assistance from Information Technology. Even server extensions that are available without charge would require maintenance by our staff and can unnecessarily complicate the work of our web providers who choose not to use them, therefore we do not make them available.

Departmental and Other Campus Web Servers

Some departments, colleges, and other organizations operate their own web servers (a recent survey located over 200 web servers on campus). We have no control over those servers or their contents, but we do have links from pages on to other campus servers when appropriate. If you maintain pages for your organization on a server other than and we have links to them (in the Site Index, for example), please inform us (by e-mail to when a URL changes. Note that all University web servers must conform to the University's Web Policy.


You will need to learn some Hypertext Markup Language (HTML) - the language of web pages. A number of tutorials and references are available from the web. We provide a very simple skeleton HTML file that is suitable for departmental use.

Contact the Help Desk at for information about HTML classes.

Your Information

Information for the web server is kept in files on the system at When you connect to with your id and password (using SSH or FTP, for example), you should find in your default directory a subdirectory called "www" for your web files. (If a www subdirectory isn't already there, you can create one using your FTP client software or the Unix mkdir command.) You will put files for use by the web server in your www directory using FTP or whatever method that works best for you. You must make these files available to the server by setting the file access flags (the server system is set up to do this by default, but you should check to be sure they are correct).

For example, on a Macintosh you would use Fetch, an FTP client, to copy files from the Mac to the web server. When you start Fetch you will see a connection dialog in which you will specify the name of the server (, your web userid, your password, and the directory on the server (www for your personal space or the directory path assigned to your project). Windows users might use an application like Ws_ftp.

Files copied by FTP to the server are made globally readable by default. This is necessary to make them available via the web server. You may need to adjust the file access permission settings for some applications or to make them available for group maintenance. Fetch has functions under the Remote menu to control the access permissions for your files on the server. (It also allows you to erase and rename your files as needed.) Most FTP clients also support the site umask command for controlling access permission settings. You can also SSH to the server, log on, and use the chmod command for this.




Generally you will want your HTML files to be readable by everyone and writable only by the owner. If you have a group working on files you may need the group write setting too. Any subdirectories generally will also have these settings. The FTP command site umask 022 will make these settings on files when they are uploaded.

In addition, subdirectories need to have the search/execute authorization set for everyone so the web server can search them for files. Individual files don't need the search/execute authorization unless you are using the server side include feature (see the Apache server documentation for more information).

Software is available on some systems that will allow you to use tools you are more familiar with for editing your HTML files and move them more-or-less automatically to the server. BBedit on the Macintosh and the Xftp command on VM/CMS are examples.

Keep in mind that the Unix file system is case sensitive. For example, the names "Sample.html" and "sample.html" are not equivalent and don't refer to the same file. The usual convention is for HTML files to be named with .html at the end, but .htm works too (except for your initial "welcome.html" file). Other common endings are .gif for GIF (Graphics Interchange Format) images and .jpeg for JPEG (Joint Photographic Experts Group) format images. In a departure from the Unix custom, these suffixes are not case sensitive in that both .GIF and .gif would be recognized as a GIF file, but a URL must still match the case actually used to locate the file.


We are running with the Apache server's CheckSpelling option enabled. If a URL specifies a file or directory that doesn't exist the server attempts to find something with a similar name. This means that the case specified in the URL need not be correct. This search incurs additional overhead on the server and requires an additional exchange between the browser and server, so you should make sure links included in your pages are correct, but it does significantly ease finding things for someone typing a URL at their browser. This can also inadvertently reveal sensitive files so you may want to disable it for some subdirectories. Create a file called .htaccess in the subdirectory and include the CheckSpelling Off directive. Consult the Apache documentation for more information.


Once you have loaded your files you can reference them for testing from your web browser with a URL like this:

where "~userid" is a tilde followed by your userid and "typical.html" is the file in question. If you don't specify a file the server will look for one called "welcome.html" by default and you should use "welcome.html" for your initial page (note that "welcome.htm" won't work).


Note that tildes are not legal characters in URLs according to the standard, but they are widely accepted nonetheless. To comply with the standard you should use the sequence %7E instead of a tilde:

Don't advertise a URL on using the ~userid form for other than testing, class, or personal purposes! This is very important! At some point in the development of your web project get in touch with us and we will set up a more permanent directory and URL for your publication-quality files leaving your www directory for testing and development. This arrangement facilitates the maintenance of the server and helps assure that your files will be handled correctly in the future.

Once you have pages ready to publish, contact and tell us the project you are working on, your department, the web userid or userids that will be used, and a phone number where we can reach you.


Mailing List

There is a mailing list for campus web providers - WebPubs-L. To join send a note to with the following as the text:

   subscribe webpubs-l Your Name

Some Additional Considerations

There are several things you should keep in mind when designing your World-Wide Web pages. These points can help make your pages more useful to a larger audience.


Your pages should have clearly indicated a contact for additional information, comments and questions about the pages, etc. An e-mail address is very convenient for most using the web so it makes a good contact mechanism.


Try to use a unified design for your pages - make them look like they belong together. If you are making pages for a University department or unit you should try to follow the general style of the other University pages - they should all look like they came from the University of Kentucky. (The University's Web policy includes some page design requirements including rules regarding the use of the UK logo. Also see the University's Graphics Standards for more information.) See our sample HTML file for a simple starting point.

Generally a white or other light background with black or other dark, contrasting text will be the most legible and thus the most useful. On some systems, depending on the fonts available and the colors used, light text on a dark background is virtually illegible. As a web author you don't have any control over which fonts are available on a user's browser and how they are rendered. This point can't be overemphasized - just because it looks good on your screen doesn't mean it will on another.

When possible use the 216 colors that are most universally available to avoid dithering (see our images page for more details about color palettes).

Clearly identify what you are trying to communicate with your pages and concentrate on that. Avoid extraneous elements that detract from that goal. Maximize the amount of information on your pages. Strive for simplicity, elegance, and directness. Avoid splash pages that viewers must pass through to get to the actual information they need.

Provide a clear path from each of your pages back to your first page or other appropriate starting point. This can be as simple as a few links at the bottom of each page. People using search engines or following links from elsewhere can jump directly to any of your pages. (See our notes on searching for more on this.) A link back to the University's home page is often appropriate. The standard UK navigation bar is required at the top of all home pages for colleges, departments, and units. (See our sample HTML file for an easy way to include it if you are using


An important consideration is how your audience will view your pages. On the UK campus in Lexington access will most likely be from a Macintosh or Windows PC with a fast ethernet connection, color monitor, and Netscape Navigator or Microsoft Internet Explorer. The speed and capability of the workstations can vary considerably however. The size and color resolution of the monitors will vary (some will even be black & white). Some people will be viewing your pages from VM/CMS or a Unix system with a text-only browser and won't be able to see graphics. Many will be accessing the web over a relatively slow modem connection and will at the least be irritated by unnecessarily large graphics and may well disable automatic loading of graphics. Some will be using a web browser other than Netscape's or Microsoft's, so reliance on their browser-specific extensions to HTML and other idiosyncrasies can cause problems. These considerations are even more important if a significant part of your audience will be located off the Lexington campus.


While graphics can be a valuable addition to a web page, consider what you are trying to communicate and avoid extensive graphics that convey little or no information. Animated images can add another valuable dimension to a page, but they are also often abused and are often more annoying than useful. "Under Construction" signs and logos from your favorite web browser company seldom add any value to a web page. (They have become dreaded web clichés.) Use the alt attribute of the img tag to provide a text alternative to your image for users who can't or aren't using graphics. See our images notes for more on using graphics.


Try to avoid excessive use of bold and italic text. On some workstations they are much less readable than plain text and too much makes a page harder to read in any case. The high-numbered HTML heading levels have the same problem - some browsers use very small, bold text that is virtually illegible for H5 and H6 headers. Some browsers support blinking text, but that is usually very difficult to read and will quickly induce visual fatigue and annoyance in readers. Some screen readers for the blind will have problems with it as well. Some browsers allow you to control the background and text colors or supply a background image. Keep in mind that some combinations of colors or complicated background images can make your text virtually illegible.

With HTML 3.2 and later you can specify type that is larger or smaller than the default with the font tag's size attribute or a style sheet. Some browsers also support a face attribute, but that is problematical.


To assure the widest compatibility your pages should use HTML that conforms to HTML 4.01 Transitional. This is basically HTML 3.2 with some common extensions. New versions of HTML will be specified as XML and the specifications of XHTML have been released. Keep in mind that some people will still be using older browser software that supports HTML 2.0 or some variant, although the numbers of these are very low. Most browsers have idiosyncrasies in their interpretation of the HTML standard and also include private extensions not supported by other browsers. This makes designing and testing web pages a complicated task.

An HTML Validation Service is available on the web.


Your pages may be used by people using screen readers or speech or Braille output devices. To better support them you should include descriptions with images, make careful use of tables, and take other steps. The W3C has accessibility guidelines and the Webxact web page analyzer can check some aspects automatically. Also see the Access Board web site and the General Services Administrataion's Section 508 site.

The growing use of hand-held, wireless devices with network access should be considered as well. Many of these devices support only text and have very small display screens.

Putting text into graphic elements makes your page useless for users in these situations.


Always respect the intellectual property rights of authors and artists. Don't use images or other material from someone else without permission. The University's Web policy includes information on intellectual property and copyright concerns and we have additional information on copyright and fair use considerations.


PDF is a file format that allows a document to be displayed by a web browser with very precise control over formatting - much more than is possible with HTML. With appropriate software PDF files are very simple to produce from existing word processing documents and other sources. However, they have several disadvantages. A browser plug-in is required to view the files, requiring some extra software to be installed by the potential users. The PDF viewer is very widely available, but not universal and some browsers and older systems are not able to use it at all, making PDF files unusable to some. PDF files are generally much larger than a simple HTML version of the same document, often by a factor of 10 or more, thus slowing the display. Many indexing systems cannot handle PDF files, so they will not be found by some search engines. PDF should be used only when very precise formatting is absolutely required, as when it is necessary to precisely match existing paper documents, or when other features available through PDF provide important benefits. Converting an existing document to good HTML is usually much more time consuming that generating a PDF file, but the time spent may be repaid many times over by that saved by the users of the page.


Support for Java and JavaScript, programming languages that allow programs to be downloaded from a web server and executed on the client workstation, are widely available, but aren't universal. Java and JavaScript should only be used when there is compelling need and an alternative method of accessing the function supplied that way should be provided. Reliance on Java or JavaScript can make your pages inaccessible to those relying on assistive technologies and may prevent them from being properly indexed by our search service. The addition of Java or JavaScript will make testing, debugging, and updating your pages much, much more complicated. Carefully weigh the costs and benefits. (Actually, because of unresolved security problems, it may even be best to disable JavaScript and particularly Java on browsers that support them.)


Carefully proofread your pages after any substantial revision. Spelling checker software can be a useful aid, but don't rely on it too heavily - it can't detect incorrectly used words.

This page was last updated on 2009-01-21. Please direct questions and comments regarding this page to


An Equal Opportunity University