SRJC CWIS Web Guidelines
http://www.santarosa.edu/compserv/iss/ web-guide/
1.42


September 24, 2003

Contents

Introduction
1 SRJC Web Guidelines
 1.1 Technical Web Guidelines
  1.1.1 Required Technical Web Guidelines
  1.1.2 Recommended Technical Web Guidelines
  1.1.3 Optional Technical Web Guidelines
 1.2 Usability
  1.2.1 Recommended Web Usability Guidelines
2 Individual SRJC Web Servers
 2.1 www.santarosa.edu
 2.2 student.santarosa.edu
 2.3 online.santarosa.edu
 2.4 autobahn.santarosa.edu
 2.5 testsys.santarosa.edu
 2.6 busxowa.santarosa.edu
Acknowledgements
References
Index

Introduction

The Santa Rosa Junior College Mission Statement [13] states that the college is committed to “Promoting open access through actively eliminating barriers to a college education.” This document is intended to help with creating web pages that will help with that stated goal.

Most of the SRJC web site will be used by a broad audience, including: local students; foreign students; English as a Second Language students; vocational students; lower-income students; CSU transfer students; UC transfer students; continuing education students; adult reentry students; parents, guardians, relatives and other supporters of any of the previous mentioned students and potential students; employees of the college; job seekers; and employees of other institutions. All of those categories may include people with different types of disabilities, from total blindness to slightly blurry vision. Users may have any of a range of computers, from a brand-new $5,000 computer to a nearly free “outdated” computer built from spare parts. Their computer may have all the latest versions of the relevant software, or may have only the most basic web browser. Students without their own computer may choose to use the computer labs or any of the “web kiosks” deployed on our various campuses.

This means that, ideally, all of our web site should work on any computer for any user, regardless of their own capabilities or the capabilities of their computer. These guidelines are designed to assist with creating sites that will work for as many users as practical in order to avoid excluding anybody.

The “Webmasters” in Computing Services review new departmental web sites for conflicts with these guidelines prior to putting them on the web. Our intention is to continually review and update these guidelines as new information, standards and technologies become available.

1 SRJC Web Guidelines

These guidelines apply to all web pages and sites that are part of the Santa Rosa Junior College (SRJC) College Wide Information System (CWIS) web site.

These guidelines are effective for new material added to CWIS after March 3rd, 20031. The intent is not to force a retrofit of existing materials, but to provide a baseline for review of new materials and to put into a convenient written form the already existing standards.

1.1 Technical Web Guidelines

