Scripting and executable considerations Client side execution such as scripting may be refused by clients. Part of the design process shall include documenting when, if ever, such facilities will be used. Tools shall not include client-side scripting unless that option has been selected by the author. Note client environments may disable client execution or scripting for security reasons, therefore servers should be able to deliver information without scripting. Minimally, a site shall notify the user that scripting is required for some functions. Selection of specific tools or versions of implementations shall be considered in both the context of the target-client environments and the life cycle management of the well-engineered Web site. Where possible, standards-based environments that are platform (processor, operating system, and browser)-independent should be targeted (see also 4.3.1).
Well-engineered Web site design should be governed by the legal and ethical guidelines of both the targetuser community, and others with access to the pages. Privacy considerations shall include organizational policies, legal context (e.g., many European countries have very strict privacy laws), and an awareness of potential network integrity issues.
All information collected from a user that would identify the user shall be discarded when the user terminates the session prior to the delivery of the prescribed item. It is acceptable to retain the data collected if the user accepts the retention of data (such as for return for later completion of the action) at the time the session is terminated. The user may be asked to allow retention of data, when the data to be collected from the user requires a significant input from the user.
The information should be retained for a fixed length of time (such as one day) after which it must be discarded. Anonymity shall be allowed upon user choice, with the potential of not providing the service or the information requested. Informative messages should be provided to explain the needs of the service and to exhibit some contact points for further clarification. End-user data collection (e.g., e-mail address, username, etc) shall not be gathered without explicit user consent. In some countries, this is related to legal issues. It may be necessary to know the geographical location of the server (perhaps provided in metadata) and the client in order to determine what information can be provided.
Legal jurisdictions and industry segments are formulating privacy guidelines that may require consideration of both at the time of design, and when reviewed, as conditions change. Well-engineered Web site shall follow legal and industry guidelines on the collection, notification, and retention of information related to users. Annex F contains pointers to principles for privacy from the European Union, U. S. Dept. of Commerce (Safe Harbor), U. S. Federal Trade Commission (COPPA)20, and the Organization for Economic Cooperation and Development (OECD) guidelines.
Indexing can provide a back door to restricted information. This may require restricting access to the index or excluding restricted information from the index. Indexing of well-engineered Web sites by conforming Web page generation tools shall adhere to the robot exclusion guidelines (see Annex E).
The target-user community evaluation shall take into account the likely existence (or future existence) of individuals who will need to access the information or services of the site and who have limited sight, color blindness, mobility impairments, audio impairments, or require other special considerations as well as ergonomic requirements for general ease-of-access and ease-of-use for users. Well-engineered Web pages shall conform to the Web Content Accessibility Guidelines Level A (priority 1 checkpoints). Well-engineered Web pages should conform to Level Double-A (priority 1 and 2 checkpoints).
The design process shall include consideration of conformance to Level Triple-A (priority 1, 2 and 3 checkpoints). (See W3C WAI Web Content 19990505.21) The World Wide Web Consortium’s Quick Tips22 summarize key concepts of Web site accessibility considerations as follows:
a) Images and animations. Use the alt attribute to describe the function of each visual. b) Image maps. Use the client-side map and text for hotspots. c) Multimedia. Provide captioning and transcripts of audio, and descriptions of video. d) Hypertext links. Use text that makes sense when read out of context. For instance, avoid “click here.” e) Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible. f) Graphs and charts. Summarize or use the longdesc attribute. g) Scripts, applets, and plug-ins. Provide alternative content in case active features are inaccessible or unsupported. h) Frames. Use the noframes element and meaningful titles. i) Tables. Make line-by-line reading sensible. Summarize. j) Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/WCAG.
There are legal requirements for access that vary by jurisdiction23, and also practical considerations as Webbased information becomes either “mission critical” within an organization or displaces other forms of communication with target-user community individuals.
Information about current guidelines and related initiatives from the W3C can be found at http://www.w3.org/WAI. Use of the 216 “Web safe” colors is recommended. These colors are selected, in hex terms, with RGB values of 00, 33, 66, 99, CC or FF only. Well-engineered Web page text to background luminance-contrast shall exceed 33% (better than 67% recommended). Thus the luminance for any specific RGB color can be computed as: luminance = 0.3 × Red + 0.59 × Green + 0.11 × Blue.24
Well-engineered Web pages shall avoid color combinations that cause problems for individuals with color blindness in its various forms. Avoid using the color pairs (see Annex H) for background/foreground of text, or of any objects (e.g., links, borders or icons) which need to be differentiated by color (this relates to red and green deficiencies, which are the most common). A table of Web-safe colors has been arranged to indicate which colors should not be used together. See Annex H for the numerical version and the visual color table.25 The requirements in this subclause are expected to provide substantive conformance to 36 CFR 1194.26 None-the-less sites required to meet 36 CFR 1194 shall assure they meet the requirements of Annex I which duplicates the relevant sections of 36 CFR 1194.
Well-engineered Web pages shall not include flashing or blinking objects which have a blinking frequency or flicker rate greater than 2 Hz without consideration for photosensitive epilepsy impact. Frequency greater than 55 Hz is acceptable under 36 CFR 1194.22(j).27 Where timeout is applied to user response forms, a mechanism shall be provided to allow a user to indicate more time is required. Timeouts or refresh should be used with care to assure users can understand and interact with pages correctly.
Forms shall use label and tab index designations to allow persons using assistive technology to access the fields and functionality required to complete and submit the forms. Well-engineered Web pages shall use the TABINDEX attribute in conjunction with the A, AREA, BUTTON, INPUT, TEXTAREA, and OBJECT elements where this provides a logical sequencing to access these elements. Where a set of pages contain common initial links, and/or duplicate links, TABINDEX shall be used to present unique links for this page first. To allow the user to avoid duplicate links, TABINDEX shall be used to present duplicates after all links have been sequenced once, and a ‘refresh’ link provided to reset the series without traversing the duplicates. Specification of all possible TABINDEX elements may be necessary to assure proper browser sequencing.
Sequencing should be verified with target browsers. Well-engineered Web pages should use the ACCESSKEY attribute with the BUTTON, INPUT, and TEXTAREA tags to initiate the related functions. ACCESSKEY should be considered for initiating link operations with the A and AREA tags as well. When specified, ACCESSKEY designators should be made visible to users and given a distinguishing style (which should be done with CSS class/style designations) to facilitate user awareness. ACCESSKEY designations should avoid overlap with browser and operating system defined shortcuts. Note: browsers do not have a common set of shortcut key assignments.
Also browsers and assistive technologies do not have a common set of shortcut key (accesskey) assignments. For forms that have more than one logical section, for example, personal information, billing information, ship-to information, FIELDSET and LEGEND elements shall be used to identify these sections. Form fields shall have associated LABEL elements (affects TEXTAREA, SELECT, and INPUT fields of type TEXT, PASSWORD, CHECKBOX, RADIO, and FILE). Repetitive navigation links shall be assigned a TABINDEX value of zero (which should result in these being presented at the end of the tabbing sequence).
Well-engineered Web pages where the primary page content does not start immediately in the BODY element shall define a DIV element with the attribute ID=”content” to enclose the primary content. This will facilitate access for users of restricted browsers, as well as indexing of page content. Pages should use a common look and feel, including the location of a common set of navigation buttons.
The first link on a page should be a link to the unique content of this page and be identified with alt text such as ‘skip navigation’ or ‘skip to content.’ This initial link may need to be a 1×1 pixel image that is not visible to users operating on a visual basis, but will be presented to individuals using audio or Braille output where avoiding the repeated information is important