WEB
STANDARDS
...TEC
HNOLOGY
FOR
NEW
WEBSI
TES
OR
MAJ
OR
ADDI
TI
ONS/
UPDATES
WEB
DEVEL
OPMENT
PROCESS
...
RESEARCH
gatheri
ng contacts, goal
s,
purpose, needs, content
& other i
nfo
PLANNI
NG
creati
ng si
temap and wi
re frames
for department contact to OK
DESI
creati
ng photoshop desi
GN
gns
for department to OK
DEVELOPMENT
devel
opi
ng out desi
gns i
nto a
functi
onal
websi
te i
n si
te manager
TESTI
NG
&
DEPLOYMENT
test on students, revi
ew responsi
veness of
content l
ayout, cross-browser testi
ng, val
i
dati
on
and functi
onal
i
ty testi
ng before goi
ng l
i
ve
MAI
NTENANCE
work wi
th department contact to
keep content updated and rel
i
vant.
conti
nual
l
y revi
ew si
te for usage,
usabi
l
i
ty, accessi
bi
l
i
ty, responsi
veness,
desi
gn trend changes and other needs
... and repeat for any new maj
or
SAT Web Standards
The following standards will give all web designers and developers a standard process
so we can all easily find and update each otherʼs work. These standards will also help
increase usability, accessibility and search engine optimization of student affairs websites. All WSU websites need to meet Section 508 Accessibility requirements. www.section508.gov
>>> Saving Structure <<<
1. Follow the Saving Structure Outline.
Saving files in identified folders allows for ease of maintenance and better organization.
2. All assets will be saved on WebDev.
Whether the website is in the CMS or developed on a different server, all files we have for every project need to be saved on WebDev in a folder called the
directory name. This will serve as a backup for all live files in Site Manager (or on another server) and will also house all working files. Follow the saving structure outline when saving files in the folder.
3. File Names:
No more than 4 words Use lower-case letters
No spaces or random characters
Use hyphens (not underscores) to separate words if necessary
>>> Design <<<
1. Use Adobe Photoshop.
All designs should be created in Photoshop with well-organized layers.
2. Use Adobe Illustrator for any logo design and InDesign for any print.
Graphic Designer may create requested graphics matching larger campaigns in InDesign.
>>> Navigation <<<
1. Navigation should be text.
Sometimes images may be an exception to the rule, but definitely no flash nav
2. No moving navigation.
Navigation items should not move on active or hover.
3. No mystery navigation.
User should always know where nav is and where it will take them without having to roll over or click on anything to find out.
4. Obvious link home.
Users need a clear “exit” at all times to get back to where they started. The logo needs to link to the department home page and be sure to make the first nav item a link back to the department home page.
5. Navigation highlight on corresponding page.
If possible, keep corresponding navigation item highlighted when on the page so users know where they are. Site Manager does not allow this so you will not see it on websites in Site Manager.
>>> Development <<<
1. If developing a website that will not be in the CMS – See Dani
If you are building a website from scratch that will not be part of the CMS, meet with Dani first. This will be very rare.
2. If developing advanced tools for content area of CMS template:
Quite often you will have to work in HTML mode in the CMS to build out the content area of a design. Make sure you are not working on a live or original CMS page incase you run into any issues. You may use Dreamweaver to help you build something and then copy the code into the CMS, but hand-coding via HTML mode is preferable.
3. Comment your code.
Your HTML should have comments that mark important areas in your code such as the start and end of a div section. This is helpful for others who have to update your code later. (HTML comment: <! -- comment here -->)
>>> Copy <<<
1. WSU websites use Trade Gothic and PMN Caecilia.
See weber.edu/brand/webfonts.html for more font resources.
2. Text color must have good contrast with background color.
Good contrast of foreground and background colors allows users to more easily read text. For large bodies of text, the best contrast is black text on a white background. Never use white text on a black background for large bodies of text. Keep in mind that color blindness is common. Be careful about using common colorblind colors together such as red and green because there would be no contrast to a user who only sees shades of grey when looking at red and green.
Red more colourblindawareness.org/colour-blindness/types-of-colour-blindness
Also, never use color as a call to action: “click on the red button to continue” – obviously if someone cannot see red or cannot see at all, this would not be a helpful direction.
3. Do not use the term “click here” for your link. All links needs to make sense out of context.
• Many web users skim the page content to find what they are looking for
• Viewing impaired users with screen readers often pull all links out of
context into a link box to search through links
• Search engines spider through your webpages via page links and use the
words in the links as reference
• Your links should include key words in the link text that tell both users and
search engines where the link will take them.
4. Use already defined/branded button and icon classes instead of creating your own.
Button: weber.edu/uistyleguide/buttons.html
Icons: weber.edu/uistyleguide/icons.html
5. Do not open links in a new browser window.
The majority of web users use the back button to navigate on a site. If a link opens in a new window, the user often does not notice or understand that a new window has opened and may get frustrated when they cannot use the back button.
Even if the link leaves your website, do not open it in a new window in an attempt to keep users on your website!
Exceptions to the rule (when to open a link in a new window):
• Opening a page containing context-sensitive information, such as help
instructions, or an alternate means of completing a form, such as a
calendar-based date picker, will significantly disrupt a multi-step workflow, such as filling in and submitting a form, if the page is opened in the same window or tab.
• The user is logged into a secured site, and following a link to a page
outside of the secured scope would terminate the user's logon. In this case opening external links in an external window allows the user to access such references while keeping their login active in the original window.
• If the link is opening a Word Document or PDF, then it may open in a new
window because research has shown that users often close out of a downloaded document instead of trying to use a back button.
Let the user know via a title tag in the HREF tag that the document will be opening in a new window: “PDF will open in a new window”
6. Do not underline text that is not a link.
Web users expect text that is underlined to be a link. If you want to emphasize text, use formatting techniques such as bold or italicize.
7. Do not double space between sentences.
It is a web standard for all sentences to have a single space separation after the period.
8. Keep content simple and concise.
Web viewers are often impatient. Get to the point, remove unnecessary jargon and uncommon vocabulary that may slow the reader down or turn them away.
Online content is moving more toward casual communication.
9. User short paragraphs and sentences.
Keep paragraphs to 3 or 4 short sentences to allow for quick reading, the ability to scan content, and better digestion of bits of information.
10.Use upside-down pyramid style.
Add the most important information toward the top of your content, as many users will not read all of the content on the page.
11.Keep text left-aligned.
It is hard to read large amounts of centered or justified text, especially on a
computer screen. Please keep blocks of text left-aligned – you may center-align a header if preferred (but not recommended).
12.Correct spelling, grammar and style.
All copy sent by client must be reviewed for spelling and grammar issues along with correct formatting for the web and make sure copy follows WSU Style Guide
rules. weber.edu/marcomm/Styleguide.html
13.All pages must have a clear path to conversion goal.
Copy must point users to complete the goal surrounding that page or the website as a whole. Whether it is signing up for advising, registering for an event, or getting users to view hours or scholarship opportunities, users should have all the information they need and there should be a clear call to action so they know what they need to do next.
14.No duplicate content.
Do not copy and paste text from another website or repeat your own copy across your website. Not only is it bad practice, but search engines may suspect the website of black-hat SEO tactics and black list the site.
15.Divide content using headers.
Separating content with clear headers is essential for allowing quick scanning and proper hierarchical page structure.
Every page has a heading 1 (H1 tag) as a page title to tell the user what the
over-all page content will be about. There can only be one H1 in a page and it should be the very first item on the page. The CMS templates have H1 built in as the editable title area – so be careful not to repeat the H1 if you add in a title in the CMS.
All content after the H1 is organized into sections with H2, H3, H4 … headings as demonstrated in the example below
In the CMS, select the text you would like to be a header and click on the down arrow of the “paragraph style” field to select the heading. The headings are automatically styled for you.
Do not use a heading element just for the formatting if it is not actually a designated heading element. If you want to highlight text that is not a heading element, use the formatting tools or create a style. See pre-determined font
styles: weber.edu/uistyleguide/font-sizes.html
>>> Tables In HTML <<<
1. Try to use tables just for information display.
Tables were never meant for layout purposes, but are often used for layout because they are quick and easy to visualize. However, tables add unnecessary code and can cause issues for visually impaired users with screen readers (if they are not displaying information meant for a table). Instead use divs with css created alignment and formatting when possible. If unknowledgeable staff will be maintaining their own websites, you may have to go with table format for ease of updating – check with Dani.
2. Use TH elements to represent table headers.
A screen reader reads tables left to right, top to bottom. This may get confusing to a user who cannot see the table as they cannot reference the header that the content being read to them is referring to. By changing the header TD row to TH, the screen reader knows to repeat the TH header before reading the
corresponding table content. Search engines also know to look for the TH tag to grab key words that represent the table content.
It is also helpful to add a caption and summary that explain the purpose of the table to visually impaired users who cannot view the table as a whole to get a good understanding of the content being displayed.
Table Code: http://www.w3schools.com/html/html_tables.asp
3. Make Sure Your Tables are Responsive.
Tables need to work in multiple screen sizes/devices just like the rest of the website. There are two pre-determined ways the table can decrease in size. Use the correct class depending on the layout and specific needs of your
informational table: weber.edu/uistyleguide/responsive-tables.html
>>> Images In HTML <<<
1. Use text instead of images as often as possible.
Because we are limited to web-safe fonts on the web (unless you add in Google Fonts), it is tempting to use a decorative font graphic instead of HTML text.
• While search engines and screen readers can read the alt tag
(description below) of an image, they prefer HTML text.
• Graphics add to page size. The more graphics you have, the larger in
size your page is which makes download times longer. Users and search engines prefer fast downloading pages.
2. All photos/images added to a website need to be 72dpi and sized.
You cannot just upload a photo to the CMS right from your camera, it has to be shrunk to a web display size or it will take too long to download. Site Manager demands that photos be sized before loading – you cannot upload an image and shrink it in Site Manager to fit a specific size.
3. All images need to have an “Alt Tag” (alternative text).
cannot see the image and also for search engines. The Alt text is added through the Properties in the CMS. By default the CMS adds an empty Alt to all images. The empty Alt tells a screen reader that this image is of no importance so it skips the image. This is preferred for any graphical elements that are purely for design and serve no purpose. However, if you add a picture or a graphic button with text, make sure to change the empty Alt to beneficial text.
4. Limit rotating banner images to five.
When we create the rotating banners (or anything that rotates), we will not exceed five. Recommend to staff that they not exceed five photos because they add to the page size, which will take the page longer to load. (Also, no one really sticks around much longer than three rotations!)
>>> Flash/Video/Audio <<<
1. Provide alternative content for all audio/video/flash.
Nothing should be provided purely by flash, audio or video that is not represented by text elsewhere:
• Video: captions need to be added or provide link to Word Doc of text
used in video.
• Audio: provide link to Word Doc of text used in audio.
• Flash: an image should appear behind flash presentations that links
users to an alternative means of getting the same information. Do not use the default flash embed that asks the user to download flash.
• Use javascript alternatives to flash whenever possible.
If you absolutely have to use flash, here is how to insert flash correctly: http://www.alistapart.com/articles/flashsatay/
>>> PDFs <<<
1. All PDFs need to be created from Word Docs – they cannot be scanned or
created from images.
2. Just like HTML, Word allows for users to add many accessibility options such as
providing Alt tags for images and using headings correctly.
3. Do not create the PDF by printing to PDF. The Word Doc has to be saved as a
>>> HTML Page Properties <<<
1. Page Name (see saving structure standard)
2. Page Title
Title should explain what the page content is about in under 60 characters (includes spaces)
Search engines look for keywords in page titles for search results.
In the CMS, the page title is also used to create the name of the page in the navigation. Therefore, it has to be short and to the point.
3. Page Description
Description explains what the content on the page is about in more detail than the title – do not just repeat what was entered for the title – this should be done in under 150 characters (including spaces).
Sometimes browsers take the page description to display in search results (more often they take content on the page that better matches the search terms).
Facebook displays the page description when you add a link to a website to your wall.
>>> Cross-‐Browser & Validation <<<
1. Sites need to work in all major browsers.
If you are building a site outside of the CMS or have done major updates to the HTML in the CMS, check that your webpage works in the following browsers:
• Most recent version of Firefox
• Most recent version of Chrome
• Most recent version of Safari
• Internet Explorer 7 and up
2. Websites need to validate.
W3C provides validation tools for your CSS and HTML. The validation tools check your code based on the dtd you have assigned the document to make sure that the HTML (4, XHTML, 5) does not have any errors. Sometimes with dynamic sites or ecommerce, it is impossible to completely validate, but you can always see if there are any errors that you can fix on your end.
>>> Forms <<<
Most forms for WSU websites will be built in Google Forms. For those projects that need a more robust form, please follow these best practices:
1. Order labels logically (name and contact info first).
2. Group content (headed by appropriate heading – probably h2) for ease of
scanning.
3. Be careful not to lead users to answer the way you may want them to answer
(do not pre-check any boxes and watch language).
4. Each label should address one topic at a time.
5. Remove unnecessary fields! If it is not mandatory, maybe it should not be on the
form! We can use the * to highlight required fields (as long as there is a clear key).
6. Use clean alignment.
7. Almost always left-aligned content (except for right-aligned against fields and
8. You will likely have to use tables for a clean layout of more complex forms. Please only use tables if you have to.
9. Fields must be long enough for the user to type in required data and be able to
see it all. Generally at least 20 characters for first and last name fields.
10. All fields should have a descriptive label and be very clear what is wanted from
the user.
11.Use colons after label (old screen readers rely on colons to indicate a label).
12.Users should be able to tab through fields in the same hierarchical manner as a
user would manually click in each field to complete the form.
13. Add a focus style to the fields that highlights which field the user is currently in (I
think most modern browsers do this automatically).
14.If the form is long and goes through multiple pages, clearly identify the userʼs
progress through a form so they know how much more they have to complete.
15. All formatting examples for completing a field need to be outside of the field so
they do not disappear when the user clicks in the field (it is easy to forget).
a. Make formatting examples smaller in font size and a darker grey so that it
is properly separated and does not complete with other text on the page.
b. Unless an email needs to be a specific domain (sometimes we need to
use just Weber emails) you do NOT need to add an example of email format.
c. If possible – have the form auto complete the correct formatting (so we do
not even have to give the user correct formatting examples).
16.Forms should have validation that shows the user missing required fields on
submission. This validation should not take users to another page – but highlight on the existing page what they need to complete.
a. All errors need to be informative and clearly visible.
17. Use a CAPTCHA it applicable.
18. Be descriptive in “submit” button – what does it mean when the user clicks the
submit button? Example: Submit Nomination or Join Purple Pals or Login.
19. Successful form submission should take the user to a page that tells them that
their form was successfully submitted and any more information they need to know such as – we will get back to you by “such a date” or driving directions to the event …
>>> Do Not Use <<<
1. Flickering or blinking objects
2. Font Tags
3. Frames (unless okayed with Dani)
4. Color as a means to understand or navigate a site (exp: “click on the red button
to continue …”)
5. Un-necessary amounts of code – only add it if it serves a purpose – if you are not
sure, check with Dani
6. Just because you can do something “neat” does not always mean you should!
Discuss any “cool” features you found and want to use with Dani before implementing them on a website.