These guidelines primarily specify standards for the underlying technical aspects of web pages intended for the SRJC CWIS web site.
1.1.1 Required Technical Web Guidelines
These criteria must be met for all web pages at SRJC.
  1. HyperText Markup Language (HTML) must be valid and standard compliant.

    Explanation: http://validator.w3.org/ may be used to check. Be sure to include the version of HTML that is being used, such as in Figure 1, Figure 2 or Figure 3. You may refer to http://www.w3.org/MarkUp/, http://www.w3.org/TR/xhtml1/ and http://www.w3.org/TR/html4/ for detailed information on the individual standards.


    Figure 1: Example HTML 4.01 Strict DTD reference
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"  
            "http://www.w3.org/TR/html4/strict.dtd">
    Figure 2: Example HTML 4.01 Transitional DTD reference
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  
            "http://www.w3.org/TR/html4/loose.dtd">
    Figure 3: Example XHTML 1.0 Strict DTD reference
    <!DOCTYPE html  
         PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  2. If Cascading Style Sheets (CSS) are used, they must be valid and standard compliant.

    Explanation: http://jigsaw.w3.org/css-validator/ may be used to check. You may refer to http://www.w3.org/TR/REC-CSS1 and http://www.w3.org/TR/REC-CSS2/ for detailed information.

  3. All material must be accessible to the disabled, in particular, they must be compliant with section 508.

    Explanation: That is section 508 of the Rehabilitation act of 1973, as amended (29 U.S.C § 794d), specifically the regulations issued by the federal Architectural and Transportation Barriers Compliance Board (Access Board) in 36 C.F.R § 1194.22. These are usually simply referred to as the “section 508 guidelines”. We have received messages from the California Community Colleges Chancellor’s Office explaining the exact legal details (including Senate Bill 105 (Stats. 2002, ch. 1102)), and stating that “The accessibility requirements of section 508 will now apply to the development, procurement, maintenance, or use of electronic or information technology by a community college district using any source of state funds.”

    Explanation: We want our web pages to work for as many people as possible, and this includes the visually disabled. Also, since we receive federal funding we fall under the federal guidelines and are legally required to make pages accessible.

    Explanation: The way that accessibility software for the disabled “sees” your pages is very similar to how automated software such as search engines, machine translators, etc. will see your page. Following these rules will usually also help your pages to show up better in searches, be more easily translated to another language, etc.

    Explanation: Most of these guidelines will also assist with making pages that will work for users utilizing the latest technology, such as web-enabled Personal Digital Assistants (PDAs), cell phones, etc.

    Here are the relevant rules from Section 508 §1194.22:

    1. A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).
    2. Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
    3. Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
    4. Documents shall be organized so they are readable without requiring an associated style sheet.
    5. Redundant text links shall be provided for each active region of a server-side image map.
    6. Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
    7. Row and column headers shall be identified for data tables.
    8. 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.
    9. Frames shall be titled with text that facilitates frame identification and navigation.
    10. Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
    11. A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
    12. 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.
    13. When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
    14. When electronic forms are designed to be completed on-line, 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.
    15. A method shall be provided that permits users to skip repetitive navigation links.
    16. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

    There is a more detailed guide to all of the above rules at
    http://www.access-board.gov/sec508/guide/1194.22.htm.

    We recommend using one or more of the following tools to assist in checking for 508 §1194.22 accessibility compliance, but portions of the rules need to be checked manually; many of these tools have a mechanism to remind you which things you’ll still need to check.

    You may also find additional information on making web sites easy to use for the disabled at these URLs:

  4. Sites intended for the general public must be usable with all versions of Netscape back to and including 4.x, all versions of Internet Explorer (IE) back to and including IE 4.x on both Macintosh and Windows. We also recommend testing with Safari 1.0.

    This does not mean that sites must look exactly the same in all versions of all browsers. It’s okay to make pages that look best only on newer browsers as long as people using older browsers can access the essential information.

    We suggest also testing with Lynx as a verification tool. Lynx is a text-mode browser; to test a page with Lynx log onto student.santarosa.edu or staff.santarosa.edu and type “lynx http://” followed by the remainder of the URL to your testing sub-site. Versions of Lynx for Windows, DOS and MacOS may be downloaded from http://lynx.browser.org/.

    Explanation: Many users continue to use Netscape 4 or IE 4 as their primary browser. They may not be able to upgrade.

    Explanation: Lynx is a very handy tool for checking accessibility; if a site is usable in Lynx it is probably obeying a, c-f, i, k and l of the 1194.22 guidelines. If a site is usable in Lynx it’s probably usable in any other browser.

  5. Each page must have contact information for a permanent employee in the department who can answer questions or forward questions to somebody that can.

    This departmental contact may be an administrative assistant, the department head, the person responsible for maintaining the web pages or anybody else in the department, as long as they can answer at least some questions about the department and know who to forward any other questions, comments or concerns on to.

    This information may be at the bottom of the page. The email address must be included as a link, such as in Figure 4.


    Figure 4: Example contact email link
    <a href="mailto:example&#40;santarosa.edu"  
       title="Email Example Department">example&#40;santarosa.edu</a>
    A generic alias or shared mailbox of the type “deptname@santarosa.edu”, may be used, providing, the mailbox is checked regularly. This contact should not be “webmaster@santarosa.edu”. You may wish to replace “@” with “&#40;” to help discourage spambots. Explanation: Users frequently have questions about departments that are outside of what the Webmasters can answer. Also, the webmasters need to know who to contact in the department if there’s a problem or question.

    Explanation: Research on the credibility (believability) of web sites conducted by Stanford’s Persuasive Technology Lab [11] indicates that the credibility of web sites is greatly enhanced by having contact information clearly presented. A phone number and physical address will also enhance credibility.

    Explanation: For many “lower level” pages this is more optional, but it’s still ideal to have it on every page, as there is no way to control what path a user follows to find your page.

  6. The main departmental page must be identified as such, not simply as “home page”; language referring simply to the “home page” should refer to the CWIS home page (<a href="/" title="SRJC home page">home page</a>).

    Example: The Computing Services home page may be identified as “SRJC Computing Services home page”, “SRJC Computing Services sub-site”, “SRJC Computing Services site”, “Computing Services home” or even simply “Computing Services”, whichever is clearest in the context it is being used in. See Figures 5, 6 and 7.


    Figure 5: Example links
    Visit our <a href="/" title="SRJC">home page</a>  
      for more information about  
      <acronym title="Santa Rosa Junior College">SRJC</acronym>.  
    For more information about related programs, check The  
    <a href="/example/"  
       title="Example Department">Example Department Homepage</a>.

    Figure 6: Example links
    <a href="/">home</a> &gt; <a href="/example/">Example Dept.</a>.

    Figure 7: Example links
    <a href="/">home</a> &gt;  
    <a href="/example/"><acronym  
       title="Example Department With Long Name">EDWLN</acronym></a>.
    Explanation: Keeping the language used consistent throughout the site is important for keeping users from being confused about where they’re going when they click on a particular link.
  7. Santa Rosa Junior College resources may not be used for commercial ventures or solicitations-for-hire which are not part of campus business or activities.

    The primary intent of this guideline is to give web developers a method to avoid conflict with SRJC board policies. When a link takes the visitor to a Web development firm, the linking code listed below must be used to clarify that the user is leaving the SRJC site and that SRJC is not promoting or endorsing the Web development firm.

    Example: Let’s pretend that the “Underwater Basket Weaving” department at SRJC hired a Web Design company to create a Web site for their department. At the bottom of every page there is text stating “Site design by Fabulous Fictitious Web Designers”. That link should use the “/outside” mechanism described in Figure 8 so that a web page will be displayed that announces to the visitor that they are leaving the SRJC site and SRJC does not endorse this company.

    Explanation: Our status as a public institution, the policies of the organization we receive our internet feed from [1], and SRJC board policy [12] restrict the use of our internet connection or web servers in furtherance of profit-making activities (consulting for pay, sales or distribution of commercial products or services for profit, etc.) or use by for-profit companies. Violating these policies may potentially expose SRJC to litigation or suspension of our internet connection. If you develop web pages stored on our servers they should not appear to endorse the sale of goods or services (commercial uses).

    If you are unsure, then the recommended solution is to add “/outside/” or “http://www.santarosa.edu/outside/” to the beginning of the URL, as in Figure 8 or Figure 9.


    Figure 8: Example outside link for a page hosted on www.santarosa.edu
    <a href="/outside/http://www.example.com/"  
       title="Example web site">.

    Figure 9: Example outside link for a page hosted on a different server
    <a href="http://www.santarosa.edu/outside/http://www.example.com/"  
       title="Example web site">.
    This will provide a page warning the user that they are leaving the SRJC web site and then direct the user to the original link.
