Web Standards: An In-Depth Reference Guide

Design/Architecture

WEB-27

WEB-27: All agencies shall display the Commonwealth Banner unaltered and as defined by the COV Design System. 

Understanding WEB-27  

The Commonwealth Branding Bar helps citizens identify official websites of government organizations in the Commonwealth of Virginia. It also helps visitors understand that the site they are on is official and secure. The new branding bar also serves as a navigation portal for website visitors to easily navigate across government agencies and search for information Commonwealth-wide, without having to navigate back to Virginia.gov. 

The branding bar is easy to install, and instructions and code can be found for agencies to put on their websites under Get the Commonwealth Branding Bar. This page lays out step-by-step instructions to generate a code to place in the head tag of an agency’s website. Agencies also have the choice to choose between grey and white branding bars to better suit the color theming of their websites. 

Each branding bar generated contains: 

  • The Virginia state logo 
  • The agency or Virginia governmental entity name, of which generators must spell out the name in full 
  • A byline stating, “An official website of the Commonwealth of Virginia” and a drop down that states “Here’s how you know.” 
  • The drop down contains information about the Commonwealth of Virginia logo and HTTPS certificates. 
  • A submenu labelled “Find a Commonwealth Resource” that when clicked, allows users to search across Virginia agencies or governmental entities, as well as commonly used Commonwealth services and resources sorted by agency area of service. 

The code generated should be used as-is and should not be modified in any way. Any difficulties with installation should be sent to the Enterprise Web Services Team at VITA by emailing The code generated should be used as-is and should not be modified in any way. Any difficulties with installation should be sent to the Enterprise Web Services Team at VITA by emailing developer@vita.virginia.gov. 

WEB-28

WEB-28: COV web systems shall provide an agency site search box which shall appear on every page and shall be displayed per the directives of the COV Design System. 

Understanding WEB-28

Having an agency-wide site search box on each agency website and page allows users to more quickly access information by typing in relevant keywords and search terms that direct them to a list of relevant links.  An agency cannot depend on primary or secondary navigation alone to direct users to relevant  information.  

Because search boxes become increasingly central for websites that house large amounts of content and information, particularly involving policies, procedures, or citizen services, search boxes should be displayed prominently on every page and should be easily noticeable by users. 

In addition, search boxes should adhere to the following best practices: 

  • Search, where possible, should retain an open-text query field with placeholder text labelled “search” or with more contextual instructions limited to a few words that user can type queries into. 
  • Search boxes should be accompanied by a magnifying glass icon with the least amount of details possible (simple lineart). Users universally recognize the magnifying glass as the symbol of search functionality. 
  • When possible, this icon should not hide the search functionality as it increases the cost of interaction (more clicks) and makes the search functionality less distinct. 
  • When in doubt, do it like Google. 
  • Search queries should be confirmed by hitting enter. Search queries can also be confirmed by hitting a confirmation button if desired, though the interaction of hitting enter in the search box should be retained. 
  • If adding a confirmation button, it should be sized and placed appropriately (usually the height of the search box itself, placed to the right of the open-text query field). This search button at minimum, needs to be 45 x 45 pixels in sizing to meet accessibility best practices. 
  • The input text box should be sized wide to handle approximately 27 characters in length at minimum (set using ems). 
  • Where possible, the search box should be placed in the upper right-hand corner of the agency website, underneath the Commonwealth Branding Bar. 
  • An auto-suggestion drop down field of less than 10 items can help users more quickly find what they are looking for, however, agencies using this should ensure that the suggestions the field auto-generates should be relevant to the search terms typed into the input field. 
  • Once a user presses enter, the original search term should remain in the field unless cleared by the user and the user should be presented with a results page displaying the results based on their search query. 
  • If a search query returns no results, users should be presented with information clearly stating that are no matching results. 

WEB-29

WEB-29: COV web systems shall include a sitemap to enable search engines to crawl a website more efficiently. Examples will be provided in the COV Design System.

Understanding WEB-29

A sitemap is a file that allows search engines to discover most of your site through crawling its content. 

Sitemaps should be in XML format, which allows search engines to index not just HTML files, but data about images, video, news content, and localized versions of agency webpages. 

To learn more about how to create sitemaps in an XML format, please visit the Sitemaps XML format documentation on sitemaps.org. 

