APPENDIX L

WEB APPLICATIONS USER INTERFACE GUIDELINES

Commonwealth of Pennsylvania

Department of Environmental Protection

Bureau of Information Technology

Applications Support Division

User Interface Guidelines

Table of Contents

1.Introduction

1.1Overview

2.Guidelines

2.1Summary of OA OIT Web Site Standards

2.2Standard UI Elements

2.2.1Labels

2.2.2Text boxes

2.2.3Check boxes

2.2.4Radio buttons

2.2.5Command buttons

2.2.6Drop-down list

2.2.7Field set

2.2.8Links

2.2.9List boxes

2.2.10Tables / Grids

2.2.11Custom Controls

2.3AJAX

2.3.1Standard Framework

2.3.2Usage Guidance

2.3.3Issues

3.Accessibility

3.1Rules Summary of OA OIT Accessibility Standards

3.1.1Alternatives and Association

3.1.2Color

3.1.3Dynamic Content

3.1.4Navigation

3.1.5General Considerations

3.1.6Links

3.1.7Special Device Accommodations

3.1.8Essential Document Attributes

3.1.9Scripts

3.1.10Document Design & Style

3.1.11Tables

3.1.12Elements & Behaviors to Avoid

User Interface Guidelines

1.Introduction

This document provides guidance for the design standards for DEP Microsoft projects User Interface (UI). It is derived, in part, from the OA ITB standards, and will be enforced through manual inspections a code reviews.

1.1Overview

The objective of this UI guide is to

  • Promote proven design principles.
  • Promote consistency in the eGrants UI
  • Require a unity of style.
  • Provide guidance on which UI element to use for collecting a given type of data.

2.Guidelines

Please refer to the standards set by OA OIT, which can be found here:

  • ITB APP005: Commonwealth of Pennsylvania Web Site Standards
  • STD APP005A: CoPA Website Standards

2.1Summary of OA OIT Web Site Standards

