standards for web development

Government of Newfoundland and Labrador

Office of the Chief Information Officer

Solution Delivery Branch

Enterprise Architecture Web Development Standards

GUIDELINES ON IMPLEMENTING STANDARDS FOR WEB DEVELOPMENT

(WEBSITES AND APPLICATIONS)




Enterprise Architecture Web Development Standards

TABLE OF CONTENTS

Overview ....................................................................................................................................................... 3

Consultations with Solution Delivery, Enterprise Architecture Web Development Lead ........................ 3

Solution Delivery, Enterprise Architecture Web Standards Evaluation .................................................... 4

Recommended Approach ............................................................................................................................. 4

During the Initial Planning phase .............................................................................................................. 4

Designing the Website or Web Application .............................................................................................. 5

Testing / Preparing for Product Review .................................................................................................... 5

Appendix A Website Usability Checklist .................................................................................................... 6

Architecture and Navigation ..................................................................................................................... 6

Layout and Design ..................................................................................................................................... 6

Content and Readability ........................................................................................................................... 7

Forms and Interaction ............................................................................................................................... 8

Appendix B Website Accessibility Guidelines ............................................................................................ 9

Web Content Accessibility Guidelines (WCAG) ........................................................................................ 9

Accessibility Testing ................................................................................................................................ 10

Appendix C Web Application Guidelines ................................................................................................. 11




Enterprise Architecture Web Development Standards 3

OVERVIEW

This document is meant to provide a recommended approach to Project Teams for developing websites

or web applications which adheres to Solution Delivery, Enterprise Architecture Web Standards

including guidelines for usability and accessibility.

Project Managers are responsible for ensuring Web Developers and Departmental Representatives

implement web standards, follow recommendations, and address concerns raised by the Solution

Delivery, Enterprise Architecture Web Development Team Lead.

The recommended approach outlined in this document assumes that the project team will consult with

the web development team during the project development.

1. During the initial planning phase;

2. When the conceptual design has been decided upon;

3. When the site or application is complete prior to launch and/or a vulnerability assessment (if

applicable); and

4. Review any edits or changes recommended from the review in section 3 if applicable.

The Web Development Team may be contacted at any time throughout the development process if a

consultation is required.

CONSULTATIONS WITH SOLUTION DELIVERY, ENTERPRISE ARCHITECTURE WEB DEVELOPMENT LEAD

The consultations are intended to allow the Web Development Team Lead to identify any issues or

concerns in the early phases of the projects development thus avoiding timely and costly delays.

1. During the initial planning phase

The Project Manager should meet with the Web Development Team Lead to give a general

overview of the project. The Web Development Team Lead will provide guidance on a

recommended approach and adherence to SDEA Web Standards. The consultation can be

arranged via the Enterprise Architecture Prime that will be assigned to the project.

2. When the conceptual design has been decided upon

The Project Manager should submit sample screenshots to the Web Development Team Lead

who, in turn, provides feedback on the overall design of the website or web application. Any

concerns raised by the Web Development Team Lead should be addressed before moving

forward to the next phase of development.

3. When the site or application is complete prior to launch and/or a vulnerability assessment (if

applicable)





The Project Manager provides a full walk-through of the website or web application to the Web

Development Team Lead. This walk-though is intended to provide a more detailed analysis of

the website or web application and to identify any issues or concerns that could not be

identified using the screenshots provided during the design phase. Any concerns raised by the

Web Development Team Lead should be addressed before moving forward to the next phase of

development.

4. Review any edits or changes recommended from the review in section 3 if applicable

Further consultations may be required depending on the complexity of the project or if the

requirements/design is re-considered later in the development cycle.

SOLUTION DELIVERY, ENTERPRISE ARCHITECTURE WEB STANDARDS EVALUATION

The Web Development Team will review and evaluate the completed website or web based application

for a final time when all consultations are complete and all recommendations have been implemented.

The newly completed website or web application will be tested to ensure that it meets an expected and

acceptable level of compliance. The Web Development Team Lead will provide feedback to the project

team regarding the results of the testing and evaluation and provide sign off for a site or application to

go live from the standards perspective where applicable.

RECOMMENDED APPROACH

DURING THE INITIAL PLANNING PHASE

During this phase of development the project manager should obtain and become familiar with all

documentation related to web standards as well as schedule a consultation with the Web Development

Team Lead to discuss the project.

Before you begin

The Communications division of Executive Council must be informed of all new government websites. As

well, all new URLs must be approved by the Communications division before registering or publishing a

new domain.

Obtain approval for new website and new URL (if applicable) from the Communications

division, Executive Council.

Obtain and read web standards documents from OCIO website

