Skip Maine state header navigation

Agencies | Online Services | Help

 Maine State Seal

Maine State Government

Dept. of Administrative & Financial Services

Office of Information Technology (OIT)


Web Accessibility and Usability Policy


I. Statement of Policy

It shall be the policy of the State of Maine that information and services on Maine State Government web sites is designed to be accessible to people with disabilities.

II. Purpose

Maine State Government is committed to the Guiding Principles of Universal Access to Information. This commitment is currently reflected in the existing Computer Applications Program Accessibility Standard, adopted in 1998. In view of enacted legislation, Title 5 MRSA~54, requiring forms to be available on the Internet; this document sets forth additional standards to insure the accessibility of Maine State Government web sites.

All citizens and employees, including those who have disabilities, have a right to access Maine's information resources and to that end Maine State Government's facilities, technologies, and services that are sources for information must be designed to provide universal access.

Compliance with the following set of standards will benefit not only our citizens with disabilities, but will also provide an additional benefit to those users who require keyboard access or use text-based browsers, low-end processors, slow modem connections and/or no multi-media capabilities on their computer. It also enhances access to Maine web sites by new technologies, such as smart phones, tablets and other devices with Internet connectivity.

III. Guidelines and Procedures

A. The implementation Guidelines contained herein are necessarily technology-dependent and will be updated as technologies evolve and change. The web technologies considered the current standards as of this version include:



Note: The use of other technologies (e.g., Java, Flash) and other document formats (e.g., Adobe Acrobat PDF, Microsoft Word, WordPerfect) is permissible if used in accordance with the standards outlined in this document. See the sections on Embedded Objects and Downloadable Documents for more information.


B. Coding

1. - Use valid, standard web programming code.

What: The World Wide Web Consortium (W3C) sets and publishes standards for web programming languages including HyperText Markup Language (HTML/XHTML), and Cascading Style Sheets (CSS). Programming code is considered "valid" when it follows the rules and conventions specified in the published standards.

Why: Valid code is the foundation for accessibility. Screen readers and other assistive technologies most reliably interpret and interact with web pages that are built using valid, standard code.

How: For web pages, indicate the programming language you are using by starting your code with a standard document type declaration, such as:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"  "">