VITA recommends following the following sitemap best practices as laid out on developers.google.com: 

  • A single sitemap should be limited to 50MB uncompressed. If your agency’s sitemap file is larger, please break your sitemap into multiple sitemaps. 
  • Sitemap files must be UTF-8 encoded. 
  • It is recommended your sitemaps are hosted at the site root. 
  • Use fully qualified, absolute URLs in your sitemap, for example, use https://www.myvaagency.gov/agencypage.html rather than /agencypage.html. 

WEB-30

WEB-30: COV web systems shall ensure that each page shall have a footer containing, at a minimum, the following information: 

  • Agency name 
  • Copyright information 
  • Text or an approved icon link stating Web Accessibility Initiative (WAI) compliance.
  • Link to the agency’s Internet Privacy Policy Statement.
  • Link to FOIA Information
  • Translation Disclaimer
  • A Contact Us Page
  • Other items as defined by the COV Design System 

Understanding WEB-30

A website footer is a static UI pattern that is shown at the very bottom of all an agency’s site pages. WEB-30 lays out that the following be displayed on the footer of every page: 

  • Agency name: The full agency name should be displayed 
  • Copyright information: Displayed as Copyright © Full Agency Name [Current Year] 
  • It is important that agencies work to meet AA conformance as laid out in WCAG 2.0 when using this link. 
  • Link to the agency’s Internet Privacy Policy Statement: Privacy policies are agency specific but should at minimum explain how an agency uses and collects a user’s information when accessing the site, what information is collected, how it pertains to Virginia law, where a user can reach out for more information, cookie policy, and other information that pertains to use of user data. An example can be found on virginia.gov. 
  • Link to FOIA Information: FOIA information is agency specific and should contain information in plain language on the Virginia Freedom of Information Act, a user’s FOIA rights, how a user can request records, where to send the request, and an agency’s responsibilities when receiving a request. More information on FOIA can be found in the Code of Virginia, Chapter 37. 
  • Translation disclaimer: A translation disclaimer states that a third party (usually Google translate) is available to localize pages. This disclaimer should name the third party, as well as  verbiage that the option is provided to help assist users in providing the website in languages other than English, but that no automated translation is perfect and that the third-party service is provided “as-is.” An example can be found on VITA’s Translation Disclaimer page. 
  • A Contact Us page: A contact us page should be included in the footer. Please see WEB-31 for additional information. 

Additionally, the COV design system recommends that all footers 

  • Work on mobile 
  • That additional links in the footer should be chosen with purpose (frequently used, mini sitemap, etc) 
  • Contain social media links/icons, but not entire social feeds 
  • Is clear and readable with minimal to no imagery 
  • Keep call to actions brief and with a clear direction and purpose if used. 

WEB-31

WEB-31: COV web systems shall provide a Contact Us page that shall include, at a minimum, the agency’s: 

  • Mailing address
  • FAX number, if available
  • Phone number, including a toll-free number and/or TTY number if available
  • Email link or contact form to an agency contact. 
  • The Contact Us page shall be accessible from the page footer.  

Understanding WEB-31

Note Agencies should employ generic email addresses and avoid associating agency contact links to specific individuals. 

A Contact Us page  allows users to contact the agency with any questions or concerns through various means to accommodate different users. 

  • Mailing addresses should be an agency’s physical address and not a PO box, formatted thus: 
     Full Agency Name 
    123 Street Address Road, Suite Number 456 
    City, VA Zip code 
     
  • Fax number, if available, formatted thus: 
    123-555-5555 (Fax)
  • Phone number, including a toll-free number and/or TTY number if available, formatted thus: 
    1-123-555-5555 (Phone) 
    1-800-555-5555 (Toll Free) 
    1-123-555-5555 (TTY) 
  • Further instructions can be provided if needed on how to use TTY or relay services if available. 
  • A generic email link should be used to avoid associating agency contact with a specific individual and should be formatted thus: 
     
    contact@agency.virginia.gov 
     
    A contact form to an agency contact is an alternate to an email address. If using a form, forms should have at minimum the following fields required for response, with appropriate labeling:
  • First name
  • Last name (? Is last name really required? Going on the principle of least)
  • Email or phone number
  • Field for message or comment 

WEB-36

WEB-36: COV platform web systems, including Commercial Off-the-Shelf (COTS) systems, shall support white-labelling for seamless use of Commonwealth Branding as defined by the COV Design System.

Understanding WEB-36

Platform web systems are defined by the EA as: 

Any web system that provides enterprise-level capabilities for largescale or multitenant implementations, including human resource management systems (HRMS), Financial Management Solutions (FMS), supply chain management (SCM), customer relationship management (CRM), enterprise performance management (EPM), and Content Management Systems (CMS). 