http://www.ocio.gov.nl.ca/ocio/itresources/index.html or by contacting Web Development

Team Lead.

Read and become familiar with the Appendix A Website Usability Checklist to understand





what the Web Development Team will be testing for.

Read and become familiar with the Appendix B Website Accessibility Guidelines to

understand what the Web Development Team will be testing.

If building an application: read and become familiar with the Appendix C - Web Application

Guidelines so that you know what the Web Development Team will be testing.

Schedule a consultation with the Web Development Team Lead to discuss the project. The

Web Development Team Lead will provide guidance on a recommended approach and

adherence to OCIO standards.

DESIGNING THE WEBSITE OR WEB APPLICATION

During concept design, a user centric approach is recommended.

Guiding Principle User Centric Design

When designing a site or organizing content, it is important to consider the perspective of the

people who visit your site. Too often, websites are organized and labeled based on the

structure and jargon of the organization that created it. Ensure that webpages, links, labels, et

cetera, use language that makes sense to your target users.

Also, when developing the information architecture for a site, consider a structure that makes

sense to your primary users.

For a website to be a success the user must be able to easily find information or perform a task.

No matter what objectives you have set for your website, it must carefully balance the needs of

users and the needs of your organization. If users don't find your website helpful, they will not

use it.

The concepts of user centric design must be a priority when developing any website or web

application.

Compiled partly from the following resource: http://www.usability.gov/basics/ucd/index.html

TESTING / PREPARING FOR PRODUCT REVIEW

The following Appendices will outline the typical items the Web Development Team will recommend

and will be evaluating during product review.





APPENDIX A WEBSITE USABILITY CHECKLIST

ARCHITECTURE AND NAVIGATION

Can you tell where you are in the site? Navigation breadcrumbs are used when appropriate.

Can you tell where you can go in the site? Navigation elements are clear, easy to find and

consistent.

Are there a reasonable number of navigation choices? Too many may be overwhelming but

enough are required to cover the necessary topics.

Do link names match page names for main navigation elements?

Is it clear what elements are links and what arent? Links are clear, different colour, underlined,

etc.

Do all link phrases make sense when read out of context? No links with "click here" or "more"

used as text.

Is there a link back to the site home page on all pages?

Do all links lead to the proper destination? No broken links.

Is there an option to search for information? Search option is easily found and gives meaningful

results?

Does each page have a title tag that matches the pages headline?

Is contact information easy to find?

Has the META data been included?

LAYOUT AND DESIGN

Does the site have a consistent, clearly recognizable "look-&-feel"?

Does the page fit the window size horizontally using responsive design? Horizontal scrolling

should be avoided.





If graphics are used, do they enhance content or lead to a better understanding of the

information being presented?

Is the layout uncluttered?

Is there good colour contrast?

Is there a clean background? Should not be busy or distracting. No text on pictures.

Is the main body content black text on white background?

Is the user able to easily increase text size?

Does the logo link back to the home page?

Do you have enough white space? Too many elements placed too close together may

overwhelm visitors.

Have you tested the site on multiple browsers, adaptive technologies and handheld devices

(where applicable)?

Emphasis is used sparingly. Use the minimal amount of emphasis to make the point.

CONTENT AND READABILITY

Is the purpose of the site clear and understood by the user within seconds?

Is the inverted pyramid writing style used, starting with the conclusion? Is important content

close to the top of the page?

Is language used in a way that is familiar to and comfortable for its readers?

Is the text clear and concise?

Is the text sans serif?

Is the text legible? Avoid using all caps.

Are key concepts emphasized?

Is text broken up into chunks for easy scanning using headlines, bullets, lists and frequent





paragraph breaks?

Is the site free from typos, spelling or grammar errors?

Do page errors give useful information? 404 pages or unexpected search results should be

avoided.

FORMS AND INTERACTION

Do forms support the task?

Do dialogues follow logical progression?

Is it clear where to go next?

Is there a clear Submit button?

Does the form collect personal information? If so ATIPP approval is required.

Note: Determining if an ATIPP review is necessary should be determined early in the process.

Remember international users and don't require information they may not have - like area codes

or postal codes.

Have you completed the Accessible Forms Checklist? (Located in Appendix B)





APPENDIX B WEBSITE ACCESSIBILITY GUIDELINES

WEB CONTENT ACCESSIBILITY GUIDELINES (WCAG)

The Web Content Accessibility Guidelines are available on the W3C website at

http://www.w3.org/TR/WCAG20/. All websites and web applications should satisfy all applicable

checkpoints outlined in the following document:

http://www.w3.org/TR/WAI-WEBCONTENT/checkpoint-list.html.

Accessible Forms Checklist

If the web site or application contains a form, the developer must complete this checklist to ensure that

