Download a printable version Enterprise Information Technology Accessibility Standards doc format of Enterprise Accessibility Standards

 

Reference #: Ent-Std-Tech-ITAS 1.3
Issue #: 3
Revision Date: March 6, 2014

 

Table of Contents


Executive Summary

Applicability

Requirements

Functional Performance Criteria

1.    Technical Standards – Applications

2.    Technical Standards – Video and Multimedia Products

3.    Documentation

4.    Training Requirements

5.    Testing Requirements

6.    Waivers and Exemptions

Roles and Responsibilities

Related Documents

Contact

Terms

Document History 


 

The purpose of these standards is to ensure that Massachusetts information technology solutions are available and accessible to people with disabilities.  This includes both Commonwealth employees in addition to members of the general public.  Executive Department agencies and their contractors are required to comply with these standards. Further, all public entities are strongly encouraged to address accessibility issues.

These standards are based on Section 508 of the Rehabilitation Act, 29 U.S.C. §794d (http://www.section508.gov/index.cfm?FuseAction=Content&ID=12).  The standards contained in this document will address some or all of the Section 508 Standards for the following categories of Information Technology:

  • Functional Performance Criteria
  • Applications
  • Video & Multi Media (where applicable)
  • Documentation

For purposes of these standards the term “information technology solution” includes computer-based information systems, but not:

  • Peripheral devices (e.g. fax machines, printers or photocopiers),
  • Systems software that manages and controls computer hardware;
  • Firmware
  • Any software or hardware associated with a system’s back-end and inaccessible to end users (e.g. servers, operating system software).

The standards together with the Enterprise Web Accessibility Standards specify minimum accessibility standards that must be implemented and maintained throughout the life cycle of all identified information technology solutions.

These standards are effective as of the published date of this document. Information technology solutions in production prior to the effective date of these standards, upon major changes, must be brought into conformance if reasonably possible.

Agencies are responsible for ensuring that the identified testing criteria are met and that all information technology solutions are in full compliance with these standards whether developed in-house or outsourced. In instances where the identified testing criteria cites the need to validate the deliverable against an assistive technology (AT) or desktop configuration, the AT/IT Environment List must be referenced.

In the rare event that compliance with these standards in connection with an agency’s procurement of commercial off the shelf (“COTS”) or application service provider (“ASP”) software poses an undue burden on the agency, the agency may apply for a waiver.

Additional references that agencies may find useful are listed at the end of this document.
 

2. Applicability

Agencies governed by the Enterprise Information Security Policy must adhere to the standards detailed in this document, except where such adherence would conflict with the Public Records Law or other laws, regulations or policies. Additional references that agencies may find useful as they classify their data are listed at the end of this document.

 

3. Requirements

Functional Performance Criteria

The functional performance criteria are critical in ensuring that these standards speak to the needs of individuals with varying disabilities. Once the technical review of an information technology solution has been evaluated, agencies need to ensure that the overall solution functionality and performance gives individuals access to Commonwealth information and data.

a. Alternate Accommodations

Support for assistive technology used by people with the listed disabilities or at least one alternate mode of operation and information retrieval must be provided to users for each of the listed disabilities.

Limited or no vision

Limited or no hearing

Limited or no speech

Limited reach, strength or fine motor control

Why the standard is needed: It cannot be assumed that users will have the ability to see, hear, operate or experience certain aspects of a user interface for an information technology solution. While each of the specifications addressed in the technical standards based sections of this document addresses specific limitations, it is imperative that agencies consider the overall accessibility of their implemented or planned solutions.

What the standard means: If assistive technologies cannot be used to facilitate the user’s access to and use of an information technology solution, then an equivalent, alternative mechanism for operation and information retrieval must be provided.

Testing Criteria: 

Vision Considerations

  • At least one mode of operation and information retrieval must be provided that does not require visual acuity greater than 20/70 using audio or enlarged print output, either together or independently.
  • At least one mode of operation and information retrieval must be provided that does not require vision.

OR

  • There is support for assistive technology used by people who have vision impairments.

Hearing Considerations

  • At least one mode of operation and information retrieval that does not require user hearing is provided.
  • Where audio information is important for the use of a product, at least one mode of operation and information retrieval is provided in an enhanced auditory fashion.

OR

  • There is support for assistive technology used by people who are deaf or hard of hearing.

Speech Considerations

  • At least one mode of operation and information retrieval that does not require user speech is provided.

OR

  • There is support for assistive technology used by people with speech related disabilities.

Motor Control Considerations

  • At least one mode of operation and information retrieval must be provided that can be used with limited reach and strength and that does not require fine motor control or simultaneous actions.

1. Technical Standards – Applications

Agencies are required to fully comply with all of these standards.  Accessibility must be documented and confirmed within the system records:

  • Prior to procuring, developing, or deploying a new information technology solution;
  • Prior to implementing a major upgrade; or
  • If accessibility is questioned later in the life cycle of an information technology solution that was deployed on or after the published date of these standards.
Standard 1.1 Keyboard Commands

When software is designed to run on a system that has a keyboard, product functions must be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

Why the standard is needed: Users who are unable to use the mouse need all functions to be available via the keyboard. The keyboard provides a precise, discrete method of navigating and selecting.

  • Users with limited hand use may not have the fine motor control required to position the mouse pointer accurately on objects displayed on the screen.
  • Blind users cannot position the mouse pointer because they can't see the screen.

Additionally, many adaptive devices are based on standard keyboard functions. If software can be used with a keyboard, it will also function properly with these devices.

What the standard means: The accessibility requirement is for all functions of the software that are not inherently mouse functions, to be operable using only the keyboard. Moving the mouse pointer or drawing are examples of functions that are inherently mouse functions. Direct manipulation, such as selecting text, is not inherently a mouse function.

For a particular software platform, there are standard keys and key combinations for doing common things. These standard keys are normally specified in the platform user interface style guideline document. The software should use these conventions when appropriate and should not use them for other purposes.

Users should be able to navigate access and activate all menus, toolbars, dialog boxes, and panes using only a keyboard.

Testing Criteria: 

  1. Test with the keyboard to verify that every feature of the solution can be accomplished.

At a minimum, the following operations must be tested using only the keyboard:

  • Verify that all menus and menu items can be accessed using the keyboard.
  • Verify that each toolbar function can be performed using the keyboard.
  • Verify that all instructions and “controls” are navigable from keyboard.
  • Navigate to sections or panes of the application window.
  • Switch the keyboard focus between concurrent dialogs and application windows.
  • Switch the keyboard focus between forms and sub forms.
  • Verify that text and objects can be selected anywhere in the application where this is possible using the mouse.
  • Verify that features invoked via direct manipulation using the mouse are available from the keyboard. For example, if an object can be sized using the mouse by selecting and dragging, it should also be able to be sized by setting the size attributes explicitly on a dialog or properties sheet.

   2. Test with the keyboard to verify continued functionality of unique keyboard support provided by the platform.

Standard 1.2 Disruption of Accessibility Features

Information technology solutions cannot disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications cannot disrupt or disable activated accessibility features of an operating system. If by virtue of the functionality itself, it cannot be determined whether or not a feature is specifically related to accessibility, reference the manufacturer’s documentation.

Why the standard is needed: Accessibility features are built into operating systems and other technology products and are often selected by the user to support their specific needs. Applications that override or disrupt these features can create barriers for the end user and must be avoided.

What the standard means: All operating system and other technology product accessibility features developed and documented according to industry standards must remain intact and functioning as intended.

Testing Criteria: 

  1. Verify that accessibility functionality of the platform the application is meant to run on is not disabled when using the application.

  2. Test the application against all identified accessibility features. If accessibility features of an operating system or other technology product are disabled or broken as a result of the application, the application must be fixed.

  3. Test the application against all identified operating system accessibility features including but not limited to the list below:

  • Ensure that operating systems features for using successive keystrokes (such as StickyKeys in Windows) are operational by verifying that multiple key stroke sequences produce the expected/desired results.
  • Ensure that operating system features for the filtering of repeated keystrokes (such as FilterKeys in Windows) can be enabled.
  • Ensure that operating system features for producing sound as an indicator that a locking key has been engaged (such as ToggleKeys in Windows) can be enabled.
  • Ensure that operating system features using keyboard options to represent mouse functions can be enabled. 
  • Ensure that operating system features for contrast and custom color settings can be enabled. 
Standard 1.3 On-screen Focus

A well-defined on-screen indication of the current focus must be provided so that it moves among interactive interface elements as the input focus changes. The focus must be programmatically exposed so that assistive technology can track focus and focus changes.

Why the standard is needed: The focus indicates where on the screen the user’s attention should be and indicates that selected features of a program allow a user to perform some action. By programmatically exposing the focus, assistive technologies can track and communicate the focus to the end user.

What the standard means: The position on a screen where an action will take place is referred to as the "focus". Focus should be indicated visually. For instance, an item in a menu with the focus is usually highlighted, and a “submit” button usually has a dotted line around its text label to indicate that it has the focus. If you press the enter key, the element that has the focus will activate in the same way as it would with a mouse click action. Additionally, assistive technology must be able to discern the focus from the program’s code. For example, a screen enlargement program needs to move the magnified area of the screen with the focus, providing the user the ability to see where the focus is.

Testing Criteria: 

  1. Test with the keyboard to verify there is a visible focus indicator.

  • Tab or arrow to interactive objects on the screen (e.g., links, menus, buttons, checkboxes).
  • Verify that you can visually identify the object that has focus.

  2. Test with a screen reader or a screen magnifier to verify that input focus is exposed programmatically.

  • Tab or arrow to interactive objects on the screen (e.g. buttons, checkboxes, radio buttons, menus, list items).
  • Verify that the object with focus is read by the screen reader or displayed by the magnifier.
Standard 1.4 User Interface

The user interface is the portion of an application or software component that the user directly interacts with. Sufficient information about a user interface element including the identity, operation and state of the element must be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.

Why the standard is needed: Someone who is blind uses a computer with the aid of assistive technology such as a screen reader, screen magnifier or Braille display. The software must provide information about the objects so an assistive technology can tell the user what the focus object (identity) is as well as its role (operation) and state. For example, if you tab through a form and focus is on a radio button, you need to know it is a radio button and whether or not it is selected.

What the standard means: This provision requires that text must be associated with each element. Examples of user interface elements include buttons, checkboxes, menus, toolbars, scroll bars, and any other feature of a program that is intended to allow the user to perform some action. The text must identify the element and its current state or condition.

For example, a button that shows a hand for getting more help must have the word "help" associated with the button. If a checkbox is present, a text label must indicate what is being checked, and whether the checkbox is checked or unchecked.

Testing Criteria: 

  1. Verify with a screen reader or a screen magnifier that input focus has text that identifies the element and its current state or condition.    

  • Tab or arrow to interactive objects on the screen (e.g. buttons, checkboxes, radio buttons, menus, list items).
  • Verify that the text for the object with focus is read by the screen reader or displayed by the magnifier and that the text sufficiently describes the object and its condition.
Standard 1.5 Image Labels

When images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images must be consistent throughout a solution’s performance.

Why the standard is needed: Labels name an object (e.g., icon names, window titles, button labels, edit fields). Most screen readers allow users to assign text names to images. If the image changes meaning during program execution the text name assigned with the screen reader is no longer valid and is confusing to the user.

This provision applies to any image that is used to indicate an action. See standard 2.13 for all other images.

What the standard means: When users assign text names to images that are associated with associated performable actions, they need to be the same and remain consistent throughout the application. Likewise, avoid having multiple objects with the same name on the same form or dialog if they do not perform the same function.

Testing Criteria: 

  1. Inventory the images used as interactive elements

  • Compare assigned text and intended action throughout the application.
  • Verify that image objects throughout the solution do not use the same text unless they represent the same action.
Standard 1.6  Textual Information

Textual information must be provided through operating system functions for displaying text. The minimum information that must be made available is text content, text input caret location, and text attributes.

Why the standard is needed: Screen readers determine what software is doing by watching calls to drawing functions and remembering what text and graphics have been drawn and where. If text is displayed in a non-standard way, screen reader software may not be able to detect it and read it.

What the standard means: The operating system is the "core" computer software that controls basic functions, such as receiving information from the keyboard, displaying information on the computer screen, and storing data on the hard disk. Other software programs use the standard protocols dictated by the operating system for displaying their own information or processing the output of other computer programs. When programs are written using unique schemes for writing text on the screen or use graphics, other programs such as software for assistive technology may not be able to interpret the information. This provision does not prohibit or limit an application programmer from developing unique display techniques. It requires that when a unique method is used, the text should also be written to the screen through the operating system.

Testing Criteria: 

  1. Verify that the screen reader correctly represents all text content, text attributes, and text input caret location information.

Standard 1.7 Individual Display Attributes (Color, Contrast and Other Display Attributes)

Applications must not override user selected contrast and color selections and other individual display attributes.

Why the standard is needed: For most people, color is a matter of preference, but it is critical for many users with visual impairments. Many users with low vision need high contrast between text and the background to be able to read information on the screen. They may even need a particular color scheme, such as white text on a black background, to prevent the background from "bleeding" over and obscuring the foreground text. Some people consider the default color scheme legible but find that it causes eyestrain over longer periods of time. Operating systems provide users with the ability to adjust color or contrast preferences. When an application disables these system-wide settings, accessibility is reduced. This provision is aimed at allowing users to select personalized settings in one place so that they cannot be disabled by software programs.

What the standard means: Solutions must not override user selected contrast and color selections and other individual display attributes addressed in the operating system desktop properties. This includes, but is not limited to, screen resolution, color quality and contrast, font size, color scheme, window style, button and icon style, icon size, and themes.

  • This provision allows programs to have unlimited options for customizing the display of the programs' content. However, there must be a section in the software that tells the program not to use its own settings, but to use whatever settings are already in place before the program starts. A simple menu selection, for example under a view, or options menu, might be a checkbox that lets the user check “use system display setting.”

Testing Criteria: 

  1. Determine whether or not system settings for font, size and color are automatically inherited by an application or if there is an optional setting that controls how an application obtains information regarding what the various settings should be.

If the system settings are automatically inherited:

  • Validate that color and contrast settings at the operating system level are inherited by the solution
    • Test at least two high or enhanced contrast settings to verify the solution is not dependent on a particular setting.
    • Verify that the solution’s user interface controls and client areas are displayed using the system’s color and contrast scheme.
  • Validate system settings for font, size and color:
    • Use system settings for font, size and color that differ from the solution’s user interface.
    • Verify that the solution’s user interface controls and client areas are displayed using the system settings for font, size and color.

If the software provides an option to inherit system font settings instead of automatically inheriting them:

  • Validate that color and contrast settings at the operating system level are inherited by the solution when that option is enabled.
    • Enable the solution’s option to inherit system settings for high or enhanced contrast.
    • Test at least two high or enhanced contrast settings to verify the solution is not dependent on a particular setting.
    • Verify that the solution’s user interface controls and client areas are displayed using the system’s color and contrast scheme.
  • Validate that system settings for font, size and color at the operating system level are inherited by the solution when the option is enabled:
    • Enable the solution’s option to inherit system settings for font, size and color.
    • Choose system settings for font, size and color that differ from the solution’s user interface.
    • Verify that the solution’s user interface controls and client areas are displayed using the chosen system settings for font, size and color.
Standard 1.8 Animation

When animation is displayed, the information must be displayable in at least one non-animated presentation mode at the option of the user.

Why the standard is needed: The use of animation on a screen can pose serious access problems for users of screen readers or other assistive technology applications. When important elements such as push-buttons or relevant text are animated, the user of assistive technology cannot access the application reliably. This provision requires that in addition to the animation, an application must provide an option to turn off animation.

What the standard means: Animation should be avoided unless it is integral to the content of the solution.  When animation is displayed, the information content of the animation must be displayed as a contextually meaningful text description at the option of the user. For example, when an animation of a hand selecting the start button on a keyboard is presented there must be a text description that describes that action.

Testing Criteria: 

  1. Verify that animation can be disabled.

  • With the animation disabled, verify that no information is lost.
  • With the animation disabled, verify information available through the animation is available in another way.
Standard 1.9 Color Coding

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

Why the standard is needed: If color alone is used to convey information, users who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue or luminosity, the colors may not provide sufficient contrast when viewed using monochrome displays or by people with color blindness.

What the standard means: Color can be useful in highlighting actions for a visual display, however if a user cannot identify or distinguish colors they will not be able to use the information. The software needs to provide another way of making the information available. For example, an application that asks users to press the green button is not accessible since some users cannot distinguish the green button from other buttons on the screen. To make it accessible, add a text label such as "Submit" on the green button and ask users to press the green "Submit" button. Consequently the green will be an enhancement to the visual display and the "Submit" label will provide the information to users who cannot identify or distinguish colors.

Testing Criteria:

 1. Determine if the solution uses color to convey information.

If the application uses color:

  • Visually inspect the screen and verify that color is not the only way to identify or distinguish information.
  • Print a copy of the screen in black and white to verify that color is not the only way to identify or distinguish information.
Standard 1.10 Color and Contrast

When a solution permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels must be provided.

Why the standard is needed: When a solution enables users to customize colors, this checkpoint requires the solution to provide more than just a variety of color choices. The color choices must provide different levels of contrast. Someone with low vision needs high contrast between text and the background to read information on the screen. Someone with another vision impairment may be sensitive to bright displays and cannot focus on a bright screen. They would need color choices that provide a softer background and appropriate foreground color. Because there are a wide variety of needs, solutions that support color customization must provide a variety of color and contrast settings.

Note: This requirement does not apply to solutions that do not provide an option for users to adjust screen colors.

What the standard means: When a solution permits a user to adjust color and contrast settings, at least five (5) selections capable of producing a range of contrast levels must be provided.

  • This provision requires more than just providing color choices. The available choices must also allow for different levels of contrast. Many people experience a high degree of sensitivity to bright displays. People with this condition cannot focus on a bright screen for long because they will soon be unable to distinguish individual letters. An overly bright background causes a visual "white-out". To alleviate this problem, the user must be able to select a softer background and appropriate foreground colors. On the other hand, many people with low vision can work most efficiently when the screen is set with very sharp contrast settings. Because there is such a variation in individual needs it is necessary for a program to have a variety of color and contrast settings.

Testing Criteria: 

  1. Determine whether a solution allows users to adjust colors.

If the solution does not allow the user to adjust colors, no further steps need to be performed.

If the solution does allow users to adjust colors, at least three high contrast color combinations must be provided.

  • Visually verify that the solution provides at least three color combinations that provide a high level of contrast[1].
  • Enable a color customization scheme supported by the solution. Visually verify that the color choices provide sufficient contrast.
  • Test at least three color choices supported by the application. 
Standard 1.11 Flashing and Blinking

Solutions must not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.

Why the standard is needed: Text and objects that blink or flash can cause photosensitive epileptic seizures in susceptible individuals, particularly if the flash has a high intensity and is in the frequency range between 2 Hz and 55 Hz. This includes flashing text, turning graphics on and off or repeatedly changing between different images on the screen.

What the standard means: Avoid the use of unnecessary flashing, alternating or blinking objects wherever possible in the user interface of your application. If flashing or blinking objects are required, they should be used sparingly and users must be able to turn off the flashing or blinking if necessary. When using, ensure that the flashing/blinking frequency is greater than 2 Hz and lower than 55 Hz.

Testing Criteria: 

  1. Determine whether or not the solution uses blinking or flashing elements.

If the application uses any blinking or flashing elements:

  • Verify that they can be disabled
  • Display the blinking elements in the software. Run a program that displays the time interval between blinks.
  • Verify that the frequency is not greater than 2 Hz and not lower than 55 Hz.
Standard 1.12 Forms

When electronic forms are used, the form must allow 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.

Why the standard is needed: Assistive technologies cannot appropriately navigate the information and field elements or assist users in engaging form functionality if the form is not appropriately and logically labeled and tagged. Labels must be associated programmatically with the field object in order for the assistive technology to make them available to the user.

What the standard means: All elements of the form must be labeled with text that is linked to the form object. For example, on a webpage, a label can have a direct association with a particular field that is indicated in the HTML code. Assistive technology can interpret the HTML and correctly announce the appropriate label.

Testing Criteria: 

  1. Test with a screen reader and verify all information on the form is spoken.

  • Navigate to each input field using the keyboard with the screen reader to read:
    • Text labels
    • Object type (role) (e.g. radio button, checkbox, edit field)
    • Object status if appropriate (e.g. a radio button or checkbox that is checked)
    • Object contents (e.g. default text, combobox content)
    • Static text that is not an input label (e.g. instructions at the top of the form) will not get keyboard focus and must be read in read-only mode. Read the entire document, including the static text and images that are not links.
    • Verify that the tab order is logical.

If the screen reader did not read all information on the form:

  • Run an object inspection tool to see if this is a problem with the application or the screen reader.
  • Use the inspection tool to check specific controls that were not read by the screen reader.
  • Verify that the tool displays the appropriate information for the screen reader to work, e.g. name, role, state, value, etc.
Standard 1.13 Text Equivalent for Non-Text Elements

A text equivalent for every non-text element must be provided (e.g., via "alt", "longdesc", or in element content).

Why the standard is needed: Graphics can be useful and attractive enhancements to a user interface. However, when graphics are used, text equivalents must be provided so that information is also accessible to people from various disability groups using a variety of technologies. Text display is essential to make user interfaces available to people using assistive technology and also to enhance usability.

What the standard means: For every image on a user interface, alternative text must be provided. The text must sufficiently describe the image so that a person unable to see the image can understand the content and meaning for its use. The term image in this standard includes elements such as pictures, graphical representations of text (including symbols), image map regions, animations (animated GIFs, for example), graphic list bullets and graphical buttons. Images that are purely decorative or used solely for layout (“spacer” images) should have a null value for their alternative text.

Testing Criteria: 

  1. Validate that there are text equivalents for all logos, photos, submit buttons, applets, and bullets in lists, ASCII art, and all of the links within an image map. Invisible images used to lay out a page should have null alternative text values.

  2. Test with a screen reader and verify that:

  • The table is read in a logical way.
  • All row and column headers are identified when a data cell is selected.
  • Content sequence is logical if tables are used for layout.
  • Form field labels are associated with the appropriate field.
  • Validate that form field labels are situated in a logical and consistent place on all forms in the application’s user interface.
Standard 1.15 Frames

Although use of frames is strongly discouraged, when used they must be titled with contextually meaningful text that facilitates frame identification and navigation. All functionality must be available when frames are turned off or not supported.

Why the standard is needed: It is important to recognize the range of negative implications that using frames has on disabled users, users who rely on assistive technology tools, and to users responsible for maintaining applications with accessibility issues in mind.

  • It is difficult for people with cognitive or visual disabilities to interpret user interfaces built with frames.
  • The use of frames requires greater technical expertise to maintain.
  • Frames are difficult for the user to print.
  • The layout features of frames can be easily replicated by using tables or style sheets.

What the standard means: If a legitimate business need exists that requires the use of frames, the following points must be addressed:

  • Users should not be required to install additional specific software to view the information in a frame. All features and options must be available when frames are turned off or not supported.
  • Each frame must have a title to facilitate frame identification and navigation.

Testing Criteria: 

  1. Verify that

  • The frame is clearly identified through the “title” attribute of the frame.
  • The frame is clearly identified by including text within the body of each frame that clearly identifies the frame.
  • When including text within the body of a frame for identification, the text should be at the beginning of the frame contents to facilitate quick identification of the frame contents beyond the title attribute.
  • The purpose of frames and how frames relate to each other is provided, if it is not obvious using frame titles alone.
  • <noframe> tags are used to provide equivalent experience when frames are not supported.
Standard 1.16 Timed Response

When a timed response is required, the user must be alerted and allowed to adjust the time specification. This criterion may be limited in computer based testing environments consistent with valid testing criteria and ADA reasonable accommodation requirements.

Why the standard is needed: A user's disability can have a direct impact on the speed with which he or she can read, move around, or enter information. A page may "time out" before the user is able to finish reading it. Many forms, when they "time out" automatically, also delete whatever data has been entered. The result is that someone with a disability who enters data slowly cannot complete the form.

What the standard means: When a timed response is required, the user must be alerted via a prompt and given sufficient time to indicate whether additional time is needed.

Testing Criteria: 

  1. Validate that if the page requires a user response within a time interval:

  • The page has features that give the user the ability to indicate that more time is required.
  • The page provides “sufficient time” for the user to indicate that more time is required.
  • The alert is given in an accessible fashion and includes text.
  • The page provides additional time when requested.

2. Technical Standards – Video and Multimedia Products

This section of the standards is only applicable when video or multimedia products are being acquired as part of an information technology solution development project. That is, video and multimedia products that are developed as part of a solution offered under the authority of the IT Acquisition policy, must also comply with the standards identified in this section. Most often equipment purchased in the United States, as required by federal standards, will already be in compliance with this section.

Standard 2.1 Caption decoder circuitry

All computer equipment that includes analog television receiver or display circuitry, must be equipped with caption decoder circuitry which appropriately receives, decodes, and displays closed captions from broadcast, cable, videotape, and DVD signals. Computer equipment that includes DTV receiver or display circuitry, must be equipped with caption decoder circuitry which appropriately receives, decodes, and displays closed captions from broadcast, cable, videotape, and DVD signals.

Why the standard is needed: Like subtitles, captions display spoken dialogue as printed words on a television screen or computer monitor. Unlike subtitles, captions are specifically designed for hard-of-hearing and deaf viewers to enable their full participation when viewing video or multimedia productions. Captions are carefully placed to identify speakers. They often include information regarding on- and off-screen sound effects, such as music or laughter. Captions also hold secondary benefits for people who are learning a foreign language, learning how to read, or watching TV in a noisy area, as well as those who understand best by processing visual information

What the standard means: Captions come in two forms: open or closed captioning:

  • Open captions are displayed automatically as part of the video, without having to be selected by the user.
  • Closed captions normally do not appear as part of the video portion of a multimedia presentation unless the viewer has selected them to appear. The person viewing the presentation must be using technology that includes a closed caption decoder. The decoder will allow the otherwise hidden data within the television signal to be displayed on the user’s TV screen or computer monitor. Many newer television models allow viewers to toggle captions on or off with ease.

Testing Criteria: 

  1. Validate that any computer equipment that can be used to display video can support caption programming contained in the media stream. 

Standard 2.2 Secondary Audio Program Playback Circuitry

Tuner cards for use in computers must be equipped with secondary audio program playback circuitry.

Why the standard is needed: Secondary Audio Program (SAP) information provides streaming audio information alongside televised broadcast information. Information could be the same program audio in another language, or something completely different, such as Descriptive Video Services (DVS) for the visually impaired. DVS is a service where a narrator describes the action of a scene during pauses in the dialogue. Audiences can hear that an actor sadly buries his face in his hands, for example.

What the standard means: Computer components that are equipped to receive television broadcasts must be equipped with a tuner card that enables secondary audio program playback.

  • SAP will not be enabled for tuner cards that support mono sound only.
  • Check product manuals for secondary audio programming directions.

Testing Criteria: 

Determine whether or not the IT equipment can receive television broadcasts.

If IT equipment is able to receive television broadcasts:

  • Validate that tuner cards support secondary audio sound by checking the product manuals.
Standard 2.3 Training Materials (related to video and multimedia)

All training and informational video and multimedia productions that are acquired as part of an information technology solution that contain speech or other audio information necessary for the comprehension of the content must be open or closed captioned.

All training and informational video and multimedia productions that are acquired as part of an information technology solution project that contain visual information necessary for the comprehension of the content must be audio described.

Why the standard is needed: Critical information in training materials needs to be made available for all users who need that training. Providing open or closed captioning and audio descriptions ensures that important information is transmitted.

What the standard means: Training needs must be assessed to include the needs of disabled parties when specifying the media deliverables for IT projects.

  • There must be multiple mechanism or methods for delivering critical user information.

Testing Criteria: 

  1. Verify that either open or closed captioning is provided for all audio content.

  2. Verify that audio descriptions are provided for all visual content.

 

3. Documentation

Standard 3.1 Description of Accessibility and Compatibility Features

End-users must have access to a description of the accessibility and compatibility features of solutions in alternate formats or alternate methods upon request, at no additional charge.

Information about keyboard shortcuts must be made available in documentation, at no extra charge.

  •   All shortcuts for keyboard operation must be enumerated in one place for easy reference.
  •   When the documentation lists specific mouse based actions, the keyboard commands must also be listed.

Why the standard is needed: People with disabilities cannot effectively use the solution if they cannot access information on how to use accessibility features. This is particularly important for keyboard access. Since most solutions focus on navigation with the mouse, it is not always clear how to use the solution with the keyboard. All keyboard navigation must be documented.

What the standard means: 

  • Descriptions of all accessible features of a solution must be available in an alternative format, upon demand, and at no extra change.
  • Alternative formats include, but are not limited to, Braille, large print, electronic media readable by the requester, such as HTML, plain text or .doc files.
  • All keyboard shortcuts should be listed in one place within the documentation for ease of use.
  • Equivalent keyboard commands should be provided in the same place in the documentation where each mouse based descriptions appear.

Testing Criteria: 

  1. Verify:

  • A list of accessible features is provided on demand and in accessible formats.
  • A list of keyboard shortcuts appears in the documentation, usually as an appendix.
  • Keyboard shortcuts appear alongside each mouse instruction.

4. Training Requirements

Standard 4.1 Training Accommodations

Agencies that provide training are responsible for ensuring that all appropriate accommodations are provided for prospective training attendees.

Why the standard is needed:  It cannot be assumed that users will have the ability to operate, see, hear or physically access all aspects of a training environment. It is imperative that agencies consider the overall accessibility of how training will be delivered.

What the standard means: Agencies are responsible for identifying and addressing all prospective attendees’ needs at training.

Testing Criteria: 

  1. Validate that all prospective attendees are able to access the training facility.

  2. Validate that any hardware and software required to successfully complete the training is available and/or compatible with assistive technology devices as appropriate.

  3. Validate that any documentation can be provided in an alternate format for prospective attendees as needed.

  4. Maintain any training documentation in an editable format.

  5. If training for an individual with a disability is likely to be ineffective in a group setting, individual accommodations need to be provided that address the individual’s unique learning needs.

5. Testing Requirements

Planning for accessibility compliance is critical in minimizing the impact on a project. Therefore it is in agencies’ best interests to carefully review project deliverables against these IT Accessibility Standards and the most current Web Accessibility Standards, as appropriate, during the planning phase and throughout the project lifecycle. Agencies are responsible for ensuring that the testing criteria for each section is met at a minimum for any new or major upgrade of information technology solutions that are included in these standards. For purposes of these standards, major upgrades are considered to be projects that require significant financial investment and include new code components or require a major re-write of existing code; require significant person hours for completion; and typically require many months rather than days or weeks to complete.  Aging solutions do not need to comply with these standards in cases where major upgrades are being applied to solutions that contain COTS or ASP software, where significant Commonwealth business processes have been built into the functionality and where the solution has been implemented for longer than 10 years.

Testing for accessibility issues must be addressed as part of the development process for either in house or outsourced solutions or in the event that COTS or ASP software is procured as part of a solution provided under the Statewide Contract ITS23, ITS33, or their successors. Successful remediation of found issues must be achieved prior to implementation. It should be noted that testing does not need to be performed for COTS and ASP Software for which accessibility testing has already been conducted and test results have already been provided to the ITD Assistive Technology Lab (ATL).

There may be instances where the testing efforts result in identification of bugs or problems that are unrelated to the solution that is being tested. In these instances, the issue(s) should be tracked as part of the testing results.

For questions or additional guidance on testing, agencies should contact the ITD ATL.

To comply with the testing requirements, Agencies must:

  • Validate that each deliverable of the Testing Criteria as applicable has been achieved through the use of a third party tester or the ITD ATL. 
    • Test against the published list of assistive technology (AT) and specific desktop configurations specified (AT/IT Environment List ).
  • Document the testing method and outcome for each test performed.
  • Identify how any non-compliant results will be fixed including both defects related to compliance with the standards and defects related to incompatibility with tools on the AT/IT Environment list.
  • Re-test any non-compliant issues until compliance can be validated and documented.
  • Coordinate all testing efforts between the ITD ATL, any contracted solution provider and any engaged third party tester to ensure that a cooperative effort to remedy found issues is applied.
  • Maintain current results of all testing and make available to the ITD Accessibility Laboratory (ITD ATL) staff upon request.
  • Re-test for any applicable accessibility deliverables before any major upgrades are applied.
    • Maintenance agreements in connection with any system delivered that falls under these standards should require cooperation between the agency and the vendor for resolution of any interoperability problems that arise during the term of the agreement related to the use of such system with specific AT in the specific IT environment.

6. Waivers and Exemptions

When delivering COTS or ASP software as part of a larger information technology solution, ITD recognizes that full compliance with these standards is not always possible. For example:

  • Sometimes accessible technology does not exist.
  • Some functions are extremely unlikely to ever involve someone with a need for assistive technology, and
  • Some applications of these standards could compromise effective government operations and/or citizen security.

Also, it is not ITD’s intention that creativity or advances in technology be deterred. It is fully understood that technological advances may render particular requirements that were once necessary, obsolete.

If an agency determines that it is unable to comply with one or more of these standards for COTS or ASP software that is delivered as part of a solution offered under ITS23, ITS33 or their successors, it must either:

  • Confirm and document in the solution’s records that the solution is exempt, because at least one of the following situations exists:
    • The function, operation, or use of an information technology solution involves intelligence activities, activities related to the Commonwealth’s security, command and control of military forces, or equipment that is an integral part of a weapon or weapons system.
    • The technology is only used by a contractor in developing or deploying a system and is not intended to be used by the agency, its employees or consumers.
    • The technology is located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment.

OR

  • Submit accessibility compliance assessment using the World Wide Web Consortium's Web Content Authoring Guidelines, version 2, level AA (the "WCAG2 Standards"), as defined at http://www.w3.org/WAI/intro/wcag.php, instead of the ITD Enterprise Accessibility Standards, Section 2., Technical Standards – Applications and the ITD Web Accessibility Standards, Sections 1 through 5 and Section 8.”

OR

  • Seek and obtain a waiver of compliance from ITD.

Filling the Waiver Request:

  • The agency must file an electronic waiver request with ITD by forwarding it to the Director of ITD’s Accessibility Technology Group, currently Sarah Bourne, at sarah.bourne@state.ma.us. The waiver must be sent from the agency’s chief information officer (CIO), be signed by the agency’s head and clearly state the reasons why a waiver should be granted.
  • ITD’s decision will take into account the recommendations made by the manager of the ITD Assistive Technology Group and by other ITD managers. If a waiver is to be granted, it will be signed by ITD’s CIO. All waiver grants or denials will be submitted to ITD’s General Counsel for review prior to finalization. Copies of the final waiver document must be sent to ITD’s General Counsel, and the Director and General Counsel of the Massachusetts Office on Disability.

Evaluation and Action on the Waiver Request:

Where necessary, the manager of the Assistive Technology Group may require additional information from the requesting agency or need information from other sources to formulate a written recommendation of whether to grant a waiver and to impose any related restrictions.

  • If ITD takes no written action on an agency’s waiver request within twenty (20) business days of receipt of the waiver application, the waiver must be presumed to have been granted. Sufficient written action may include notification to the requiring agency that ITD requires a specific amount of additional time to fully process the request.
  • If ITD refuses to grant the waiver, it must specify the reasons for the refusal in writing.
  • ITD may place conditions on the waiver.
  • ITD may waive some standards, while continuing to enforce others.
  • Where, after review of a waiver request, ITD is inclined to grant the request, ITD will, after consulting with ITD’s General Counsel, advise MOD General Counsel in writing of its intent to do so, and its reasons for the proposed granting of the waiver.
  • Where communications with employees or the public will be affected, ITD will also advise MOD what remediation plan it intends to impose to ensure that the requesting entity’s communications with persons with disabilities will be equally as effective as those with people who are not disabled.
  • MOD will have five (5) business days to state in writing any concerns it may have with the proposed waiver. If MOD does not respond within this specified time, it will be presumed that MOD has no objections to the waiver.

Criteria for Granting a Waiver:

In determining whether it will grant a waiver from one or more of the requirements within these standards, ITD will review the documentation submitted by the agency asking for the waiver, in addition to any other relevant material available to ITD, to establish if the following criteria are met:

  • The agency diligently sought out accessible alternative technology that offers equivalent features and functionality to the inaccessible technology it proposes to use, but it was unsuccessful in finding any.
  • The cost of developing or acquiring substitute accessible technology is prohibitive.
  • The Agency demonstrates that compliance would impose a severe financial or administrative hardship on the agency.

OR

The Agency demonstrates that compliance would fundamentally and negatively change the program or activity that the use of technology is intended to enhance.

  • The agency presents an adequate plan for:
    • Providing alternative access to its employees and, where applicable, to the public, during the period in which inaccessible technology is used by the agency; and
    • Moving toward use of an accessible system.

4. Roles and Responsibilities

The roles and responsibilities associated with implementation and compliance with these standards follow:

Assistant Secretary for Information Technology

  • Issue detailed guidelines governing agency development, implementation, and maintenance of Electronic Security Plans (ESP).
  • Require agencies to submit their ESP to the Information Technology Division (ITD) for review.
  • Specify when agencies shall be required to update their ESPs, and submit updated ESPs to ITD for approval.
  • Issue policies requiring that incidents involving a breach of security or unauthorized acquisition of personal information be immediately reported to ITD and to other required entities per M.G.L., Ch 93H.
  • Develop mandatory standards and procedures for agencies to follow before such agencies enter into contracts with third parties that access personal information in electronic form.

Secretariat Chief Information Officer (SCIO) and Agency Head

  • SCIOs and Agency heads are responsible for exercising due diligence in adoption of this framework to meet the obligations of the Commonwealth by ensuring that adequate security controls are in place and in effect to promote reasonable assurance of security control objectives that safeguard the information assets, including but not limited to personal information.
  • Ensure that all IT systems and applications developed conform to this and all related Enterprise Information Technology Policies, Standards and Procedures promulgated by the Assistant Secretary for Information Technology. Non-conforming IT systems cannot be deployed unless the purchasing entity and their contractor have jointly applied for and received in writing from the Assistant Secretary for Information Technology or designee notice that a specified variance will be permitted.
  • Provide communication, training and enforcement that support the security goals of the Secretariat, its agencies and the Commonwealth.
  • Provide proper third party oversight as applicable for any IT systems and applications.
  • Review and sign all agency security programs, plans, self-audits and reports submitted by the Agency.
  • The Agency Heads are responsible for ensuring compliance with all applicable laws, regulations, and contractual obligations.
  • The Agency Heads are responsible for signing off on the agency's acceptable risk level for meeting IT security objectives.

Secretariat or Agency Information Security Officer (ISO)

  • Ensure that the goals and requirements of the Enterprise Information Security Policy are implemented and met.
  • Maintain all required documentation as specified in the Enterprise Information Technology Policies, Standards and Procedures promulgated by the Assistant Secretary for Information Technology.
  • Conduct self-audits required by ITD upon request and at a minimum annually documenting reasonable assurance that compliance with Enterprise Information Technology Policies, Standards and Procedures has been achieved.
  • Coordinate their agency's compliance with the requirements of applicable executive orders, federal and state laws and regulations, ITD security standards and policies and security-related contractual requirements.
  • Sign all required agency security programs, plans, self-audits, and reports to attest to the accuracy of completeness of the submissions.

Enterprise Security Board (ESB)

  • Recommend revisions and updates to these standards.
  • Manage the variance process and provide recommendations to the Assistant Secretary for Information Technology for approval.
  • Advise the Assistant Secretary for Information Technology in developing security policies, standards and guidelines.
  • Act as a consultative body to the Assistant Secretary for Information Technology.

Information Technology Division (ITD)

  • Establish, adopt and implement the Enterprise-wide policies and standards as determined by the Assistant Secretary for Information Technology in support of the Commonwealth's information security goals including:
    • Continuous testing and monitoring of the enterprise environment.
    • Requesting statements of compliance from Agency ISOs including additional information as required by the Assistant Secretary for Information Technology.
    • Providing ongoing education and outreach.
    • Consult with state entities on the planning and deployment of IT Resources.
    • After review of any related recommendations of the Enterprise Security Board, issue revisions and updates to this policy and related standards.
    • Approve or deny variance recommendations of the ESB.

 

Third parties

  • Ensure that all IT systems and applications developed by or for Executive Department agencies or operating within the Commonwealth's Wide Area Network (MAGNet) conform to this and other applicable Enterprise Information Technology Policies, Standards and Procedures promulgated by the Assistant Secretary for Information Technology. Non-conforming IT systems cannot be deployed unless the purchasing entity and their contractor have jointly applied for and received in writing from the Assistant Secretary for Information Technology or designee, notice that a specified deviation will be permitted.

5. Related Documents

In an effort to provide information that is consistent with current guidance and best practices, the information and guidance provided in this document borrows heavily from the following sources.

Enterprise Information Security Policy

http://www.section508.gov/

http://www.accessibilityforum.org/paper_tool.html

http://www.access-board.gov/sec508/guide/index.htm

http://www.umaine.edu/weboffice/accessibility/default.htm

http://www-03.ibm.com/able/guidelines/software/accesssoftware.html

In addition to the above references, users may find the following resources useful:

Lighthouse International: A non-profit organization dedicated to preserving vision and to providing critically needed vision and rehabilitation services to help people of all ages overcome the challenges of vision loss.

aDesigner:  A disability simulator that helps designers ensure that their content and applications are accessible and usable by the visually impaired.

456 Berea Street:  Article about color contrast tools that are currently available.

 

6. Contact

Standards@state.ma.us
 

7Terms

Key terms used in this policy have been provided below for your convenience.  For a full list of terms please refer to the Information Technology Division’s web site where a full glossary of Commonwealth Specific Terms is maintained. 
 

8. Document History

DateAction

Effective Date

Next Review Date
10/26/07Published10/26/07 
01/23/12Reviewed1/31/121/23/13
1/21/14Updated3/6/20141/1/15
    


[1] For information regarding how to effectively evaluate color contrast options, Lighthouse International is a resource that may be helpful to developers.  For tools that can be used to assist users in identifying sufficient contrast options, please reference the Additional Information section at the end of this document.