1.1.2 Recommended Technical Web Guidelines

These guidelines are recommended in all but a very few cases. Exceptions other than those listed can be made, but if you’re not sure, ask first. (webmaster@santarosa.edu) Exceptions are, typically, when the pages are intended only for internal SRJC use, complex dynamic applications and other unusual circumstances.

  1. Pages should have no horizontal scrolling on an 800x600 monitor and should be usable on a 640x480 monitor.

    Explanation: Since web browsers don’t send data on screen size or resolution, we don’t have any accurate information on our own user population. The most recent research available [4] indicates that approximately half of users (in general) have an 800x600 display, 7 percent have a 640x480 display. However, different research has found different answers and we’re working on gathering data on our own user population. The “web kiosks” that SRJC has deployed at many locations mostly have 640x480 displays as well. Most new computers sell with at least an 800x600 display, but it is still possible to buy a new 14-inch display that may be capable of 1024x768, but looks best at 640x480. Even with newer, larger monitors, some users with visual problems will have their monitors set to 640x480.

    Explanation: Vertical scrolling is a minor annoyance, but when combined with horizontal scrolling the combination is extremely hard to use, even for advanced users. Even with no content in the “hidden” portion that users have to horizontally scroll to, users will be tempted to scroll to see what they’re missing, and the scrollbar across the bottom will reduce the vertical space available for your design.

    Be aware that page designs that require a wider monitor will potentially make your site harder to use for some users; the wider the design, the more users the site will be hard to use for.

    At this time, probably the best choice is to fit your design within 760 pixels of width (so that they fit on an 800x600 screen) and verify that the pages are usable on a 640x480 display. It’s best if your design is “fluid” so that on a larger monitor your design will expand to fill the available horizontal space.

    If your users are likely to need to print particular web pages, those pages may need to be designed to fit within approximately 535 pixels of width.

    Even users with a larger monitor may appreciate it if your page design is narrower; for instance, a user with a larger monitor set to 1280x1024 can have two browser windows open (at roughly 640x960 per window) or even 4 windows (about 640x480 per window).

  2. We strongly recommend whenever possible, frames should not be used unless there is a strong (clearly defensible) reason to do so.

    Explanation: Usability testing has shown good evidence that frames confuse users by breaking fundamental model they use to navigate the web. The “Back” button can become unpredictable for the user when frames are used. Frames make a web site more difficult to use and prevent users from readily emailing a URL to others or bookmarking the page. Searches will usually return the individual frames instead of the frameset, which may lack the navigational elements the user would use to find their way around the rest of your site.

    Explanation: Frames may also take longer to design, develop, and maintain.

    Exception: complex, dynamic web applications, particularly ones that are session-based and non-searchable where bookmarks won’t work anyways and external search engines can’t find the pages anyways.

    Exception: Inline frames may be used judiciously as they avoid most of the problems with frames.

  3. Avoid using “pop-up” windows. Particularly avoid new windows designed to take over the entire screen.

    Explanation: Many advanced users have pop-ups turned off in their browser and won’t be able to see your pop-up content easily. Even less advanced users have frequently adopted the habit of immediately closing all new small-window pop-ups because in their experience they’re usually annoying advertisements. New windows that fill the entire screen will confuse new users by breaking their back button; meaning they may not be able to return to your page at all. In many cases the content that you’re linking to is what the user was ultimately looking for, and if not more know how to use the back button than know to use the close button to go back. And if your page isn’t the only page that creates a new window, the user can end up with a confusing “stack” of many windows.

    Exception: complex forms and applications where there is a risk of losing data entered by the user when linking to a small page explaining part of the options. Such a sub-page should be a small simple page that “dead-ends” either with no links or exclusively linking to pages with no links. Links to those pages may want to include “pop-up” or similar text next to the link to warn the user.

  4. If a client-side scripting language, such as JavaScript, JScript VBScript or ECMAScript is used, all essential site features must continue to function without it. For example, if JavaScript is used to implement “roll-over” buttons, when JavaScript is turned off or unavailable, clicking on the link must work. If JavaScript is used to implement a menu, there must be a way for the user to reach the same choices; choices may be on a different page. If JavaScript is used to implement a pop-up, there must still be an href= in the anchor tag so that the link works as a normal link when JavaScript is unavailable.

    Explanation: Many users have JavaScript disabled or are using browsers that don’t support JavaScript. Additionally, JavaScript presents accessibility issues. See section 508 part 1194.22(l) on Page 9.

    Exception: pages intended solely for internal, staff-only use.

    Example: For instance, when making a link that shows a menu, don’t use “href=javascript:”, use onClick and provide a useful href=, as in Figure 10.


    Figure 10: Example (partial) of a menu that works without JavaScript
    <a href="choices.shtml" onClick="menuChoicesOn();">
    Where choices.shtml has the same (or more) options as the menu presented by menuChoicesOn() has.
  5. Adobe PDF (Adobe Portable Document Format) is best used when the exact look and feel of the document is required to be preserved or other features of PDF that are not present in HTML are required.

    We encourage developers to use HTML when possible and PDF when required.

    Exception: PDF may be used for material intended for internal staff use, use primarily by other institutions, forms that must printed, etc. PDF is preferred over formats such as Word or Excel.

    Explanation: While PDF is widely supported on campus and at other similar institutions, not everybody that has a web browser has a PDF reader. PDFs are primarily designed for print and many of the on-screen navigation features that are possible with HTML are difficult or different with PDFs. The PDF reader user interface is different from the web browser interface, and any new user interface may confuse users. Our site search will find content in PDFs, but if a PDF is very long, the user will simply be dropped into the top of the document and have to find the material themselves within the document.

  6. If PDF is used, the PDFs should be made to function with version 4 of free Acrobat Reader.

    Explanation: Version 5 is the current version of the Acrobat Reader, however many users still haven’t upgraded from the version 4 Reader. If you can use extra features that are available in version 5 without negatively impacting the version 4 users, there’s no problem with using those features.

  7. If PDF is used, the PDFs must be produced following Adobe’s guidelines for creating Accessible Adobe PDF Files available at
    http://www.adobe.com/products/acrobat/access_booklet.html; more information on the Accessibility of Adobe products may be found at
    http://access.adobe.com/. Otherwise an accessible alternative must be provided.
  8. If PDF is used, it should be properly distilled and optimized.

    Explanation: PDF files should usually be created in Screen or eBook quality and not Print or Press quality. Screen and eBook quality will usually still print reasonably. Print quality is adequate to produce material as high-quality as most printers people have can produce. Press quality is only for professional prepress output.

  9. We recommend against using Flash in most cases.

    Explanation: Flash is not as universally supported as HTML. Flash content can’t be found by our search engine. Flash content often creates a totally new user interface for each Flash site, which will only confuse users.

    Explanation: Computing Services doesn’t have the resources to fix, maintain, or update Flash content, so be sure to budget for maintenance.

  10. If Flash is used, an accessible alternative must be provided, and the Macromedia Flash accessibility guidelines [7] should be followed.

    Explanation: Macromedia is working on improving the accessibility of Flash, but at this time there is no way to create Flash documents that are accessible enough to meet the section 508 guidelines.

  11. We recommend against using other “plug-in” and “applet” technologies, such as Java for most pages.

    Explanation: These technologies are not as universally supported as HTML, and even where supported there are frequent problems (such as browser crashes and lock-ups), versioning difficulties, competing standards and accessibility issues.

    Exception: Classes on a given subject may have files using that technology. For example, pages about SRJC’s Java classes and pages given to students in a class on Java almost certainly should include examples of Java in use.

    Exception: Any of these may be used if they are on separate pages with links clearly indicating that that technology is used and there must be accessible (preferably HTML) alternatives provided if the technology used isn’t accessible.

  12. If you provide non-HTML content, we strongly recommend that links to that content clearly indicate the format nearby. For files over 100K there should also be a file size. Providing a link where a user can download a viewer for that technology is also a good idea and may be required by section 508 in most circumstances.

    Example: See Figure 11


    Figure 11: Example link to non-HTML content
    <a href="web-guidelines.pdf"  
       title="SRJC Web Guidelines">Web Guidelines</a>  
    (PDF: 293 KB;  
    <a href="http://www.adobe.com/products/acrobat/">Download  
       Adobe&reg; Acrobat&reg; PDF&reg; Reader&reg;</a>)
  13. Pages should be designed to be functional with any modern, standards-compliant HTML browser.
  14. Pages should never be removed, only replaced. If a page must be removed, a .htaccess file should be used to redirect the browser to a page holding the replacement material. When developing a new version of a departmental sub-site, try to replace the existing pages with new equivalent material.

    Explanation: Some users will have the old pages bookmarked and old bookmarks should continue to work. Other sites may have links to your pages. Search engines will take time to notice the new page being added or the old page being removed.

    Example: A new design is put in place for /deptname/ and there is an existing “contact.html” page. Do not remove “contact.html” and put contact information in “contact-us.html”, the new updated contact page should go in “contact.html”. If the new design requires that the new page be named something else, such as “contact.shtml” or “contact.php”, then a .htaccess file should be used to redirect requests from the old page to the new page.

  15. Each main departmental page must have a link back to CWIS home. This may be a logo and/or a text link in the upper-left corner of the page, or at the bottom of the page or both.

    Each sub-page should have both a link to the CWIS home and to the departmental main page, such as “SRJC / Department Name”; further categorization is recommended when used appropriately, such as “SRJC / Department Name / Special Program”. (A trail reflecting the hierarchical structure leading to this page, in other words) Replacing the “/” with a “>” or arrow graphic may be acceptable.

    Exception: session-based web applications where a given URL works for a limited amount of time (or similar situations where leaving the page can cause a loss of data or loss of work) should not have any links back to the home-page or departmental page; such pages may have the “trail” included in the same spot, but without linking.