the form is usable and accessible to all users.

Use label for and id to associate form elements.

Another benefit from the use of the label tag is an increase in the size of the area that can

be clicked to access the form control.

e.g. Name

Avoid using tables to lay out forms.

When it is necessary to use tables, the layout of the form must provide a close

relationship, in HTML-table terms, between the form label (request or prompt) and the

input element.

Place the both the form label and the input in the same cell or in horizontally adjacent

cells.

Use the HTML4 elements and to group together like elements.

A form where different elements are well organised with similar elements grouped

together is easier for everyone to use.

The tabindex attribute allows you to specify the tab order for a web page.

In order for this to be effective all elements in the form much have the tabindex specified.

This is not required but should be used as a back-up device. If the page is laid out

effectively, the desired tab order will be natura.

All forms must be keyboard accessible.

CSS should be used to change the curser for mouseovers on label elements.





This clearly indicates to the user that there is an expanded clickable area.

Do not rely on colour to make something stand out (e.g. an error message in a form).

Avoid using organisational jargon or code for error messages.

Error messages should provide an indication of the problem and offer advice on how it

might be corrected.

Whenever possible avoid having the forms require a timed response.

Condensed from: http://www.usability.com.au/resources/forms.cfm

ACCESSIBILITY TESTING

If the site is small, visit every page and attempt to use every link. If the site is too large to reasonably do

this, create a list of tasks that users will most likely attempt on your site and perform them:

1. as you normally would, with a mouse 2. using keyboard only 3. using a screen reader

Be sure the tasks cover all elements of your site such as forms, data tables, multimedia elements, etc.

Completing these tasks shouldnt require users to do things such as pressing Tab a high number of times

before reaching main content or listening to navigation and other layout items before getting to the

content.

Avoid: - confusing navigation - complex language when it could be simpler - having to tab through long lists before getting to main content - vague link text - multimedia that cannot be controlled by all users - anything else that makes it harder for people to use the site





APPENDIX C WEB APPLICATION GUIDELINES

Where applicable, ensure static potions of application design adhere to the Government of

Newfoundland and Labrador Web Standards located at

http://www.ocio.gov.nl.ca/ocio/itresources/OCIOWebStandardsforGNLWebsites.pdf.

Applications should follow design standards as put forth by the World Wide Web Consortium W3C

http://www.w3.org/.

Important Note - Vulnerability Assessment (VA)

Approval from the Web Development Team for application design look and feel, accessibility,

and usability factors must be received prior to the commencement of a Vulnerability

Assessment (VA) as in some instances, changes to the look and feel or static pages may affect

the core design of an application.

Application opening page

Applications should have an opening web page coded in static HTML. This page should include a link or

login to the application as well as two additional options to access the services provided by the

application in the event the application is not accessible for any reason (ex. phone number, email, etc.)

This page should be viewable using any browser or device regardless of any requirements (such as java,

internet explorer, etc.) for the application itself.

Opening page is coded using HTML and CSS and has been tested in all common browsers and

devices.

Static portions of the application are coded using HTML and CSS.

The option to resize text is available.

The Government of Newfoundland and Labrador brand signature is present and has proper

placement on all screens/pages.

The Government of Newfoundland and Labrador web standard colour scheme is implemented on

all screens/pages.

The main body content contains black sans serif text on white background.

New windows do not open other than to take a user outside the current application or to display

a PDF.

Help files are available from all pages/screens.





Clear language is used.

Screens/pages are consistent.

In instances when an unable to log in or similar message occurs, a prompt for next steps is

generated such as contact administrator at 555-5555 etc.

Error messages provide next steps to help the user.

Instructive hints and tips are provided.

Graphics are used according to the Government of Newfoundland and Labrador web standards.

If this application has a parent site, there is a clear link to the parent site and the look and feel

mirrors the parent site.

This application has been tested using adaptive technology, multiple browsers and handheld

devices (where applicable).

Compiled partly from the following resources: - UserEffect; University of Minnesota Duluth; UX Booth; Virtual Hosting





Guidelines on Implementing Standards for Web DevelopmentTable of ContentsOverviewConsultations with Solution Delivery, Enterprise Architecture Web Development LeadSolution Delivery, Enterprise Architecture Web Standards Evaluation

Recommended ApproachDuring the Initial Planning phaseDesigning the Website or Web ApplicationTesting / Preparing for Product Review

Appendix A Website Usability ChecklistArchitecture and NavigationLayout and DesignContent and ReadabilityForms and Interaction

Appendix B Website Accessibility GuidelinesWeb Content Accessibility Guidelines (WCAG)Accessibility Testing

Appendix C Web Application Guidelines

standards for web development

Documents