See the full list of W3C Recommended Document Type Declarations ( Use the W3C HTML Validation Service ( to check your code.

Ref: WCAG 1.0 3.2, 11.1, 11.2; WCAG 2.0 4.1.1


2. Use appropriate markup to convey document structure.

What: HTML includes "markup" (programming code) to identify the structural elements of a document. For example, <p> identifies a paragraph and <h1> identifies a heading.

Why: Screen readers use structural information to help make reading more efficient. For example, most screen readers can skip from heading to heading, announce the number of items in a list, and identify the current row and column in a data table.

How: Identify headings, paragraphs, lists, quotations, etc., using the appropriate markup instead of relying solely on formatting. For example, use <h1> tags to identify the top-level heading rather than simply making its text large and bold. Do not misuse structural markup for formatting effects, such as using <blockquote> to indent a paragraph. Use Cascading Style Sheets (CSS) for formatting.

Ref:WCAG 1.0 3.5, 3.6, 3.7, 5.4; WCAG 2.0 1.3.1


3. Use style sheets for formatting whenever possible.

What: Cascading Style Sheets (CSS) is a formatting language designed to compliment HTML. While HTML is designed to identify a document's structure, CSS is intended for formatting and presentation. (Pages must be usable and function properly when CSS is not supported. CSS Level 2 is recommended, but it must be backward compatible.)

Why: In general, users can most easily override formatting settings made using CSS. The use of CSS for formatting also tends to facilitate the proper use of HTML to identify document structure.

How: See the W3C's Cascading Style Sheets site for specifications, tutorials, and resources.

(Note: Some older web browsers, notably Internet Explorer 3 and Netscape 4, have problematic support for CSS. Be sure to test pages using CSS in multiple browsers.)

Ref: WCAG 3.3


C.  Text

1.  Use text to display text, unless formatting that cannot be achieved with CSS is required.

What: Web developers often use images of text to achieve a specific style, size, or special effect.

Why: Users with limited vision rely on the ability to enlarge text or choose enhanced color combinations. However, most web browsers cannot change the size and color of images.

How: Whenever possible, use actual text instead of images of text. Cascading Style Sheets (CSS) can be used to achieve specific sizes, colors, or effects. Text that requires exact formatting, such as logos and/or other branding elements, are appropriate exceptions.

Ref: WCAG 1.0 3.1; WCAG 2.0 1.4.5


2.  Use relative sizes for fonts.

What: Font sizes can be set using "absolute" or "relative" units of measurement. Absolute units, notably pixels (px), points (pt), and inches (in), are based on fixed physical measurements; "relative" units, such as percentages (%) or keywords (e.g., small, medium, or large) are based on the user's default font size.

Why: Users with limited vision often rely on the ability to enlarge text. Most web browsers allow users to easily change the size of text that has been set with relative units (or not set at all). Using absolute font sizes generally makes it more difficult for users to change text size to meet their needs.

How: Set font sizes using relative measurements or avoid setting font sizes altogether.

Ref: WCAG 1.0 3.4; WCAG 2.0 1.4.4


3.  Identify the language of text.

What: HTML uses the lang attribute to specify language in a web page. It can be set for any HTML element.

Why: Words written in foreign languages can be unintelligible when spoken by a screen reader. Most screen readers are able to pronounce words in their appropriate language if it is specified.

How: Use the lang attribute on the <html> element to identify the primary language of each document, for example, <html lang="en">, for English. Use the lang attribute on <span> or other elements to identify words or phrases in other languages. For example, a Spanish phrase within an English document could be coded as: <span lang="es">se habla español</span>.

Ref: WCAG 1.0 4.1, 4.3; WCAG 2.0 3.1.1, 3.1.2


4.  Use images instead of "ASCII art."

What: "ASCII art" is images created using special arrangements of text characters and symbols. For example, ":-)" is often used to create a smiley face, and "->" is often used as an arrow.

Why: Screen readers read most ASCII art literally, which can be extremely confusing. For example, ":-)" reads as "colon dash right parenthesis" and "->" as "dash greater than."

How: Use images with appropriate alternate text instead of ASCII art.

Ref: WCAG 1.0 1.1; WCAG 2.0 1.1.1; 508 a

D. Colors

1. Do not convey information with color alone.

What: Color is often used to indicate special functions or status. For example, required form fields are frequently indicated with red labels.

Why: Users with blindness, limited vision, or color-blindness may miss information presented with color.

How: Whenever color is used as an indicator, use a non-color-based indicator as well. For example, required form fields could be identified with an icon (an image with appropriate alternate text) in the label, as well as with color.

Ref: WCAG 1.0 2.1; WCAG 2.0 1.4.1; 508 c

2.  Use contrasting foreground and background colors.

What: Web authors can set specific colors to be used for foregrounds (text) and backgrounds. Sometimes images are used as backgrounds.

Why: Users with limited vision or color-blindness may have difficulty reading text that is similar in color to its background.

How: For text, use dark colors on light backgrounds, or vice versa. Avoid combinations of red and green as well as busy background images. Text must have a contrast ratio of at least 3:1.

Ref: WCAG 1.0 2.2; WCAG 2.0 1.4.3

E. Images

1. Provide appropriate "alternate text" for all images.

What: The HTML image element (<img>) includes an "alternate text" attribute (alt) that is used to provide text that can be substituted when the image itself cannot be displayed. Alternate text is meant to be a concise replacement for an image and should serve the same purpose and convey the same meaning.

Why: Individuals who are blind cannot perceive information presented in images; screen reading software reads alternate text instead.

How: ALL images must have appropriate alternate text. As a rule of thumb, consider what you might say if you were reading the web page to someone over the telephone. You do not need to include the words "image of" or "graphic of."


·         For images that contain words or letters - use alternate text that includes the same words or letters.

·         For images links - use alternate text that identifies the link's destination or function. You do not need to include the words "link to."

·         For images that are invisible, purely decorative, do not convey meaning, or are completely redundant with text that is already on screen - use alt="" (empty string) to indicate that the image can be safely ignored by a screen reader.

·         For CAPTCHA images, use alt text to indicate that the image is being used for CAPTCHA and provide an alternative test in a non-visual medium (e.g., an audio file).

Ref: WCAG 1.0 1.1; WCAG 2.0 1.1.1; 508 a

2. Provide full descriptions for graphs, diagrams, and other meaningful images.

What: "Meaningful" images are images that convey more information than can appropriately be expressed as alternate text.

Why: A full description allows a user who cannot see or understand a meaningful image to receive the same information as a sighted individual.

How: Present a full description of a meaningful image either on the page on which the image appears or through a link immediately preceding or following the image. Use alternate text to provide a concise name for the image. For example, the alternate text of a graph should state its title and the full description should summarize its trends and/or present a table of its data.

Note: The longdesc attribute of the <img> element can also be used to provide a link to a full description. Because longdesc it is not yet supported by most web browsers, it should not be used as the only method of providing a full description.

Ref: WCAG 1.0 1.1; WCAG 2.0 1.1.1; 508 a


F. Image Maps

1. Provide alternate text for each area in client-side image maps.

What: Image maps are images divided into multiple "areas," with each area having its own hypertext link.

Why: Just as images must have alternate text, each area of an image map must also have appropriate alternate text for use when the image is not displayed.

How: Use alternate text that indicates the function or destination of the link for each area of a client-side image map. The image itself should have alternate text that indicates the overall function of the image map.

Ref: WCAG 1.0 1.1; WCAG 2.0 1.1.1; 508 a

2.  Use client-side image maps instead of server-side image maps unless areas cannot be defined with available shapes.

What: While client-side image maps and server-side image maps look and operate similarly, they are technically very different. Because of the way server-side image maps work, all information about the image and links is stored at the web server and is not available to the user's web browser or assistive technology.

Why: Screen readers cannot identify or read the separate areas or links within server-side image maps.

How: Whenever possible, use client-side image maps instead of server-side image maps. If server-side image maps must be used, provide an accessible alternative that includes the same content and functionality. In cases where it is impossible to create an equivalent accessible version, such as with some geographical imaging and mapping systems, exceptions may be necessary.

Ref: WCAG 1.0 1.2, 9.1; 508 e, f

G. Audio

1. Do not convey information with sound alone.

What: It is possible to use sound for a variety of purposes, including presenting warning signals, cues, or verbal instructions.

Why: Users who are deaf or hard of hearing may miss information provided only through sound.

How: Whenever significant information is provided by sound, include a visual indicator that provides the same information as well.

Ref: WCAG 1.0 1.1; WCAG 2.0 1.1.1, 1.2.1; 508 a

2. Do not automatically play audio.

What: It is possible for a web page to automatically play sound or music when it loads.

Why: Background sounds or music can make it difficult or impossible for screen readers user to hear their screen readers.

How: Do not automatically play audio for more than 3 seconds. Provide a means for users to start audio playback when they desire (e.g., a "play" button).

Ref: WCAG 2.0 1.4.2

3. Provide text transcripts for audio containing speech when it is provided to the public and/or required to be viewed by employees.

What: "Audio containing speech" includes audio recordings or live broadcasts of speeches, seminars, conferences, etc. A text transcript is a word-for-word written record of the spoken content of such an event.

Why: Individuals who are deaf or hard of hearing may require text transcripts to access audio information.

How: Provide a link to an HTML or text transcript of any audio presented on a web site. Transcripts should be posted at the same time the audio is made available. Communication Access Realtime Translation (CART) providers can transcribe live events.

Ref: WCAG 1.0 1.1; WCAG 2.0 1.1.1, 1.2.1; 508 a

H. Multimedia

1. Provide synchronized captions for all multimedia that contains essential auditory information when it is provided to the public and/or required to be viewed by employees.

What: Multimedia generally refers to recorded or live media containing both video and audio tracks. Captions are essentially a text transcript of the audio synchronized with the audio/video tracks of the presentation.

Why: Individuals who are deaf or hard of hearing may require captions to access the audio information in multimedia.

How: Whenever possible, video should be posted using the accessible resources provided by the Maine State Media Gallery.  Agencies can subscribe to the service at  3rd party video services, such as YouTube, are allowed but are required to post content with synchronized captions which have been manually evaluated for accuracy and if necessary updated to appropriately reflect the audio and visual content of the video.


Ref: WCAG 1.0 1.4; WCAG 2.0 1.2.2, 1.2.4; 508 b

2. Provide audio descriptions for all multimedia that contains essential visual information when it is provided to the public and/or required to be viewed by employees.

What: Audio descriptions are verbal descriptions of the actions and images displayed in a video that are inserted during pauses in the regular dialogue or audio track. Audio descriptions are only necessary if significant information that is presented visually is not discernable from the dialogue or audio track.

Why: Individuals who are blind or low-vision may require audio descriptions to access the visual information in multimedia.

How: Carefully consider whether audio descriptions are necessary to present the significant information of a multimedia recording. Many speech-intensive events, such as speeches, lectures, or conferences, do not contain essential video and, therefore, do not need audio description. When necessary, audio descriptions are usually best implemented by a professional "audio describer."

Ref: WCAG 1.0 1.3; WCAG 2.0 1.2.3, 1.2.5; 508 b

I. Animation

1. Provide a means of pausing any moving, blinking, scrolling, or auto-updating information.

What: Animated graphics, Flash, Java, <blink> tags, <marquee> tags, and other techniques are often used to create a variety of animated effects.

Why: Some users with disabilities are not able to read text that is moving. Animation can be distracting to users with visual or cognitive disabilities.

How: Avoid animation and movement unless it provides significant additional information. If animation is used, provide a means of pausing the animation.

Ref: WCAG 1.0 7.1, 7.2, 7.3; WCAG 2.0 2.2.2

2. Do not include content that flashes faster than 3 times per second.

What: Animated graphics, Flash, Java, <blink> tags, and other techniques can be used to cause content to flash.

Why: Flashing faster than 3 times per second can trigger epileptic seizures.

How: Do not include content that flashes faster than 3 times per second.

Ref: WCAG 1.0 7.1; WCAG 2.0 2.3.1 ; 508 j


J. Links

1. Ensure that links are understandable out of context.

What: A link is understandable out of context when it clearly indicates its destination or function without requiring additional information.

Why: Screen reader users often "tab" through links (skip from link to link by pressing the Tab key) in order to "scan" a page. Most screen readers also offer a "links list" feature to help speed the process of navigating to specific links. Links that are not understandable out of context, such as "click here" or "more," make these techniques much less efficient. Some screen readers can be configured to read link title attributes instead of link text, however most currently read only link text by default.

How: Use link text that is clear and unambiguous. Link text should usually match the title of the page to which the link points. Ensure that links that point to the same URL use the same link text, and that links that point to different URL's use different link text. If title attributes are used, repeat the text of the link as the beginning of the title, followed by the additional information.

Note: Portions of links may be hidden visually but revealed to assistive technologies using a style such as:

.invisible { position: absolute; left: -10000px; width: 1px; height: 1px; overflow: hidden; }

Ref: WCAG 1.0 13.1; WCAG 2.0 2.4.4

2. Provide a means of skipping past repetitive navigation links.

What: Navigation links are the lists or "menus" of links to all the sections of a site that are often repeated on every page.

Why: Because navigation links are typically placed at the beginning (top left) of pages, screen reader users must read through all the navigation links before reaching the main area of the page. Individuals who use a keyboard instead of a mouse similarly must tab through all the navigation links before reaching the main area of the page. Providing a means of skipping these links can significantly improve efficiency and usability for screen reader and keyboard users.

How: Provide a link at the beginning of navigation lists that points to a target at the beginning of the main content area of the page. This link must be visible to screen reader and keyboard users, but can be hidden from other users, e.g.:

<style type="text/css">   a.skipnavigation { position: absolute; left: -10000px; }   a.skipnavigation:focus, a.skipnavigation:active { position: static; left: 0; } </style>

<a href="#content" class="skipnavigation">Skip to Content</a>

<a id="content"></a>

Ref: WCAG 1.0 13.6; WCAG 2.0 2.4.1; 508

3. Avoid using small links.

What: The size of the "clickable" area of a link is limited to the size of the image or text that makes up the link.

Why: Mouse-users with limited fine motor control may have difficulty pointing to and clicking on links that are small, especially if the links are close together.

How: Make sure that images used for links are reasonably large, preferably 16 pixels by 16 pixels or larger. Use standard or enlarged font sizes for text links, and avoid using text links that are shorter than 4 characters in length. Avoid placing small links close together.

Ref: n/a

4. Ensure that same-page links move keyboard focus as well as screen focus.

What: Same-page links are links that target another location on the same page. The target is usually indicated with a "named anchor" (e.g., <a name="targetname"></a>). When a same-page link is clicked, the screen should scroll and keyboard focus should move to the target location on the page.

Why: Users with physical or visual impairments may not be able to use a mouse. Same-page links can enable these users to more quickly and efficiently move about a page. Unfortunately, Internet Explorer 5, 6 & 7 do not reliably move keyboard focus to the target of same page links.

How: To ensure that same-page links work correctly in Internet Explorer 5, 6 & 7, set tabindex="-1" on same-page link targets.

Ref: WCAG 2.0 2.1.1

K. Forms

1. Provide labels or titles for all form fields.

What: HTML forms include "fields" such as text boxes (<input type="text">), check boxes (<input type="checkbox">), radio buttons (<input type="radio">), and drop-down lists (<select>). Each field is typically identified by a text label positioned above, before, or below the field. In HTML, labels are identified using the <label> tag.

Why: Screen readers cannot always determine which label belongs to which field based on positioning alone. Proper use of the HTML <label> element and/or title attribute makes this association clear.

How: Use a <label> element whenever possible to identify each form field's label. Set the label element's for attribute to match the corresponding field's id, e.g.:

<label for="fieldId">Label Text:</label> <input id="fieldId" name="fieldId" />

Add a title attribute to any form field that cannot be associated with a <label>. Because screen readers typically recognize either the <label> or the title (not both), the title must provide the full label, and a <label> should not be associated with the field.

For buttons (<input type="submit|reset|button">), use the value attribute to provide a label; for image buttons (<input type="image">), use the alt attribute for the label.

Ref: WCAG 1.0 12.4; WCAG 2.0 1.3.1, 2.4.6, 3.3.2; 508 n

2. Position labels as close as possible to form fields.

What: Using certain layout techniques, form labels are not always positioned immediately next to their fields.

Why: When screen magnification software enlarges a web page it also reduces the field of view. If form field label is positioned far away from its field, it may be impossible for a screen magnifier-user to view both the field and the label at the same time.

How: Position labels immediately adjacent to fields, preferably in standard locations, such as on the left or above text boxes and list boxes and on the right of checkboxes and radio buttons.

Ref: WCAG 10.2; 508 n

3. Ensure that form fields are in a logical tab order.

What: Screen reader and keyboard users move between form fields (and links) using the Tab key. The order in which form fields receive focus is called the "tab order." By default, the tab order follows the order in which elements appear in a page's HTML code.

Why: Depending on the design and layout of a page, the tab order may not match the visual (or logical) order of fields on a form. Reading fields out of their intended order can be disorienting for a screen reader or keyboard user.

How: Make sure that fields appear in logical order in the HTML code or use the tabindex attribute on each field to set the appropriate order.

Note: Any element with a positive tabindex will come before all elements without tabindex in the tab order. As a result, tabindex must usually be applied to all or none of the focusable elements on a page.

Ref: WCAG 1.0 9.4; WCAG 2.0 2.4.3; 508 n

4. Avoid placing non-focusable text between form fields.

What: Special instructions for completing form fields may be listed after or between the fields to which they apply. Usually, this text is non-focusable, that is, it does not receive focus when a user tabs through the form fields.

Why: When filling out a form, screen readers typically use a special "forms mode" in which they interact only with focusable elements, including form fields, associated labels, buttons, and links. In "forms mode," screen readers do not read non-focusable text.

How: Instructions should be given within field labels if possible. If instructions are too long to fit within labels, they should be provided in an instructions section before the beginning of the form. If neither of these approaches works, consider using a technique to make the text elements focusable.

Note that disabled form fields (disabled="disabled") are non-focusable; fields may be made read-only (readonly="readonly") to keep them focusable.

Ref: 508 n

5. Provide legends for groups of form fields.

What: In some cases, several form fields may need to be grouped together. For example, a set of radio buttons may provide different "answers" to a single "question."

Why: Screen readers need to be able to read the group name or "question" in addition to each field's individual label.

How: If possible, group related fields within a <fieldset> element and provide the group name or "question" in the fieldset's <legend>. If a fieldset cannot be used, apply a title attribute to each field in the group including the group name and the field's label. Because screen readers typically recognize either the <label> or the title (not both), the <label> elements should not be associated with their fields when using this technique. Also note that groups of radio buttons (and sometimes checkboxes) can usually be replaced by a single drop-down list or list box (<select>) with the "question" as the <label> and the "answers" as <option> elements.

Ref: WCAG 1.0 12.3; WCAG 2.0 1.3.1, 2.4.6, 3.3.2; 508 n

6. Ensure that text in form fields can be enlarged.

What: Most web browsers allow users to easily adjust the size of text on a page.

Why: Users with limited vision often rely on the ability to enlarge text. However, Internet Explorer 5, 6 & 7 do not change the size of text within form fields to match settings selected from the View, Text Size menu.

How: To ensure that text in form fields can be easily resized in Internet Explorer 5, 6 & 7, include a style rule such as the following:

input, select, textarea, button { font-size: 100%; }

Ref: WCAG 2.0 1.4.4


L. Data Tables

1. Identify a header cell for each column and row in simple data tables.

What: In HTML, the table element (<table>) is used to display data. "Simple" tables have a uniform number of columns and rows. Table header cells (<th>) are used to provide a label for each row and column.

Why: A screen reader can use table headers to provide row and column information while a user explores the data cells within a table.

How: Use <th> elements with scope="col" (for column headers) or scope="row" (for row headers) to identify column and row header cells. The cell that contains the most uniquely identifying information for the column or row should be the header; usually, this should be the first cell of each column and row. Do not include unnecessary columns or rows for formatting.

Ref: WCAG 1.0 5.1; WCAG 2.0 1.3.1; 508 g


2. Identify relationships in complex data tables using id and headers attributes.

What: Tables become complex when they have "spanned" columns or rows, multiple layers of headers, or are divided into multiple sections. The id and headers attributes can be used to associate data cells with multiple row and column headers in complex data tables.

Why: Modern screen readers can use the information provided with id and headers attributes to interpret relationships in complex tables.

How: Whenever possible, simplify complex tables by re-arranging or dividing them into separate tables. If a table cannot be simplified, use a unique id attribute on each header cell, for example: <th id="header1">, and a headers attributes on each data cell to list the id attributes of header cells that it relates to, for example: <td headers="header1 header2 header3">. Do not include unnecessary columns, rows, colspans, or rowspans for formatting.

See W3C's "Tables in HTML Documents" ( for more information on how to markup complex tables.

Ref: WCAG 1.0 5.2; WCAG 2.0 1.3.1; 508 h

3. Provide summary attributes for data tables.

What: The summary attribute provides the name and, possibly, a brief description of a table's content and structure. The summary is not displayed on the screen, but is read by most screen readers.

Why: By reading a table's summary, a screen reader-user can quickly decide whether to take the time to read a table in detail; it also helps to let the screen reader-user know what to expect regarding the table's structure.

How: Provide the name of the table in the summary attribute of the <table> tag. A brief description of the content and structure of the table may also be included in the summary. (No summary should be used if a table is used for layout.)

Ref: WCAG 1.0 5.5; WCAG 2.0 1.3.1

M. Frames

1.  Provide concise, unique, and understandable titles for frames.

What: HTML frames and iframes are used to divide web pages into separate areas, each displaying a separate web page. Each frame is identified by its title attribute and each page contained within a frame is identified by its <title> element.

Why: To navigate pages with frames, users who are blind must be able to identify the different frames and understand the purpose of each frame. Most screen readers identify frames by speaking the title of each frame.

How: Give each frame and iframe a concise, unique, understandable title attribute that indicates the frame's function and is unique within the frameset. Do not include the word "frame." Set the <title> element of each page contained within a frame to match its title attribute or to identify the current content of that frame.

Ref: WCAG 1.0 12.1; WCAG 2.0 4.1.2; 508 i

N. Scripts

1. Ensure that scripted functions are usable with assistive technologies.

What: Scripting languages such as JavaScript are simple programming languages that can be used within a web browser to automate tasks and enable pages to respond to user input. Scripts are often used to dynamically show or hide the content that appears on a web page or to perform important functions, such as checking that entries in form fields are valid.

Why: Assistive technologies may interact with scripts in unexpected ways. For example, some assistive technologies may not be able to trigger some script events, and other assistive technologies may not recognize changes to content made using scripts. However, assistive technology users need to be able to access the same essential content and functionality whether scripts are fully, partially, or not supported. It is not safe to assume that users with disabilities will have scripting support turned off.

How: Whenever scripts are used, it is the responsibility of the page developer to thoroughly test using assistive technologies to ensure that all information and functionality is accessible. Testing should confirm that content is usable with system large fonts and high contrast display settings, that interface elements are focusable and operable using the keyboard, that tab and reading order are appropriate, and that all content can be identified and operated with leading assistive technology tools. If there is any doubt, err on the safe side by ensuring that the essential elements of the page do not rely on scripts.

Scripting features that are purely decorative and do not present any significant information or functionality do not need to be made accessible.

Ref: WCAG 1.0 6.2, 6.3, 6.5, 8.1; WCAG 2.0 1.3.1, 4.1.2; 508 l

2. Ensure that significant interactions can be performed with both keyboard and mouse.

What: Scripts can trigger changes when the user performs specific actions. For example, an image can change color when the mouse pointer hovers over it (i.e., the onmouseover event). Different events are triggered by either mouse or keyboard actions.

Why: Users with physical impairments may be able to use the keyboard but not the mouse. Individuals who cannot see the mouse pointer on the screen must use the keyboard for all interactions. Scripts that can only be triggered by the mouse are not accessible to these individuals.

How: Whenever using a mouse-only event (e.g., onmouseover, onmouseout) to trigger a significant script action, use the corresponding keyboard event (e.g., onfocus, onblur). Ensure that scripts are attached to elements that can receive keyboard focus, such as links and form fields.

Also, make sure that keyboard events do not unintentionally trigger script actions. For example, when a keyboard user arrows through the options in a drop-down list (<select>), the onchange event fires once for each option; if a script attached to this event reloads the page (or causes some other significant change), it may be impossible for a keyboard user to operate the control.

Ref: WCAG 1.0 6.4, 9.2, 9.3; WCAG 2.0 2.1.1 ; 508 1194.21 a

3. Avoid changing focus unexpectedly.

What: Scripting can be used to move focus from one element to another, load a new page, or open a new window.

Why: Users may be disoriented by changes that they do not expect.

How: In most cases, changes to focus, location, or the current window should be initiated by a user activating (clicking) a link or button. If changes are initiated by other actions, make sure that there is an obvious cause-and-effect relationship between the action and the change. If changes are not likely to be expected, it may be necessary to provide explicit instructions to users before the changes occur.

Ref: WCAG 1.0 8.1; WCAG 2.0 3.2.1, 3.2.2; 508 l

4. Avoid changing content unexpectedly.

What: Scripting can be used to add or change content on a web page.

Why: Users, especially those using screen readers and screen magnifiers, may not notice that content has changed on a different part of the page. If changes occur in parts of the page that have already been read, the user is not likely to "back up" to find the new content.

How: In most cases, content should only be changed or added after the current point of focus in the tab/reading order. For example, if entering a value in a field causes text to appear, the text should appear after that field in the tab/reading order. It is also important to ensure that changes happen quickly enough that they are complete before the user reaches the changed element. For example, if selecting an item from a list box changes the value in a subsequent field, the change must be complete before the focus moves to the subsequent field. If content is changed above the user's focus, or if changes occur slowly enough that a user may move past the changed element before the change is complete, it may be necessary to provide an alert box or other instruction to direct the user to the changed element.

Ref: WCAG 1.0 8.1; 508 l

O. Embedded Objects

1. Use accessible embedded objects whenever possible.

What: "Objects" include a variety of non-HTML technologies, such as Java and Flash, that can be embedded within web pages. These technologies require additional software to be downloaded, installed, and run before the content can be viewed or used. Embedded objects operate with their own user interfaces, which are separate and different from that of standard web pages.

Why: Because embedded objects have their own interfaces, they must be accessible in and of themselves. If essential content or functionality is presented using an object that is not accessible, it will not be usable by individuals with disabilities.

How: Check with the manufacturer and/or developer to determine if and how the technology can be made accessible.

Ref: WCAG 1.0 8.1; WCAG 2.0 4.1.2; 508 m


P. Downloadable Objects

1. Provide accessible HTML or text versions of non-accessible downloadable documents whenever possible.

What: Downloadable documents are often provided in formats such as Adobe Acrobat Portable Document Format (PDF), Microsoft Word, Microsoft PowerPoint, etc. Each document format has its own accessibility issues and may or may not provide appropriate techniques to address accessibility. A document is considered natively accessible if it follows the accessibility techniques for its format.

Why: Because non-HTML documents cannot implement HTML accessibility techniques, they must be accessible in and of themselves. If essential content or functionality is presented in a downloadable document that is not accessible, it will not be usable by individuals with disabilities.

How: Check with the manufacturer and/or publisher of the format of a downloadable document to determine if and how it can be made accessible. If accessibility techniques exist, ensure that the downloadable

Note: See Adobe's Accessibility Resource Center ( for information about PDF accessibility.

Ref: n/a

2. If a downloadable document cannot be made natively accessible, provide an accessible alternative that includes the same content and functionality.

What: If a downloadable document cannot be made natively accessible, it may be possible to provide both the original document and an equivalent accessible alternative.

Why: By providing both the original and accessible versions, the same content and functionality can be available to all users.

How: Wherever a link is provided to an inaccessible document, also provide a link to an accessible version, preferably in HTML format. Make sure that the information and functionality is completely equivalent and up-to-date. Be sure to consider whether the inaccessible version is actually necessary. If an accessible alternative cannot be provided electronically, provide information on how to obtain an alternate format (e.g., large print, Braille, audio recording) in a timely manner.

Ref: WCAG 1.0 11.1, 11.4; WCAG 2.0 1.1.1; 508 k

Q. Timing

1. Notify users of time limits and provide a means to extend time if possible.

What: Some web pages, frequently those that require a user to log in, time-out after a certain period of inactivity and require the user to start over.

Why: Users with visual, physical, or cognitive disabilities may require more time than average to read and interact with a web page.

How: Provide a clear explanation of any time limits. If possible, offer the user a way to extend or remove the limits. Avoid using time limits unnecessarily.

Ref: 508 p; WCAG 2.0 2.2.1

2. Do not automatically refresh the current page.

What: It is possible to cause web pages to automatically re-load their content on a certain interval. For example, a page containing news headlines might refresh every few minutes to present the most current items.

Why: When a page automatically refreshes, it can cause a screen reader to re-start reading from the beginning of the page.

How: Do not use http-equiv="refresh". If necessary, provide a link or control to allow the user to refresh a page at his or her discretion.

Ref: WCAG 1.0 7.4, 7.5; WCAG 2.0 2.2.1

3. Avoid automatically opening new windows.

What: It is possible to cause hypertext links to open pages in a new browser window, or to automatically open additional windows when a page loads or unloads.

Why: It may not always be obvious to users, especially those with limited vision, blindness, or cognitive disabilities, when a new window has opened. It can be confusing when features such as the browser's "back" button no longer work as expected.

How: Clearly identify any links that will open new windows by providing an indication in the link text or title attributes. In more complex web sites or applications, you may want to consider allowing users to select their preference for whether links are opened in new windows or not.

Ref: WCAG 10.1

R. Page Layout

1. When using tables for layout, ensure that reading order is logical.

What: HTML tables are sometimes used to lay out web pages in multiple columns and sections (instead of actually presenting data). "Reading order" refers to the order in which a screen reader would read through the table.

Why: Screen readers read through tables in the order in which cells are defined in the HTML code, which can be very different from the order that someone reading visually would follow. It is essential that the reading order match the logical flow of the document so that a screen reader user would hear the document in the same order that a visual reader would read it.

How: Avoid using tables for layout whenever possible. If tables are used for layout, check the reading order by following the order in which the table cells appear in the code. If necessary, restructure the table to achieve an appropriate reading order.

Ref: WCAG 1.0 5.3; WCAG 2.0 1.3.2

2.  When using style sheets for layout, ensure that reading order is logical.

What: The positioning features of Cascading Style Sheets can be used to position elements visually almost anywhere on a web page.

Why: Screen readers read through the elements on a web page in the order in which they appear in the page code, regardless of how they are positioned using style sheets. It is essential that the reading order match the logical flow of the document so that a screen reader user would hear the document in the same order that a visual reader would read it.

How: Check the reading order by following the order in which elements appear in the HTML code. Adjust the reading order by rearranging the order in which elements are defined in the code.

Ref: WCAG 1.0 6.1; WCAG 2.0 1.3.2; 508 d          

3. Avoid horizontal scrolling.

What: If a web page is wider than the window or screen in which it is viewed, most browsers will display a horizontal scroll bar and require the user to manually scroll to see the entire page.

Why: When a screen magnifier enlarges a web page, it also reduces the field of view so that the user must pan (scroll) to see the entire page. When the web page being viewed also requires horizontal scrolling, the combination can be awkward or unusable. Keyboard users may also find repetitive scrolling fatiguing and inefficient.

How: Design pages so that they can resize to fit the width of the user's browser. Use relative widths and check for horizontal scrolling using a screen resolution of 800 by 600 pixels. If scrolling cannot be avoided, place the least important content in the rightmost part of the page.

Ref: WCAG 2.0 1.4.8

S. Page Content

1. Use the clearest, simplest, and most concise language appropriate for a page's subject matter.

What: "Clearest, simplest, and most concise language" refers to the words and grammar used in the content of a web page. It is a subjective goal that depends on the subject matter and intended audience of each web page.

Why: Clear and simple language is easier for all readers, and especially those with cognitive or learning disabilities. Simple language also helps individuals whose primary language is American Sign Language, which differs significantly from written English.

How: Be concise and avoid jargon. Have someone else proofread your text. Do user testing with people from your intended audience if possible.

Ref: WCAG 14.1

T. Alternative Accessible Versions

1. Use separate accessible versions only as a last resort.

What: Separate accessible or "text-only" versions are often offered instead of providing a single accessible site.

Why: Manually developing and maintaining a separate "text-only" version of an entire site is tremendously demanding of time and resources. In practice, "text-only" versions are rarely kept complete or up-to-date. Given advances in accessibility techniques and assistive technologies, "text-only" sites are simply not necessary in most cases.

How: Follow these standards to develop a single site that is universally accessible and efficient to maintain.

Ref: WCAG 11.4; 508 k

U. Contact Information

1. Provide contact information.

What: Contact information should be identified. Contact information should include email, telephone, TTY, and mailing address.

Why: Individuals with disabilities may need to report accessibility problems or request information in an alternate accessible format.

How: List accessibility contact information on the home page or contact page. Inquiries about accessibility, especially requests for materials in alternate format, need to be handled in a timely manner.

Ref: n/a

V. Testing

1.  Test for accessibility.

What: Testing includes functional tests with assistive technology, browser and operating system functionality as well as automated testing software.

Why: Testing will determine whether accessibility has actually been accomplished.

How: Use browser and operating system accessibility features and leading assistive technology software such as screen readers and magnifiers to test for functional accessibility. Use an automated testing tool to identify common accessibility problems. If possible, do user testing with people with disabilities.

Ref: n/a



IV. Applicability

This policy applies to all web content published by all Executive Branch and semi autonomous state agencies. It is intended for all web authors, developers, and content contributors creating or maintaining web pages for the State. The basic concepts should be understandable by anyone with a general familiarity with web technologies. Knowledge of Hypertext Markup Language (HTML) and related web languages will help in fully understanding the Implementation Guidelines. As the technology evolves, this policy may be amended to ensure consistency in the use of technologies by state employees.


All federal and state statues and policies apply including:

·         Section 508 of the Rehabilitation Act of 1973


·         Americans with Disabilities Act of 1990


·         Maine Human Rights Act

·         Accessibility Policy on Effective Electronic Communications

·         Information Technology Security Policy   

·         Policy Concerning the use of State-Owned Information and Technology (I.T.) and Related Communications Equipment and Resources

·         Maine State Archive - Record Retention Schedules

V. Responsibility

A. Agency: Agencies are directly responsible and accountable for providing equal access to information and services published through their web sites.  This responsibility is not effected by waivers from some of the specifics of this policy. 

B. Chief Information Officer of the State of Maine - Title 5, Maine Revised Statutes, Chapter 163 §1973, Section 1, Paragraph B authorized the Chief Information Officer to  “set policies and standards for the implementation and use of information and telecommunications technologies, including privacy and security standards and standards of the Federal Americans with Disabilities Act (ADA), for information technology.


VI. Definitions

A. Landing page - A landing page is the page website visitors arrive at after clicking on a link on another website. It could be a home page, or any other page in a site.

VII. References

A. IT Policies, Standards and Procedures

VIII. Document Information

Initial Issue Date:  May 1, 2012

Latest Revision Date:  November 12, 2014

Point of Contact:  Henry Quintal, Architecture-Policy Administrator, OIT, 207-624-8836.

Approved By:  James R. Smith, Chief Information Officer, OIT, 207-624-7568.

Position Title(s) or Agency responsible for enforcement: James R. Smith, Chief Information Officer, OIT, 207-624-7568

Legal Citation: 5 M.R.S.A. Chapter 163 Section 1973 paragraphs (1) B and (1) D, which read in part, “The Chief Information Officer shall:” “Set policies and standards for the implementation and use of information and telecommunications technologies…” and “Identify and implement information technology best business practices and project management.”

Waiver Process: See the Waiver Policy[1]