The State Organization Index provides an alphabetical listing of government organizations, including commissions, departments, and bureaus.
Top-requested sites to log in to services provided by the state
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:
For purposes of these standards the term “information technology solution” includes computer-based information systems, but not:
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.
Reference #: Ent-Std-Tech-ITAS 1.3
Revision Date: March 6, 2014
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.
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.
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.
Motor Control Considerations
Agencies are required to fully comply with all of these standards. Accessibility must be documented and confirmed within the system records:
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.
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.
At a minimum, the following operations must be tested using only the keyboard:
2. Test with the keyboard to verify continued functionality of unique keyboard support provided by the platform.
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.
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:
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.
1. Test with the keyboard to verify there is a visible focus indicator.
2. Test with a screen reader or a screen magnifier to verify that input focus is exposed programmatically.
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.
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.
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.
1. Inventory the images used as interactive elements
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.
1. Verify that the screen reader correctly represents all text content, text attributes, and text input caret location information.
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.
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:
If the software provides an option to inherit system font settings instead of automatically inheriting them:
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.
1. Verify that animation can be disabled.
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.
1. Determine if the solution uses color to convey information.
If the application uses color:
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.
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.
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.
1. Determine whether or not the solution uses blinking or flashing elements.
If the application uses any blinking or flashing elements:
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.
1. Test with a screen reader and verify all information on the form is spoken.
If the screen reader did not read all information on the form:
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.
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:
For data tables, row and column headers must exist and meaningfully identify the tables’ contents. Form fields and their labels must be programmatically bound together wherever possible so that they can be associated with each by assistive technology.
Why the standard is needed: Large tables of data and form fields can be difficult to interpret if a person is using a non-visual means of accessing the user interface. Users of screen readers can easily get "lost" inside a table or form because it may be impossible to associate a particular cell or form label that a screen reader is reading with the corresponding column headings, row names, or form field.
What the standard means: Be cognizant of how a screen reader will interpret the information presented through the user interface.
Tables: Screen readers read the information contained in a table across the rows as opposed to down the columns. When a data cell is selected, the screen reader reads the headers associated with it as well as its content.
Forms: Screen readers rely on a form's labels to assist users in navigating forms. Therefore, a form’s labels must be linked to its controls programmatically.
1. Test with a screen reader and verify that:
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.
What the standard means: If a legitimate business need exists that requires the use of frames, the following points must be addressed:
1. Verify that
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.
1. Validate that if the page requires a user response within a time interval:
 For information regarding how to effectively evaluate color contrast options, Lighthouse Guild, formerly known as 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.
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.
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:
1. Validate that any computer equipment that can be used to display video can support caption programming contained in the media stream.
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.
Determine whether or not the IT equipment can receive television broadcasts.
If IT equipment is able to receive television broadcasts:
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.
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.
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.
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:
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.
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.
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 EOTSS 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 EOTSS ATL.
To comply with the testing requirements, Agencies must:
When delivering COTS or ASP software as part of a larger information technology solution, EOTSS recognizes that full compliance with these standards is not always possible. For example:
Also, it is not EOTSS' 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:
Filling the Waiver Request:
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.
Criteria for Granting a Waiver:
In determining whether it will grant a waiver from one or more of the requirements within these standards, EOTSS will review the documentation submitted by the agency asking for the waiver, in addition to any other relevant material available to EOTSS, to establish if the following criteria are met:
The Agency demonstrates that compliance would fundamentally and negatively change the program or activity that the use of technology is intended to enhance.
The roles and responsibilities associated with implementation and compliance with these standards follow:
Assistant Secretary for Information Technology
Secretariat Chief Information Officer (SCIO) and Agency Head
Secretariat or Agency Information Security Officer (ISO)
Enterprise Security Board (ESB)
The Executive Office of Technology Services and Security (EOTSS)
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
In addition to the above references, users may find the following resources useful:
Lighthouse Guild, formerly known as 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.
Key terms used in this policy have been provided below for your convenience. For a full list of terms please refer to the Executive Office of Technology Services and Security (EOTSS) web site where a full glossary of Commonwealth Specific Terms is maintained.