These systems should allow for the ability for COVA agencies to re-brand their appearance to fit EA appearance and design system standards (also known as white-labeling) when presented externally or are public-facing. At minimum, a platform web system that can be accessed by public users should display the Commonwealth Branding Bar at the top of the page. 

Accessibility

WEB-39

WEB-39: COV web systems shall provide needed accessibility information that shall be displayed per the directives of the COV Design System, so that the user shall have immediate knowledge as to how to best navigate the website.

Understanding WEB-39

COV web systems shall clearly post websites' accessibility compliance as listed WEB-30, in particular to inform users of strategies needed to navigate the website regardless of ability. Further, agencies should include an accessibility statement that includes the efforts the agency is making towards developing an accessible website, how they track accessibility, and to whom users can direct accessibility related concerns.

WEB-40 – WEB-43

Visual requirements (WEB-40 – WEB-43)

Understanding WEB-40 – WEB-43

High-contrast colors guidance is based in WCAG’s Success Criterion 1.4.3 Contrast (Minimum), which states: 

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: 

  • Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Text that is part of a logo or brand name has no contrast requirement. 

Color contrast ratios can be determined by using an auditing tool such as SiteImprove or online checkers such as WebAIM. 

The audio cues guidance is based in WCAG’s Success Criterion 1.2.2 Captions (Prerecorded), which states: 

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. 

Guidance on best practices for rendering captioning can be found on WCAG’s recommended site, joeclark.org and the Described and Captioning Media Program website. 

Additionally, not all users can understand or perceive color, imagery, or other visual cues due to disabilities that affect vision such as blindness or color blindness in otherwise sighted users. WEB-41 is based on WCAG’s Success Criterion 1.4.1 Use of Color, which states: 

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. 

For example, if a contact form has a green button for “submit” and a grey button for “clear form,”, both the buttons and the instructions for submission should be clearly labelled. In this instance the green button should be labelled “submit” and the red button should be labelled “clear.”. The instructions should direct users to “click the submit button to confirm submission of the form or click the clear form button to clear the form and start over.” 

Labeling should be clear and descriptive to avoid user confusion, but concise enough for users to read quickly and to help users with reading or other cognitive disabilities. 

Agencies should not use color alone to signify hyperlinks on their websites. Agencies should look to use consistent, easily-recognizable design patterns to denote both internal and externally-facing hyperlinks, such as through underlying, CSS hover states, and icons (particularly in the case of an externally-facing hyperlink). 

Further, fields that are marked as required or fields that are met with input errors must present this information in ways that are not just identified through use of color. For example, a field cannot just be highlighted in a red border or have a red asterisk next to it. Rather, agencies should consider identifiers such as “First Name Required” or “First Name*” and a notifier that says “* = Required Field.” 

Visual and code examples of required field best practices can be found on Deque’s The Anatomy of Accessible Forms: Required Form Fields page. 

For user-inputted errors, the error should be easily identifiable with a clear, concise description of the error. Each error message should also meet the following criteria: 

  • identify each field in error
  • provide suggestions (when known) to correct the errors,
  • properly expose this information to assistive technology. 

For additional information and examples on how to format accessible form fields with errors, please visit Level Access’ How to Provide Accessible Form Error Identification page. 

ARIA Requirements

WEB-44 – WEB-53

WEB-44 – WEB-53: ARIA requirements

Understanding WEB-44 – WEB-53

HTML 5 contains a greater variety and more descriptive HTML tags to help developers and accessible technology more easily understand the structure, content, and organization of a web page. Agencies should ensure that their websites are using semantic HTML correctly to help developers, users, and accessible technologies access their website’s content appropriately. Further, HTML5 semantic markup helps limit the use of ARIA in HTML code. For more information on semantic markup in HTML 5 and its role in accessible, please visit Mozilla’s HTML: A good basis for accessibility webpage. 

ARIA, or Accessible Rich Internet Applications is a set of roles and attributes added to HTML code to make a website more accessible to users using assistive web technologies. If you have the option of using an HTML element with semantics and behavior already built in, use that HTML element rather than AIRA. Agencies should use ARIA with an HTML element if there is no other HTML element that natively semantically or behaviorally describes or functions what it does. When agencies elect to use ARIA, they should be aware that they are responsible for creating an appropriate and similarly native experience for assistive web technologies (such as keyboard tab order). 