ITBAPP005 and APP005A are summarized here. Please refer to the actual documents for details and to check for updates to the standards.

  • Consistency is the key to a user friendly site. Things like style (look & feel), page organization, navigation, help & error messages and input elements should be consistent throughout the entire site.
  • The site navigation should indicate to the user where they are in the site.
  • Users should be provided an easy way to return “home“
  • Commonwealth sites share a common branding. APP005A specifies common elements to be used for the header, footer, and side navigation. See the DEP home page for an example (
  • Make an effort to keep page sizes relatively small (100KB on average) to provide reasonable download time.
  • Tools like Firefox’s “YSlow” add-on can be used to measure page size.
  • Page length is to be limited to no more than two 1024- by 768-pixel screens worth of information
  • Link descriptions are to aid users to locate relevant information; the text should be description and intuitive. Avoid non-descriptive text like “Click Here”
  • Define acronyms and jargon.
  • Consider using the <acronym> tag with the “title” attribute set to the acronym’s definition.
  • Consider the effect on download time of the images included on the page.
  • Non-Commonwealth advertisements or Web page sponsorships are not to be used until a business case is presented to, and approved by, the Deputy Secretary for Information Technology.
  • Persistent cookies are not to be used.
  • Frames are not to be used.
  • Graphics’ resolution should be no more than 72 pixels per inch

2.2Standard UI Elements

In order to promote site consistency, this section defines standards for the UI elements to be used depending on either the input type or the data being displayed on the screen.

2.2.1Labels

Labels are used to provide a description and purpose of an input element.

  • Assign a descriptive label to every text box.
  • Avoid acronyms or abbreviations unless you are sure all users will understand them. It is okay to use multiple-word text box labels; however, keep them concise.
  • Capitalize the first letter of the initial word of a label. Place labels for text boxes to the left of the box. Avoid placing labels on top of text boxes.
  • Align text box labels on the left. Do not right-align labels. Right-aligned labels produce a ragged left margin, which is hard to scan.
  • Use a colon after text box labels to distinguish between the label and the data that follows. Allow space between the colon and the text box for the longest label. Do not use colons after group frame names or column headings.

2.2.2Text boxes

Text boxes allow users to display, enter, or edit a text or numeric value and are the main way for users to type in data.

  • If data is for display only and cannot be changed or added, use a label, not a text box.
  • If a particular text box is temporarily protected, gray out the box and label to signify that data cannot be entered or changed at this time.
  • Size text boxes to indicate the approximate length of the field.
  • If you have text boxes that all pertain to similar information, group them together in a field set and label the entire group.

2.2.3Check boxes

Check boxes allow users to make a decision between two or more clearly differing choices.

  • Use check boxes when users can choose one or more options.
  • Use check boxes when users are toggling a feature on or off.
  • Place check boxes together in a group.
  • Limit a check box group to ten or fewer choices.

2.2.4Radio buttons

Radio buttons allow users to make a single choice among a set of mutually exclusive, related choices.

  • Place radio buttons together in a group.
  • Use a field set to show the group and use a descriptive label for the entire group.
  • Limit option buttons to six or fewer choices. If you have more choices, consider using a single selection list box or drop-down list box instead.
  • If users need to make yes/no or on/off choices, use a single check box rather than option buttons.

2.2.5Command buttons

Command buttons allow users to perform an immediate action and are the primary way that users take action on a form.

  • Use command buttons to convey to users the major actions of a particular form.
  • Users should be able to glance at a form and know what to do there and what to do next, based on the names and placement of the command buttons.
  • Choose specific labels for certain functions and use these labels throughout an application and from one screen to another. For example, use 'Search' to display a table of search results, rather than sometimes 'Search' and sometimes 'Find'.
  • If the length of text for a series of command buttons in a dialog box is similar, make all the buttons in the dialog box the size of the largest button.
  • If the text length for a series of command buttons in a dialog box varies, use two button sizes—one for shorter text and another for longer text.

2.2.6Drop-down list

Drop-down lists allow users to make a single choice among a list of mutually exclusive values.

  • Use drop-down lists to provide the user the ability to select a value from a long list of enumerated values. For example, data from a look-up table or criteria for a filter.
  • Do not use a drop-down list box if it is important for users to see all the options all the time. Consider a single selection list box for a large list of values.

2.2.7Field set

Field sets allow users to see relationships among a set of related controls. Use field sets with a descriptive label to group related input elements.

2.2.8Links

Use links to allow users to navigate to another page, window, or help topic; display a definition; initiate a command; or choose an option.

2.2.9List boxes

List boxes allow users to select from a set of values presented in a list that is always visible. With a single-selection list box, users select one item from a list of mutually exclusive values. With a multiple-selection list box, users select zero or more items from a list of values.

  • Use list boxes rather than radio buttons when you have a lot of options (more than 6).
  • Choose a label for the entire list box that describes the items inside the box, for example Available Printers.
  • If there are more than 40 items in a list, consider providing a way for users to filter the list to narrow down the number of options from which they must choose.
  • Place the label on the top of the list, left justified, followed by a colon.
  • If you use a scrolling multiple selection list box, consider also displaying a box with a summary of what the user has selected. This way, the user does not have to continually move up and down the list to see what has already been chosen.

2.2.10Tables / Grids

Tables and grids allow users to enter or view larger amounts of information at a time.

  • Display a table if users need to compare two or more pieces of data and you can’t predict ahead of time which they need.
  • Use tables to display search results.
  • Consider providing paging, sorting, and filtering for tables/grids that may potentially contain large numbers of records (greater that 25).
  • Use grids to allow users to enter several pieces of data at a time.
  • Choose labels for columns that accurately reflect the data.
  • If rows contain different data, label each row. Left justify column and row labels. Do not use a colon after the label.

2.2.11Custom Controls

Custom controls, for example ASP .NET User Controls, built from standard UI elements should be developed where they will enhance consistency in UI style, data handling and validation, and ease of form development. Some ideas of customs controls that may be helpful across the Environmental eGrants project follow.

  • Address control – a control consisting of labels, text boxes, and drop down lists to collect the standard parts of an address. The control could implement a common method for validating addresses across the entire project
  • Telephone number control – a control consisting of a text box. The control would implement a common method for validating that the user has entered a properly formatted telephone number.
  • Zip code control – a control consisting of text box. The control would implement a common method for validating that the user has entered a properly formatted zip code.
  • E-mail address control – a control consisting of text box. The control would implement a common method for validating that the user has entered a properly formatted email address.
  • Date picker control – a control consisting of text box. The control would implement a common method for validating that the user has entered a properly formatted date, and that the date is within a given range.

2.3AJAX

The use of AJAX is permitted where it will enhance the user’s experience or improve the performance of the application’s UI.

2.3.1Standard Framework

Environmental eGrants will us ASP .NET AJAX as its standard AJAX framework. For more information on ASP .NET AJAX, visit and to get started.

2.3.2Usage Guidance

In order to ensure our application is designed for the best possible experience, we will follow the golden rule of Progressive Enhancement: Develop without any JavaScript code first, and then add JavaScript code when we have a working site. Essentially, build a basic Web site with real links and forms pointing to real URLs. Use JavaScript programming and AJAX to change the functionality of those links and forms to enhance the UI. The key goal here in adding AJAX is to make things easier for users. Ajax enhancements eliminate the waiting and scrolling, bringing Web applications up to the level of responsiveness of many traditional desktop applications. With that in mind, please consider the following general rules.

  • Use AJAX to Enhance, not to Function. Use it in the parts of the interface where you will get the most 'bang for the buck'.
  • Alert users as to what's going on. An indication must be provided that stuff is being done and that the page has changed.
  • Minimize the frequency of updates. Instead of polling, consider providing a simple refresh link that triggers the AJAX call only when the user wants it. While this is similar to using the Refresh button in the browser, it puts less demand on the Web server if it only needs to retrieve a small amount of data.

2.3.3Issues

Keep the following issues in mind when deciding where to use AJAX.

  • AJAX content is dynamic, so it breaks the expected behavior of browser functions like the back & forward buttons, and bookmarking.
  • Search engines don't 'see' the dynamically generated content.
  • Content is not visible to persons using a screen reader, and there's currently no reliable and consistent way of notifying screen readers that a change has occurred.
  • AJAX is not accessible to older browsers that don't have good JavaScript support, or to users that turn off JavaScript.

3.Accessibility

Please refer to the Accessibility standards set by OA OIT, which can be found here:

  • ITB ACC001: IT Accessibility Policy
  • OPD-ACC001A: Manual Testing Strategies and Techniques for Web Site Accessibility Validation
  • OPD-ACC001B: AccVerify Configuration Settings
  • OPD-ACC001C: AccVerify Accessibility Rule Settings
  • OPD-ACC001D: Accessibility Compliance Report

3.1Rules Summary of OA OIT Accessibility Standards

3.1.1Alternatives and Association

  • All INPUT elements are required to contain the alt attribute or have an explicitly associated LABEL.
  • All Images and non-text elements must have text alternatives.
  • Purely decorative images and spacer images should have empty ALT tags
  • Text alternatives should be complete and effectively describe the meaning and purpose of the non-text elements.
  • Graphics used for form buttons must have appropriate ALT attributes.
  • All pages are required to contain a bookmark link to skip navigation that has the specified text in either the link text or the 'title' attribute value.
  • Keyboard shortcuts should be provided to important links, form controls, and groups of form controls.

3.1.2Color

  • Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.
  • Any information or emphasis conveyed with color must also be available without color.

3.1.3Dynamic Content

  • Ensure that equivalents for dynamic content are updated when the dynamic content changes.

3.1.4Navigation

  • Provide navigation bars to highlight and give access to the navigation mechanism.

3.1.5General Considerations

  • If after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, and has equivalent information (or functionality).
  • Pop-ups or spawned windows are minimized and the user is informed when the current window is changed. (e.g., Opens in new Window)
  • Proprietary formats available for document viewing must be validated and deemed accessible; otherwise, an accessible alternative format must be made available. Summary descriptions must be provided for documents that cannot be converted to an accessible format due to the graphical or programmatic characteristics of the document.
  • Specify the expansion of each abbreviation or acronym in a document where it first occurs.
  • If needed, form controls are grouped into manageable blocks using FIELDSET and LEGEND.
  • Representing text with images should be avoided. Markup should be used to convey text format and information.
  • Create a logical tab order through links, form controls, and objects.

3.1.6Links

  • Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.
  • All anchor elements not surrounding images cannot be directly adjacent.
  • The target of each link should be clearly identified.
  • All anchor elements are required not to use the same link text to refer to different resources.

3.1.7Special Device Accommodations

  • All pages that have links to files that require a special reader or plug-in are required to contain the specified text indicating a link to the reader or plug-in.
  • When an electronic form is designed for online completion, the form allows 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.

3.1.8Essential Document Attributes

  • Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
  • When an appropriate markup language exists, use markup rather than images to convey information.
  • Create documents that validate to published formal grammars.
  • Documents are required to use the !DOCTYPE tag
  • Documents are required to use the META element with the 'http-equiv' attribute value 'refresh'.
  • Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.
  • Documents are required to use the TITLE element.
  • Documents are required to use the META element with the 'name' attribute value 'language' in the Head section.

3.1.9Scripts

  • When a script causes a time-out on pages with forms, the user shall be given the option to indicate that additional time is necessary to complete the form.
  • For scripts and applets, ensure that event handlers are input device-independent.
  • For scripts, specify logical event handlers rather than device-dependent event handlers.
  • Pages should be usable when scripts, applets, or other programmatic objects are turned off or not supported.
  • Essential Information provided by a script should be identified with functional text that can be read by assistive technology.

3.1.10Document Design & Style

  • Organize documents so they may be read without style sheets.
  • Use style sheets to control layout and presentation.
  • Use relative rather than absolute units in markup language attribute values and style sheet property values.
  • Use header elements to convey document structure and use them according to specification.
  • Provide information about the general layout of a site (e.g., a site map or table of contents).
  • Header elements are used to convey document structure and are nested according to specification. (Do not use headers for font effects.)

3.1.11Tables

  • Do not use tables for layout unless the table makes sense when rendered linearly. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linear version).
  • If a table is used for layout, do not use any structural markup for the purpose of visual formatting.
  • Provide Summaries for Tables.
  • Provide abbreviations for header labels.
  • Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.
  • When tables are used for layout, the linear order of the table cells presents the page content in an understandable manner.
  • Row and column headers are identified for data tables.
  • Appropriate markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

3.1.12Elements & Behaviors to Avoid