1.1.3 Optional Technical Web Guidelines
We would like to see these things on web pages, but we will approve pages that don’t meet these standards.
  1. XHTML (Extensible HyperText Markup Language) 1.0 Strict or HTML 4.01 Strict is ideal.
  2. Most ideal is XHTML 1.0/strict with no tables and CSS used for all positioning. (See the source for http://www.wired.com/ or http: //www.w3.org/ for examples.)

    Explanation: Using XHTML/strict (1.1 or 1.0) and stylesheets allows for the most flexibility and future maintainability.

  3. If the above is followed, creating a stylesheet for multiple types of presentation of the document is very nice; see Figure 12.

    Figure 12: Example of multiple stylesheets
    <link rel="stylesheet" type="text/css" media="screen"  
          href="/css/screen-style.css" />  
    <link rel="stylesheet" type="text/css" media="aural,braille,embossed"  
          href="/css/accessible-style.css" />  
    <link rel="stylesheet" type="text/css" media="print"  
          href="/css/print-style.css" />
  4. “Meta name” and “meta keywords” in the head of HTML documents help search engines find your pages; see Figure 13.

    Figure 13: Example “meta name” and “meta keywords” tags
    <meta name="keywords"  
          content="Web Guidelines, HTML, XHTML, CSS, Usability" />  
    <meta name="description" content="SRJC Web Guidelines" />

1.2 Usability

1.2.1 Recommended Web Usability Guidelines

Pages should follow these usability guidelines. When one of these guidelines conflicts with a technical guideline, the technical guideline has priority. When two usability recommendations conflict, the web designer should decide which option provides the highest level of usability for the most people.

  1. All pages should be easily usable by a wide range of users.
  2. All pages should be as resolution-independent as possible.
  3. All pages should be usable on small screens.
  4. All pages should be usable on large screens.
  5. All pages should be usable with a speech-based browser.
  6. All pages should be usable with a screen-reader reading from a browser window.
  7. All pages should have text that can resize. (use relative sizes such as percentages, ems, exs and not pixels, points. Particularly avoid using graphical pictures of words. If graphics containing text must be used, the text should be large enough to be read clearly.)
  8. If fonts are set, either via the “<font face=>” tag or via stylesheets, then one of the generic font families (serif, sans-serif, cursive, fantasy, and monospace) must be provided as a final fallback, such as “Helvetica, Arial, Verdana, sans-serif”, “"Times New Roman", Garamond,serif”, or “Courier,Prestige,monospace”. No specific font is guaranteed to exist on any given system, but these generic font names will pick the closest available font.
  9. All pages should be able to be printed reasonably. This may be done by providing a print version, a print stylesheet marked as such or by using a design that works reasonably well for screen and print, such as a design that fits within 535 pixels width.
  10. All pages should be designed with the idea that they are part of the overall SRJC CWIS site and should integrate into it.
  11. Colors
  12. The size of navigational elements should be kept to a minimum.

    Explanation: Navigation is a necessary element that is not a goal in itself and pushes informational content out of the way.

  13. Reasonable whitespace should be used to separate items to maintain readability.
  14. All content should be marked up by meaning; for example, different levels of heading should use the “<h1>”, “<h2>”, etc. elements with control of appearance relegated to the stylesheet.
  15. All pages should load as fast as possible, even over a 14.4K modem.

    Explanation: Most of our target audience is located in Sonoma County, and in many of the outlying areas of Sonoma County, the maximum data speed that the phone lines will support is 26.6K.

  16. All pages should load in under 10 seconds over a 28.8K modem connection.

    Explanation: The longer the user has to wait for your page to load, the more likely that they will give up and go somewhere else.

  17. The total size of a page, including all elements (graphics, stylesheets, etc.), should be under 40KB and is expected to be under 100KB.

    Explanation: A 40KB page will take at least 15 seconds to load on a 26.6K modem connection.

    Explanation: A 100KB page will take at least 35 seconds to load on a 26.6K modem connection. Even on good phone lines with the best modem available it’s likely to take over 20 seconds to load a 100KB page. With that long of a wait, many users will simply give up.

  18. All pages must be designed so that they are usable with none of the graphics loaded.

    Explanation: This is, essentially, required for accessibility. Additionally it helps make the page usable while the user is waiting for graphics to download, or if the user has turned off graphics loading to speed things up.

  19. The text of all links must make sense (and inform the user what the link is to) when the content of the link is read alone out of context. This means “click here” must not be used.
  20. When possible, all documents and directories should be named in a manner that clearly and concisely represents the resource that is provided. For example, this document should be named “web-guidelines” or something similar, not “page6”.
  21. All page design should look professional and credible. Avoid amateur looking heavy backgrounds behind text, infinitely cycling animated graphics, etc.

    Explanation: Research at Stanford’s Persuasive Technology Lab [11] has shown that visual designs that are professional looking (or look appropriate to their purpose) are significantly more credible (believable).

  22. In general, animation should be avoided, except where it brings attention to an essential element that would otherwise be missed. When used for that purpose, it still has to avoid flashing and should have a limited and small number of cycles.
  23. Introductory, content-free “splash pages” with a single link should be avoided. An informative index page with links to the other parts of that sub-site should be used instead.

    Explanation: A “splash page” simply slows the user down and impedes their progress in getting to the really useful things in your site. In other words, it gets in the way of the user.

    Exception: Sites with a primary purpose of displaying artwork through the web. Most departments should keep any material of that nature down a few layers so that more basic information about the department (services, classes, people, etc.) can be at the top.

    Exception: Sites with a strong reason for needing to warn the user about entering the site. This should be very rare on SRJC web pages.

  24. All pages may provide a link to the SRJC CWIS search page (/search/), a site-wide search box (as in Figure 14)

    Figure 14: Example site search
    <form name="gs" method="GET"  
          action="http://www.google.com/u/santarosa">  
    <input type="hidden" name="hl" value="en" />  
    <input type="text" name="q" size="15" maxlength="2048" />  
    <input type="submit" value="Search" name="btnG" />  
    </form>
    a departmental page search box (Figure 15)
    Figure 15: Example departmental search
    <form name="gs" method="GET"  
          action="http://www.google.com/u/santarosa">  
    <input type="hidden" name="hl" value="en" />  
    <input type="hidden" name="hq"  
           value="inurl:santarosa.edu/deptname" />  
    <input type="text" name="q" size="15" maxlength="2048" />  
    <input type="submit" value="Search" name="btnG" />  
    </form>
    or a separate departmental search page.
  25. If search is provided, the scope of the search must be clear. It is recommended to simply provide a site-wide search; users may be looking for related material that is outside of the departmental pages.

2 Individual SRJC Web Servers

These standards apply only to pages hosted on the particular server.

2.1 www.santarosa.edu

These criteria must be met for pages and sites hosted on the www.santarosa.edu (previously known as “grimmy”) server. This is where most departmental pages are located. Pages with a path that starts with a tilde (“~”) or “%7e” are exempt. Please direct any questions or comments about this server to webmaster@santarosa.edu.
  1. Pages must be easily maintainable by the department’s web contact person and the internet services staff. Preferably with all words as HTML text and not pictures of the words. If images holding words are used, we need versions that can be used to reconstruct and instructions so that new sections can be added, old sections taken out, etc.
  2. All file and directory names should consist only of lower-case letters, numbers, the hyphen (“-”) and the period (“.”). The total length, including extension, of file names must be 30 or fewer characters in length.

    Exception: well-known acronyms.

  3. The extension for HTML pages is “.html”, for HTML using SSI (Server-Side Includes) it is “.shtml”, for JPEG (Joint Photographics Expert Group) graphics it is “.jpg”, for GIF (Graphics Interchange Format) graphics it is “.gif”, for PNG (Portable Network Graphics) files it is “.png”, for PDF files it is “.pdf”, for CGIs (Perl, Python, C, C++, etc) it is “.cgi” and for PHP (PHP Hypertext Preprocessor) it is “.php”.
  4. Supported technologies include Apache 1.3.22, HTML, SSI, CGI, Perl 5.005, Python 1.5.2, PHP 4.2, compiled C, compiled C++ and MySQL databases.
  5. For any technologies (such as C++) where there must be a compiled binary to run, we must be given both the source code and a precompiled binary.
  6. Personal pages (with a tilde (“~”) or “%7e” in the URL) cannot be part of the official SRJC CWIS site; those pages are intended for the personal use of SRJC staff or students. These may be used for development and testing of material intended to be later moved into CWIS, however.

2.2 student.santarosa.edu

Pages at the top level of student.santarosa.edu must follow all the same standards as for www.santarosa.edu. Personal student web pages (with a tilde (“~” or “%7e” in the URL) hosted are intended primarily for use in classes, but also for personal, non-commercial use by students; these pages may also be used for development and testing of pages intended for www.santarosa.edu. Supported technologies are basically the same as for www.santarosa.edu.

2.3 online.santarosa.edu

Pages on the CATE (online/Sisters) server are handled by the CATE project and many of the above standards are automatically handled by the templating system used there. Please direct any questions about this server to webmaster@online.santarosa.edu.

2.4 autobahn.santarosa.edu

Autobahn is primarily intended for interactive applications and web pages maintained by Computing Services. At this time we don’t allow departmental pages to be hosted on autobahn.

2.5 testsys.santarosa.edu

Testsys is primarily intended for interactive applications and web pages maintained by Computing Services. At this time we don’t allow departmental pages to be hosted on testsys.

2.6 busxowa.santarosa.edu

Busxowa is intended solely for the “Outlook Web Access” application that allows staff to read and write emails from a web browser.

Acknowledgements

Many people at SRJC have helped with the creation of these guidelines at various stages of their development. Thank you all.

The primary author and editor of this document has been Eric Eisenhart.

While others have contributed, these nine people have probably contributed the most:

References

[1]   4CNet, “The California State University 4CNet Acceptable Use Policy,” http://www.4c.net/documents/4cnet_policy.html

[2]   Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, Internet Engineering Task Force, Mar. 1997, http: //ietf.org/rfc/rfc2119.txt

[3]   Communication Technologies Branch, NCI, “Research-Based Web Design & Usability Guidelines”, National Cancer Institute (NCI), http: //usability.gov/guidelines/

[4]   Communication Technologies Branch, NCI, “Research-Based Web Design & Usability Guidelines”, National Cancer Institute (NCI), http: //usability.gov/guidelines/softhard.html#four

[5]   Fogg, B.J., “Stanford Guidelines for Web Credibility,” A Research Summary from the Stanford Persuasive Technology Lab, Stanford University, May 2002, http://www.webcredibility.org/guidelines

[6]   Lynch, P.J., Horton, S., “Yale Web Style Manual, 2nd edition”, Yale Center for Advanced Instructional Media, 1997-2002 http://info.med. yale.edu/caim/manual/, http://www.webstyleguide.com/

[7]   Macromedia, “Accessibility: Macromedia Flash MX Features”, Macromedia, Inc., 1995-2003 http: //www.macromedia.com/macromedia/accessibility/features/flash/

[8]   Nielsen, J., “useit.com: Jakob Nielsen’s Website (Usability and Web Design)”, http://www.useit.com/

[9]   Raggett, D., “HTML 3.2 Reference Specification” World Wide Web Consortium, Jan. 1997, http://www.w3.org/TR/REC-html32

[10]   Raggett, D., Le Hors, A., Jacobs, I., “HTML 4.01 Specification,” World Wide Web Consortium, Apr. 1998, revised Dec. 1999, http: //www.w3.org/TR/html4/

[11]   Stanford Persuasive Technology Lab “The Web Credibility Project” Stanford University, http://www.webcredibility.org/

[12]   SRJC Board, “Santa Rosa Junior College Policy Manual,” http: //www.santarosa.edu/polman/

[13]   SRJC Board, “Santa Rosa Junior College Mission Statement,” 1985-2001 http://www.santarosa.edu/polman/1mission/1.1.html

[14]   W3C HTML Working Group, “W3C HyperText Markup Language (HTML) Home Page,” World Wide Web Consortium, 1995-2003, http: //www.w3.org/MarkUp/

[15]   W3C HTML Working Group, “XHTMLTM1.0 The Extensible HyperText Markup Language (Second Edition),” World Wide Web Consortium, Jan. 2000, revised Aug. 2002, http://www.w3.org/TR/ xhtml1/

[16]   W3C Validator Team, “W3C MarkUp Validation Service,” World Wide Web Consortium, 1994-2003, http://validator.w3.org/