WEB-44 – WEB-53 specifically denotes requirements for ARIA usage should agencies find a situation where there is no equivalent semantic markup. Developers can reference the W3C’s Accessible Rich Internet Applications (WAI-ARIA) 1.3 for more in-depth detail for ARIA standards, while designers can reference the W3C’s ARIA Authoring Practice Guide (APG) for information on common design patterns and how to design interactions that work best with ARIA usage. 

User Interaction with Layout

WEB-54 – WEB-102

WEB-54 – WEB-102: User interaction with layout

Understanding WEB-54 – WEB-102

When agencies create websites, they should consider not just the “most common” user, but a design for a wide variety of user types and lived experiences. These groups are normally broken down into the following categories: 

  • Visual
  • Auditory
  • Motor
  • Cognitive 

As such, agencies should ensure that their websites are capable of being accessed and interacted with these five user groups and alternative variations of their website’s interactions are available. If a link is accessible with a mouse pointer, for example, it must also be available through keyboard via tab order, through screen readers via semantic markup, and visually denoted not just through color. Additionally, agencies should consider describing visual mediums (such as images) through alt text, and descriptive or other equivalent text for auditory cues.  

Agencies should allow users full control over the web page if it contains played media (auditory and/or visual) and avoid flashing and scrolling imagery for users who might have epilepsy or migraine triggers. 

When it doubt, keep it simple! 

Developers and agencies can reference the WCAG Web 2.1 standards for the most up-to-date and approved web standards if they wish to dive more in-depth. However, Harvard University has put together a simple, easy-to-read guide to the top 10 essentials that developers should consider with accessibility that covers most of the topics covered in WEB-54 – WEB-71. 

WEB-72 – WEB-102 focuses specifically on making websites perceivable, operable, and robust. These are three of four principles documented in WCAG’s four principles of accessibility. 

According to the WCAG, these four principles are: 

  • Perceivable - Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses) 
  • Operable - User interface components and navigation must be operable. This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform) 
  • Understandable - Information and the operation of user interface must be understandable. This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding) 
  • Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible) 

These four principles make up the backbone of today’s modern accessibility standards on the web. 

Additionally, WEB-72 states that agency websites should contain at least two of the following items: 

  • List of related pages  
  • Table of contents 
  • Site map 
  • Search 
  • List of all pages 

For more information in a concise and simplified manner, agencies can reference Harvard University’s Principles from their Digital Accessibility Initiative website. 

User Device Navigation

WEB-103 – WEB-120

WEB-103 – WEB-120: User device navigation

Understanding WEB-103 – WEB-120

WEB-103 – WEB-120 focuses specifically on alternative ways to navigate a website. It’s important to realize that not all users utilize an input device that makes use of a mouse pointer. Alternative input devices can include screen readers, voice commands, mouth sticks, sip and puffs, and the tab and enter keys found on computer keyboards, to name a few. 

Agencies can learn more about assistive technologies on the University of Berkeley’s Types of Assistive Technologies webpage. 

Additionally, this EA section also references potential users’ motor control function on mobile devices, stating that: 

COV web systems shall not require multipoint or path-based gestures, such as pinching, swiping, or dragging. for functionality unless the gesture is essential to the functionality. 

This means that on touch screen devices, users should be able to zoom, enlarge text, or perform basic interactions on a webpage without the need for gesture control; and that websites should be developed to respond natively to different screen sizes and devices. 

Agencies can find a breakdown of additional accessibility techniques, including the ones in the section, in Harvard University’s Assistive Technologies Techniques webpage. 

AV Content

WEB-121 – WEB-128

AV content: WEB-121 – WEB-128

Understanding WEB-121 – WEB-128

All audio and visual media should be appropriately accessible and formatted for users on the web. This section in the EA is in specific reference to WCAG Guideline 1.2 - Time-based Media, which outlines how AV content on websites should be made accessible. Standards 1.2.1 and 1.2.5 should be referenced, which follow below: 

  • An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only or video-only content.  
  • Captions are provided for all prerecorded audio content in synchronized media. 
  • An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, 
  • Captions are provided for all live audio content in synchronized media. 
  • Audio description is provided for all prerecorded video content in synchronized media. 

Additionally, all live content, such as webinars and webcasts hosted on agency websites or applications should also provide accurate and on-time captions (such as real-time captioning and/or CART transcription). 

Users should also have the ability to pause, play, and stop the media at any time; and the media should not automatically play when the user visits the page.