Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 2. Information Technology

Chapter 25. Web Services

Section 5. Accessibility Guidelines for the Web

2.25.5  Accessibility Guidelines for the Web

2.25.5.1  (04-01-2006)
Purpose

  1. The purpose of this IRM is to provide rules and guidelines for creating accessible web content and applications on internal and external IRS web sites. Most of this IRM is drawn from Section 508 of the Rehabilitation Act of 1973 (Section 508), as amended (29 U.S.C. Section 794d). However, this IRM will also incorporate standards and procedures that the IRS considers useful or necessary to ensure that all employees have full access to information resources.

    • When developing, procuring, maintaining or using Electronic and Information Technology (EIT), the IRS must ensure that employees with disabilities have access to and use of information and data that is comparable to that for other employees without disabilities.

    • Members of the public with disabilities seeking information or services from the IRS have access to and use of information and data that is comparable to that for members of the public without disabilities.

  2. The key to compliance with this IRM is adherence to the technical requirements. These technical requirements are identified in this policy under Section 2.25.5.4.4, Web-based Intranet and Internet Information and Applications Standards Extract.

  3. IRS employees are expected to ensure that the guidelines specified under this IRM are adhered to and maintained within the fundamental nature of Section 508.

2.25.5.2  (11-01-2003)
References and Regulations

  1. The IRS accessibility policy originates from:

    • Federal Acquisition Regulations (FAR) web site, http://www.arnet.gov/far

      Note:

      Part 10 (Market Research) and Subpart 39.2 (EIT).

    • Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. Section 794d), as amended by the Workforce Investment Act of 1998 (105 P.L. 220), August 7, 1998, http://www.section508.gov.

  2. Links:

    • Information Resources Accessibility Program Office (IRAP), http://irap.no.irs.gov.

    • Web Services Division web site, http://ws.web.irs.gov.

    • The official IRS web site for 508 web requirements, http://508.web.irs.gov/IRM.

    • IRS School of Information Technology online Section 508 course, http://learning.irs.gov.

    • Alternative Media Center Section 508 online tutorial, http://amc.enterprise.irs.gov/tutorials/descnarr/.

    • Other IRS web sites for documentation, http://amc.enterprise.irs.gov.

    • The Center for Information Technology Accommodation (CITA), U.S. General Services Administration's Office of Government-wide Policy, www.section508.gov and www.gsa.gov.

    • Architectural and Transportation Barriers Compliance Board, The Access Board, Electronic and Information Technology Accessibility Standards (Section 508), Guide to the Section 508 Standards for Electronic and Information Technology, www.access-board.gov/sec508/guide/index.htm. The Access Board is an independent federal agency devoted to accessibility for people with disabilities.

    • World Wide Web Consortium (W3C) Web Accessibility Initiative Information, http://www.w3.org/WAI.

    • First Gov Section 508 Information, http://www.firstgov.gov/Government/Federal_Workers.shtml.

    • National Cancer Institute, Web Accessibility Plans, offers tutorial on scripting, http://oc.nci.nih.gov/web508/tut-l.html.

    • IBM Website featuring information on scripting and accessibility, http://www-3.ibm.com/able/webscripts.html.

    • National Center for Accessible Media (NCAM) http://main.wgbh.org/wgbh/access/index.html.

    • Reference site for DoIT Learning Technologies and Distance Education, http://wiscinfo.doit.wisc.edu/ltde/ORFI/ces/webpages.htm.

    • Reference site for American Council of the Blind, http://www.acb.org/accessible-formats.html.

    • Reference site for Adobe Systems, Inc., http://access.adobe.com.

    • Developer’s tutorial site, http://www.devguru.com.

    • Reference site on JavaScript, http://www.JavaScripts.com and http://webdeveloper.earthweb.com/webjs/.

    • Reference site for Macromedia, Inc. http://www.macromedia.com/macromedia/accessibility/policy.html.

2.25.5.3  (11-01-2003)
Program Offices

  1. This IRM provides information on the IRS’ Information Resources Accessibility Program (IRAP) and the Web Services Division (WS) and how they pertain to web accessibility.

2.25.5.3.1  (11-01-2003)
Information Resources Accessibility Program (IRAP) (OS:CIO:I:I:IR)

  1. For additional information on Section 508, contact the IRS’ Information Resources Accessibility Program (IRAP). IRAP’s mission is to increase access to information technology resources for employees and customers with disabilities by providing leadership toward upfront systems accessibility and infrastructure support for information technology accommodations. For Accessibility issues such as assistance with Section 508 accessibility testing or assistive technology functions in relationship to a particular web-based product, contact IRAP at:

    5000 Ellin Road

    Attn: IRAP, OS:CIO:I:I:IR

    B3-300 NCFB

    Lanham, MD 20706

    Phone: (202) 283-0283

    TTY: (202) 283-6566

    Fax: (202) 283-6565

    IRAP’s Intranet web site is: http://irap.no.irs.gov.

2.25.5.3.2  (11-01-2003)
Web Services Division (OS:CIO:I:W:P)

  1. The Web Services Division (WS) provides technical assistance with IRS’ web site design and redesign, web development and enhancement, web hosting, security liaison, web master publishing support, and customer support and guidance. WS also provides technical assistance with IRS Intranet standards. The mission of WS is:

    "To deliver top quality Web Services that continuously add value to the IRS through partnership with our customers and the ability to leverage and deliver all aspects of MITS Services. "

  2. Contact WS for web site development issues or for technical assistance with IRS Intranet standards at (202) 283-3500.

  3. WS’ web site is: http://ws.web.irs.gov.

2.25.5.3.3  (11-01-2003)
Roles and Responsibilities

  1. This IRM provides the roles and responsibilities of IRAP and WS.

2.25.5.3.3.1  (11-01-2003)
Information Resources Accessibility Program (IRAP)

  1. The primary roles and responsibilities for IRS accessibility guidance belong to IRAP. The IRAP Program Manager serves as the official Section 508 Coordinator for the IRS. As such, IRAP will:

    1. Proactively seek and bring together Section 508 related updates (laws, regulations, policies, guidelines, etc.).

    2. Notify Web Services directly of these updates.

    3. Promulgate and market accessibility requirements throughout the agency, as necessary.

    4. Assist Web Services in preparing the accessibility portion of a web development life cycle framework that can be integrated into day-to-day operations.

    5. Participate with Web Services in the evaluation of automated testing tools that support 508 web accessibility for possible use in the web development life cycle.

    6. Endorse selected Section 508 software tools that assist site owners in making their web sites compliant with this IRM.

    7. Support Web Services' Accessibility Plan for technical support by partnering in plan formulation and endorsement.

2.25.5.3.3.2  (11-01-2003)
Web Services Division

  1. WS will serve as the source for technical guidance and support for Accessibility standards and initiatives related to this IRM. WS will provide technical customer support in the following ways:

    1. Act on all Accessibility notices for required changes with a plan for action and implementation, including distribution among the IRS web development and management organizations.

    2. Create an accessibility portion (with assistance from IRAP) of a web development life cycle system that can be integrated into day-to-day operations.

    3. Seek and perform analysis and review of automated tools that will assist customers with accessibility diagnostics, along with support from IRAP.

    4. Provide customers with technical guidance for web site design and content formulation.

    5. Ensure that new and launched web sites comply with Section 508 requirements.

    6. Establish and maintain an Accessibility Plan in support of compliance with this IRM.

    7. Ensure that the applicable areas of the Accessibility Plan are followed by all web site and application development personnel.

2.25.5.4  (11-01-2003)
Technical Standards for EIT

  1. This IRM defines accessibility and the information processed by web-based Electronic Information Technology (EIT). It provides the criteria and explanations for web-based Intranet and Internet information and applications standards.

2.25.5.4.1  (11-01-2003)
Accessibility

  1. Accessibility is the assurance that access to EIT is available to the widest possible audience. The design and coding of a web page or application determines its accessibility.

2.25.5.4.2  (11-01-2003)
Information Processed by EIT

  1. Any information that is captured, used, re-used, disseminated, stored or otherwise processed by web-based EIT is covered under this IRM. EIT must be available to anyone who has the authority to access IRS information regardless of ability.

  2. If information on the network is not available in a standards compliant form, then it must be made available in an alternative (accessible) form. The process for obtaining accessible information must be as easy for disabled users as it is for non-disabled users.

2.25.5.4.3  (11-01-2003)
Accessibility Rules and Guidelines

  1. This IRM specifies criteria for accessible web-based technology and information based on rule of law. Other rules and guidelines specified in this IRM were developed by IRAP, Web Services, other offices in the IRS, other government agencies, the W3C, and organizations with expertise on how to provide universal accessibility on the web. These requirements

    1. Ensure access for people with visual disabilities who rely on various assistive products for obtaining EIT that is displayed in a text or graphics format. Assistive products for people with visual disabilities consist of screen enlargement and screen readers that translate what is on a computer screen into audible output or refreshable Braille displays.

    2. Ensure access for people with hearing disabilities who rely on various assistive products for obtaining EIT that is conveyed by sound on a computer system. Assistive products that turn sound into a readable output consist of electronic text, visual signals, or captioning.

    3. Ensure access for people with mobility disabilities who rely on various assistive products for obtaining EIT. Assistive products include fixed split keyboards, alternative pointing devices and switches for individuals who have difficulties clicking small buttons displayed on the computer.

    4. Ensure access for people with cognitive and language disabilities to easily obtain EIT. Information should not be complex or have inconsistent visual displays or word choices that can make a web site inaccessible.

    5. Ensure access for people with seizure disorders can obtain computer-based information, by not creating pages that flicker at a rate that is likely to cause seizures. The flicker rate has been defined to cause seizures between 2 Hz (cycles) to 55 Hz (cycles). Some banner ads, designed to grab the attention of prospective customers, flash or flicker at rates that may induce seizures in those susceptible to them

2.25.5.4.4  (11-01-2003)
Web-Based Intranet and Internet Information and Applications Standards Extract

  1. All IRS web sites and applications must be accessible in accordance with this IRM. This IRM is fully in compliance with Section 1194.22 of the 508 web standards and associated guidance with The Access Board and the WC3. A web site will be in compliance with the technical requirements if it meets the criteria specified in Section 2.25.5.4.5 of this IRM. The Section 508 Statute upon which this guideline is based is provided in Exhibit 2.25.5-1 of this IRM.

  2. These provisions provide the technical requirements that must be followed by IRS employees and contractors when developing web pages and applications for internal or external use.

  3. These standards apply to all document formats posted to IRS Internet and Intranet web sites, including MS Word, Excel, PowerPoint, HTML, PDF, Flash and others. Refer to Section 2.25.5.4.5.16, IRS Technical Requirement (q), Non-HTML Content.

  4. These technical requirements apply to any page, document or application that was developed for the web after June 21, 2001. In addition, these requirements apply to any web page or application that was created before the above date, and has since been modified by more than 30 percent, or when application functionality is added. Web pages and applications that were created before the above date and receive minor modifications should comply with this IRM whenever possible.

  5. The techniques described in this IRM are not necessarily the only methods of providing compliance with Section 2.25.5.4.5 of this IRM. With the evolution of technology, other techniques may become available or even preferable. Web Services will review this IRM on an annual basis and make updates as necessary to ensure compliance with Section 508 technical standards and IRS requirements. When new or additional information on standards or techniques become available, the information will be posted at http://508.web.irs.gov/IRM.

  6. The IRS abbreviated technical requirements are listed as follows:

    1. Alternatives for Non-Text Elements

    2. Alternatives for Multimedia Presentations

    3. Colors

    4. Readability/Style Sheets

    5. Sever-Side Image Maps

    6. Client-Side Image Maps

    7. Data Tables

    8. Multi-level Data Tables

    9. Frames

    10. Screen Frequency

    11. Text-Only Alternatives

    12. Displaying Content with Scripts

    13. Applets and Plug-Ins

    14. On-Line Forms

    15. Skip Repetitive Navigation

    16. Timed Responses

    17. IRS Technical Requirement on Non-HTML Content

2.25.5.4.5  (11-01-2003)
IRS Abbreviated Technical Requirements

  1. The remaining part of this IRM describes the IRS abbreviated technical requirements in detail and provides an explanation for each. A complete list of Accessibility Code examples are provided in Exhibit 2.25.5-2. For more information and resources about accessibility in Web Services or the IRS, refer to the IRAP web site, http://irap.no.irs.gov and http://508.web.irs.gov/IRM.

2.25.5.4.5.1  (11-01-2003)
Alternatives for Non-Text Elements, Technical Requirement (a)

  1. Technical Requirement (a). A text equivalent for every non-text element shall be provided via "alt," "longdesc," or in element content.

  2. A non-text element is an image, graphic, audio clip, or other feature that conveys meaning through a picture or sound. The following are possible examples of non-text elements: buttons (when button text is an image), photographs, line art, charts, graphs, image maps, animated gifs, ASCII art such as a happy face symbol";-)" , audio files, video files, maps, math equations, images used as bullets, scripts, streaming media and so forth. HTML bullets <ul> are NOT considered a non-text element. See Exhibit 2.25.5-3, Terms and Definitions for a listing of non-text elements that are covered under this rule.

  3. For simple content, a text equivalent may need to only describe the function or purpose of content. For complex content (charts, graphs, etc.), the text equivalent may be longer and include descriptive information.

  4. Assigning Text to Elements:There are several methods of providing textual information so that it can be recognized by assistive technology devices. For instance, the <img> tag can accept an " alt" attribute that can include text to describe the picture. For example: <img src="logo.gif" alt="IRS Logo" >.

  5. However, not all images require alt tags with descriptions. Images that do not convey content or aid in navigation need null alt tags. For example, transparent gifs are often used for spacing. Adding a text description to these elements will produce unnecessary clutter for users of assistive technology. For such graphics, an empty alt attribute is required. For example: <img src="transparent.gif" alt="" > .

  6. If an <a> tag surrounds both text and an image, use alt="" on the image, as the text in the link should explain the purpose of the link, not the alt. There is no reason to duplicate the text. For example: <a href="info.html" ><img src=" info.gif" alt="  " >More Information <\//a> .

  7. If an image stands alone in an anchor tag <a>, an alt tag is necessary.

  8. If a textual description of the image is embedded in the context of the page, an alt tag may not be necessary. For example: 'Here is a sample picture of our library.' <img src="pictureoflibrary.jpg " >.

  9. An alternative text is required between opening and closing <applet>or <object> tags. For example:<APPLET CODE=" MyCoolApplet.class" WIDTH="200" , HEIGHT=" 100" >This applet displays current stock prices</APPLET>.

  10. Ensuring Compliance: Compliance with this technical requirement can generally be verified by a manual code review of the HTML code. Using a tool, such as an AccMonitor, may be helpful to do this. Find every <img> <applet> and <code> tag in the HTML and make sure it has proper contextual information or it is assigned a proper null value.

2.25.5.4.5.2  (11-01-2003)
Equivalent Alternatives for Multimedia Presentation, Technical Requirement (b)

  1. Technical Requirement (b). Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

  2. Equivalent Alternatives: Captioning for the audio portion and audio description of visual information of multimedia presentations are considered equivalent alternatives. This technical requirement requires that the captioning must be synchronized with the audio. Synchronized captioning is required so someone reading the captions can also watch the speaker and associate relevant actions with the speech. In addition, video descriptions of visual activity also are required when the visual activity can not be determined from the accompanying audio alone. Audio description should be inserted during pauses in the audio portion of the presentation.

  3. Slide Presentations: Frequently, slide presentations such as MS PowerPoint are inaccessible because of graphs, charts, and tables as well as many image elements. Such files should be saved as HTML and the HTML should be edited so that it is accessible. The HTML version will then be made available in the same context as the link to the original file.

  4. Audio Files with no Video: Since audio is a non-text element, a text transcript must be made available.

  5. Live Audio and Video Webcast Speeches: Live audio and video webcast speeches qualify as a multimedia presentation and requires the speech to be captioned and the visual portion to be audio described. To view an example, access the National Center for Accessible Media (NCAM) web site at http://main.wgbh.org/wgbh/access/dvs/lion.ram.

  6. Ensuring Compliance: No assistive technology is required to verify compliance with Technical Requirement (b). Compliance with this requirement is verified with a manual review of the HTML code.

2.25.5.4.5.3  (11-01-2003)
Colors, Technical Requirement (c)

  1. Technical Requirement (c). Web pages shall be designed so that all information conveyed with color is also available without color.

  2. Page Display: This technical standard addresses not only the problem of using color to indicate emphasized text, but also the use of color to indicate an action. This technical standard does not prohibit the use of color to enhance identification of important features, such as red text for headlines. It does, however, require that some other method of identification, such as text labels, must be combined with the use of color. For example, a web page that directs a user to "press the green button to start" should also identify the green button in some other fashion than simply by color.

  3. Ensuring Compliance: No assistive technology is required to test for compliance with Technical Requirement c. There are three ways of testing a web page to determine if this requirement is being met:

    1. By either viewing the page on a black and white monitor.

    2. By printing the page on a black and white printer.

    3. By testing for color. Insert the text between brackets below in the address of the page to be tested in Internet Explorer (IE). [javascript:document.body.style.filter='gray()';void(null)]. A favorites link that contains the javascript can also be created.

2.25.5.4.5.4  (11-01-2003)
Readability/Style Sheets, Technical Requirement (d)

  1. Technical Requirement (d). Documents shall be organized so they are readable without requiring an associated style sheet.

  2. Style Sheets: This requirement requires that web pages using style sheets are able to be read accurately by browsers that do not support style sheets and by browsers that have disabled the support for style sheets. A style sheet is a set of statements that specify presentation of a document.

  3. The IRS requires "external" style sheets, in which the style rules are set up in a separate file. An example of an external style sheet is: <link rel=stylesheet type="text/css" href="section508.css" >.

  4. Ensuring Compliance:No assistive technology is required to test for compliance with Technical Requirement d. However, to turn off the style sheet control set up a link called "Kill Style Sheet" under "Favorites" in IE that contains the URL: javascript:for(i=0;i<document.styleSheets.length;i++) document.styleSheets[i].cssText="" ;void(null)>. This will display the web page or application without the style sheets.

2.25.5.4.5.5  (11-01-2003)
Server-Side Image Maps, Technical Requirement (e)

  1. Technical Requirement (e). Server-side maps shall not be used unless there is no other alternative. Client-side maps shall be used whenever possible. Redundant text links shall be provided for each active region of a server-side image map. See Section 2.25.5.4.5.6 for client-side maps.

  2. When a web page uses a server-side image map to present the user with a selection of options, browsers cannot indicate to the user the URL that will be followed when a region of the map is activated. Therefore, the redundant text link is necessary to provide access to the page for anyone not able to see or accurately click on the map.

  3. Ensuring Compliance: As with Technical Requirement (a), compliance with Technical Requirement (e) can be verified with a manual review of the HTML code. Web developers should look for the use of the "ismap" code to identify the use of a server-side image map.

2.25.5.4.5.6  (11-01-2003)
Client-Side Image Maps, Technical Requirement (f)

  1. Technical Requirement (f). Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

  2. Image Maps: An "image map" is a picture (often an actual map) on a web page that provides different "links" to other web pages. For all image maps, content developers must supply a text equivalent. As with other links, the link text should make sense when read out of context.

  3. All link text, whether it is visible on a page or the alt text on image links, must clearly tell the user the purpose of the link. Identifying where the link goes is the key to meaningful link text. Phrases like " Click Here" or "Learn More" are of little use to someone using an assistive technology. Do not use the phrase " link to" to preface link text.

  4. The client-side image map allows a content developer to assign text to each image map "hot spot." This feature means that users using assistive technology can easily identify and activate regions of the map. To make an image map accessible, content developers must ensure that each action associated with a visual region may be activated without a pointing device. See Figure 2.25.5-1 for an example of a client-side image map.

    Figure 2.25.5-1

    Client-Side Image Map

    <img src="navbar.gif" border=" 0" usemap="#Map" >  
    <map name="Map" >  
    <area shape="rect" coords="0,2,64,19 " href="general.html" alt="information about us" >...  
    </map>  

  5. Ensuring Compliance: Compliance to Technical Requirement (f) can be verified with a manual review of the HTML code. Web developers should look for the use of the "usemap" code to identify the use of a client-side image map.

2.25.5.4.5.7  (11-01-2003)
Data Tables, Technical Requirements (g) and (h)

  1. Technical Requirements (g) and (h). Row and column headers shall be identified for simple and multi-level data tables. Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

  2. The "<pre>" tag shall not be used to simulate a table.

  3. When tables are used to represent logical relationships among data, such as text, preformatted text, images, links, forms, form fields, other tables, etc. that information is called "tabular information " and the tables are called "data tables." The relationships expressed by a table may be rendered visually (usually on a two-dimensional grid), aurally (often preceding cells with header information), or in other formats.

  4. Table descriptions shall be placed adjacent to the table or in the body of the table, using such tags as the CAPTION tag. This is not an alternative to making the contents of the tables compliant.

  5. The scope attribute shall be used whenever possible to provide an association between a header and its related information.

    • The "scope" attribute is the most effective way of making HTML compliant with Technical Requirements (g) and (h). The scope attribute also works with some (but not all) assistive technology in tables that use "colspan" or "rowspan" attributes in table header or data cells.

    • The first row of each table should include column headings. Typically, these column headings are inserted in <th> tags, although <td> tags can also be used. These tags at the top of each column should include the following attribute: scope="col" .

  6. Figure 2.25.5-2 provides an example of source code for tables. In this example, the table summarizes the work schedule of an employee.

    Figure 2.25.5-2

    Data Table

    <table>  
    <tr>  
    <th>&nbsp;</th>  
    <th scope="col" >Spring</th><th scope="col" >Summer</th><th scope=" col" >Autumn</th><th scope="col" >Winter</th> </tr>  
    <tr> <td scope="row " >Betty,<\//td> <td>9-5<\//td> <td>10-6
    <\//td> <td>8-4<\//td> <td>7-3<\//td>     		 
    </tr>  
    </table>  
    Table would display as follows:  
      Spring Summer Autumn Winter  
    Betty 9-5 10-6 8-4 7-3  

  7. If the table is already coded with ID and Headers, it may already be considered accessible. When creating new tables, use the "scope " attribute. Unlike using the "scope" attribute, using the "ID" and "Headers" attributes requires that every data cell in a table include special attributes for association. The "scope" attribute is much easier to code, and provides equal accessibility.

  8. Ensuring Compliance: A manual review of the HTML code is adequate to determine accessibility. Assistive technology devices, such as the screen reader Job Access with Speech (JAWS), can optionally be used to determine the accessibility of the table.

2.25.5.4.5.8  (11-01-2003)
Frames, Technical Requirement (i)

  1. Technical Requirement (i). Frames shall be titled with text that facilitates frame identification and navigation. IRS web pages should not use frames because frames may present problems with bookmarking, printing, and accessibility.

  2. Identifying Frames: To identify frames, include text within the body of each frame that clearly identifies the frame. This text should be "invisible" to prevent visual clutter.

  3. Content developers shall include meaningful text in the <frame> tag's "title" attribute. A top frame used for navigation shall have an alt tag of "top navigation." A top frame used only as a banner shall have an alt tag of "banner frame." A frame on the left margin shall have an alt tag of "left navigation. " A frame on the right margin shall have an alt tag of " right navigation."

  4. Figure 2.25.5-3 provides an example of conforming code for identifying frames.

    Figure 2.25.5-3

    Example Code for Identifying Frames

    <frameset cols="30%, 60%" >
    <frame src="navlinks.html" name=" navlinks" title="Left Navigation" >
    <frame src="geninfo.html" name=" contents_page" title="Main Content" >
    </frame>

  5. Ensuring Compliance: Technical Requirement (i) compliance can be verified with a manual review of the HTML code. Assistive technology devices, such as the screen reader JAWS, can optionally be used to determine the accessibility of each frame.

2.25.5.4.5.9  (11-01-2003)
Screen Frequency, Technical Requirement (j)

  1. Technical Requirement (j). Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz (cycles) and lower than 55 Hz (cycles). The exception is menu bars that stay visible during scrolling. Animated gifs shall be avoided.

  2. People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).

  3. Flashing or flickering elements are usually added through technologies such as animated gif's, Java applets, or third-party plug-ins or applications. Review the software manual or the script to ensure the correct flicker rate. Animated gif's are images that download in a single file (like ordinary image files), but have content that changes over short periods of time. Like other images, however, they are usually incorporated through the use of the <img> tag.

  4. Ensuring Compliance: No assistive technology is required to test for compliance with Technical Requirement (j). Individuals should use the blink rate specifications provided with the blink generation software to determine compliance with this standard. Refer to the code or the development tool’s operating manual for further information.

2.25.5.4.5.10  (11-01-2003)
Text-Only Alternatives, Technical Requirement (k)

  1. Technical Requirement (k). Text-only alternatives shall not be used to ensure accessibility unless absolutely necessary. Text-only pages that require manual updates are specifically prohibited. Manual updates are those which require manual creation of alternate "text only " pages. Dynamically generated pages are required if a user selects text-only as a viewing option.

  2. Text-only pages shall be dynamically updated when the graphic version changes. If a web site uses a text-only alternative, the option to select text-only will be the second available link on the web page and will use a tabindex of 2. Graphic or text links to a text-only page will say, " Text Only." The words or images used for the text-only link do not need to be visible.

  3. Ensuring Compliance: Verification of a text-only page can be achieved through manual code review and the optional use of Assistive Technology, such as a screen reader.

2.25.5.4.5.11  (11-01-2003)
Scripts, Technical Requirement (l)

  1. Technical Requirement (l). When pages use scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

  2. Sample JavaScript and additional information are available at http://508.web.irs.gov/IRM.

  3. JavaScript:The provisions of this technical requirement related to scripting languages, such as JavaScript, require that scripting elements provide functional text. Functional text is informational, descriptive text is for the user of assistive technologies. The intent is for text to be presented that conveys an accurate message of what is being displayed by the script. For example, if a web page uses a script to create a graphic map of menu choices, the web developer may be required to incorporate redundant text links that match the menu choices.

  4. Web developers must ensure that scripting guidelines related to Section 508 are implemented in their web pages. Web developers should incorporate the guidelines presented in this IRM during the development life cycle, before the applications become part of mainstream use.

  5. Recommended Techniques: All of the code used in the Figures 2.25.5-4 and 2.25.5-5 can be found at http://508.web.irs.gov/IRM.

  6. When JavaScript Is Not Supported: Web pages using JavaScript shall provide full functionality without JavaScript, since users have the ability to turn off JavaScript or may be using a browser that does not support JavaScript.

  7. JavaScript URLs:JavaScript URLs are one way to invoke JavaScript functions, and will work even if JavaScript is turned off. Typically, this technique is used as part of <a> anchor links. For example, the following link invokes a JavaScript function called myFunction: <a href="javascript:myFunction();" >Start myFunction</a>.

  8. When an image is used in place of text inside a JavaScript URL, the image shall have a meaningful alt tag. Developers shall not use the title tag in place of the alt tag in this case. The following link invokes the JavaScript function myFunction, but requires the user to click on an image instead of the text "Start myFunction." The alt tag makes the link accessible.

  9. Example: <a href="javascript:myFunction(); " ><img src="myFunction.gif" alt=myFunction></a>.

  10. NoScript Text Equivalent: This technique entails providing a text equivalent to the JavaScript code using the <noscript> element. The <noscript> tag is used to display alternative content for browsers that do not recognize the <script> tag or for those occasions where the user has purposely disabled JavaScript. Figure 2.25.5-4 demonstrates the code for the <noscript> element. In this case, however, the information in the <noscript> section would tend to be inaccurate. This page is in violation of the IRM most of the time because the user without JavaScript would not receive the same information as the enabled user would.

  11. Server-Side Script vs. Client-Side Script: Many of the same functions that are developed in JavaScript can be accomplished with a server-side script, as shown in Figure 2.25.5-5. Server-side scripting performs all of its processing on the web server, and delivers a final product (the web page) to the user's browser. Pages programmed with server-side scripting do not require any special capabilities on the user's computer or browser, so no accommodations are necessary for browsers without JavaScript.

  12. Figures 2.25.5-4 and 2.25.5-5 contain sample code outlining three techniques to make web pages accessible when JavaScript is turned off or not supported.

    Figure 2.25.5-4

    Inaccessible Text Equivalent (NoScript)

    <script language="javascript" >
    <!--
    document.write('<P>Last Modified: '+document.lastModified);
    document.write('<P>');
    //-->
    </script>
    <noscript>
    <p>Last Modified: December 2002</p>
    <noscript>

    Figure 2.25.5-5

    Server-Side Script

    <script language="javascript " runat="server" >
    <!--
    //Scripting run on the server when the page is loaded
    // and before it is sent to browser.
    var d=new Date();
      document.forms[0].DateValue.value=d;
      //-->
    </script>

  13. Event Handlers: An event handler is a script that is invoked when a specific event occurs (e.g., the mouse is moved, a key is pressed, the document is loaded, or a form is submitted). Caution should be exercised when deciding which event handlers to use in web pages, because different assistive technologies provide different degrees of support for different event handlers. Whenever possible, application-level event triggers should be used rather than user interaction-level triggers.

  14. Event handlers should be input device-independent. Device-independent access means that users may interact with the web page with their own preferred input (or output) device. Device-dependent event handlers require a specific kind of input device to invoke the event handler. For example, onDblClick requires a mouse; there is no keyboard equivalent for double clicking. Input devices include pointing devices, such as the mouse, keyboards, Braille displays, speech input software, and other equipment. Output devices include monitors, speech synthesizers, and Braille displays. If device-dependent attributes MUST be used, redundant input mechanisms (i.e., two handlers specified for the same element) shall be required.

  15. Using an event handler saves resources by not requiring the server to do the initial checking, and feedback about errors is almost instantaneous. The disadvantage is that if scripting is turned off or cannot be read by the user’s browser, event handlers will not work.

  16. Accessible Event Handlers: Accessible Event Handlers consist of:

    • onClick:The onClick event handler is triggered when the user clicks on a particular object such as a button. It is often used with links and button elements, and works well with accessible technology. The "value" attribute must contain text that describes the respective type of object in detail so the user is aware of the specific functionality of the object. See Figure 2.25.5-6 for an example of the onClick event handler.

    Figure 2.25.5-6

    An Example of the onClick Accessible Event Handler

    <input type="button" value="Press Here" onclick="alert('Button Clicked')" >

    • onLoad and onUnload: An onLoad or onUnload event handler is invoked when a web page is loaded or unloaded. Because neither event handler is triggered by any user interaction with an element on the page, they do not present accessibility problems. See Figure 2.25.5-7 for an example of the onLoad event handler.

    Figure 2.25.5-7

    An Example of the onLoad Accessible Event Handler

    <body onload="window.alert('Welcome to the IRS site.'); "
    onunload="window.alert('Thank you for visiting the IRS site.');" >

    • onChange: The onChange event handler is triggered when a change occurs to an object. As shown in Figure 2.25.5-8, the onChange code is invoked when the text in the User Name textbox is changed and the focus is moved out of the textbox. The "value " attribute of the INPUT form elements must contain text. The "value" attribute should always clearly define the object and its functionality.

    Figure 2.25.5-8

    An Example of the onChange Accessible Event Handler

    <script language="javascript " >
    <!--
    function validateForm() {
      if (JSForm.UserName.value =="" ) {
      window.alert('A User Name must be entered.');
      }
    }
    //-->
    </script>
    <!--HTML code→
    User Name: <input type=" text" id="UserName" name="UserName "
    value="UserName" onchange="validateForm()" ><br>
    <input type="submit" name="LogIn" value="Log In" >

    Note:

    Pulldown menus that submit using the onChange event handler shall NOT be used. An accessible solution is to program pulldown menus as forms, using server-side scripting and a "submit" button. Another option is to offer alternate forms of navigation, such as simple lists in which all links are visible without any action on the user's part.

    • onSelect:An onSelect event handler is invoked when the user selects some of the text within a text or text area field. See Figure 2.25.5-9 for an example of the onSelect event handler.

    Figure 2.25.5-9

    An Example of the onSelect Accessible Event Handler

    <input type="text"
    name="UserName" value="IRSUser" size="20"
    onselect="alert('You are about to change the user name entered.');" >
    <br>
    <input type="submit" name="LogIn " value="Log In" >

  17. Problematic Event Handlers: The Problematic Event Handlers consist of:

    • onMouseOver and onMouseOut: The onMouseOver and onMouseOut event handlers are triggered when a user rolls over an object with the mouse (onMouseOver) or moves the mouse off of the object (onMouseOut). A screen reader bypasses these event handlers entirely. Accordingly, when these event handlers are used, the information or navigation provided by these event handlers, if any, shall be duplicated through other means.

    • onMouseDown and onMouseUp:The onMouseDown event handler is triggered when the mouse button is pressed by the user. When the mouse button is released, the onMouseUp event handler is triggered. Some assistive technologies cannot detect nor read when the onMouseDown or onMouseUp event handlers are triggered. Thus, these event handlers must be combined with onKeyDown and onKeyUp. Alternatively, the onClick event can be used instead of the Mouse handlers. Refer to paragraph (19), Multiple Input Options, in this section for additional information on the onMouseDown and onMouseUp event handlers.

  18. Inaccessible Event Handlers: The event handlers described below are considered inaccessible event handlers and shall not be used in developing IRS web pages or applications unless absolutely necessary. Inaccessible event handlers consist of:

    • onKeyPress: This event handler shall not be used. Instead, use the onClick event. See discussion below on the onClick event.

    • onDblClick: The onDblClick event handler is triggered when the user rapidly clicks twice on the same element. The onDblClick event handler is not compatible with assistive technologies and shall not be used for developing IRS web pages.

    • onFocus and onBlur:The onFocus event handler is invoked when input focus enters a field either by tabbing or clicking in, but not by selecting input from the field. An onBlur event handler is invoked when input focus leaves a field. For windows, frames and framesets the event handler is invoked when the window loses focus. Although these event handlers do not necessarily present accessibility problems, their behavior can be confusing to a web page visitor and they should be avoided.

  19. Multiple Input Options:This IRM gives recommendations on providing multiple input options. Event handlers that rely on mouse coordinates should not be used because this prevents device-independent input. Multiple input options consist of:

    • Use onMouseDown with onKeyDown: The onMouseDown event handler is invoked when the user depresses a mouse button on an object that supports this event (e.g., button, document, link). The onKeyDown event handler is invoked when a keyboard key is depressed. Audio browsers do not read any changes to the "value" attribute in the textbox because it does not recognize when an object is changed dynamically using JavaScript. See Figure 2.25.5-10 for an example of the onMouseDown with onKeyDown multiple input options event handlers.

    Figure 2.25.5-10

    Example of onMouseDown with onKeyDown Multiple Input Option

    Annual Salary:
    <input type="text" name="Salary " size="7" value="$40,000"
    onmousedown="window.alert('You cannot change a value in this field.');"
    onkeydown="window.alert('You cannot change a value in this field.');"

    • Use onMouseUp with onKeyUp: The onMouseUp event handler is invoked when the user releases a mouse button on an object that supports this event (e.g., button, document, link). The onKeyUp event handler is invoked when a keyboard key is released from its depressed position. As with the onMouseDown and onKeyDown events, assistive technologies will not read any changes to the textbox because it does not recognize when an object is changed dynamically using JavaScript. See Figure 2.25.5-11 for an example of the onMouseUp with onKeyUp multiple input options event handlers.

    Figure 2.25.5-11

    Example of onMouseUp with OnKeyUp Multiple Input Option

    Annual Salary: <input type="text" name="Salary" size="7" value=" $40,000"  
       
    onmouseup="window.alert('The value has been reset to $40,000.')';Salary.value='$40,000'" >  
       
    onkeyup="window.alert('The value has been reset to $40,000.')';Salary.value='$40,000' " >  

    • Use onClick instead of onKeyPress: The onClick event handler is invoked when a button object (regular, radio, reset and submit) or a link is clicked, a checkbox is checked, or an image map area is selected. Except in the case of a button or an image map area, the onClick event handler can return "false" to cancel the action. The onKeyPress event handler is invoked only when a user presses or holds down a key. The onClick event handler will execute correctly when the user clicks on the object using a mouse or presses the Enter key when the focus is on the object. See Figure 2.25.5-12 for an example of the onClick instead of onKeyPress event handlers.

    Note:

    With Microsoft Internet Explorer, the onClick event handler does not work with reset buttons.

    Figure 2.25.5-12

    Example of onClick instead of onKeyPress Multiple Input Option

    <script language="javascript " >  
    <!--    
    function compute() {  
      //Compute the montly salary and display it to  
      //      the user in an alert box.  
         
      window.alert('The montly salary is ' +  
              Math.round(JSForm.Salary.value / 12) + '.');  
    }    
    //-->    
    </script>    
         
    <form name="JSForm" id="JSForm" >  
    Annual Salary:  
    <input type="text" id="Salary" name="Salary" size=" 7" value="40000" ><br>  
         
    <input type="button" id="Compute" name="Compute"  
    value="Compute Monthly Pay "  
    onclick="compute();" ><br>  
    </form>    

  20. Ensuring Compliance: The accessibility scenarios to be considered when developing JavaScript solutions fall into three categories. The first category includes users who are mobility-impaired and use a recent version of a standard browser (Internet Explorer 5+, Netscape 4+). The second category includes users who are visually impaired and use a recent screen-reader (JAWS 4+) with a recent standard browser. The third category includes users who use an older browser or an assistive technology, text-only browser such as Lynx, or who have JavaScript turned off on their browsers.

  21. Scripts are generally not supported for users in the third scenario; any functionality provided by scripting will be inaccessible to these users and an alternative non-scripted solution should be offered. Although Section 508's scripting provision focuses on visually disabled users, the reality of making scripting accessible to most users encompasses all of these scenarios. At a minimum, the full content and functionality of web sites needs to be available to the users who are using standard browsers that are described in the first two categories of the accessibility scenarios in paragraph (20) of this section.

  22. If client-side scripting must be used it should be:

    • Evaluated carefully before development. The user should ask, what will this script accomplish? Why is it necessary? Is there a way to achieve the same functionality or effect without using scripting?

    • Developed to operate with both keyboard and mouse input.

    • Tested on multiple platforms, browsers, and assistive technologies to ensure maximum user access. In particular, scripts should be tested with keyboard-only and voice input.

    • Coupled with a non-scripted solution (even if less elegant, efficient, or user-friendly) wherever possible, for those users who will not be able to access the scripted version. However, links which use a JavaScript function as the URL will correctly run even when JavaScript has been disabled. For example, <a href="javascript:NextPageLink(); " >Next Page</a>.

  23. The following guidelines provided in paragraphs (24) through (26) may be used to check that accessibility efforts with JavaScript have been successful.

  24. Test the web pages without the mouse, using only keyboard or voice input.

    • Keyboard input: Use the tab key to navigate through links and form fields (shift-tab to navigate backwards).

    • Voice input: IBM's ViaVoice is available as a free 30-day trial edition for Macintosh, Microsoft Windows, and Linux. The full version costs less than $100. ViaVoice is a popular program among those who cannot use the keyboard, including a large and growing number of people with repetitive-stress injuries.

  25. Test everything in the web page with scripting turned off. Scripting can be turned off in any browser.

  26. Test the site using common browser/assistive technology combinations. Common browser/assistive technology combinations include:

    • Internet Explorer 4+ and JAWS 3+ for Internet.

    • Internet Explorer 5+ and JAWS 4+ for Intranet.

  27. Assistive technology devices, such as the screen reader JAWS, can optionally be used to determine the accessibility of the scripts.

2.25.5.4.5.12  (11-01-2003)
Applets and Plug-ins, Technical Requirement (m)

  1. Technical Requirement (m). When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with Section 508 accessibility requirements (§1194.21(a) through (l)). The plug-in must meet these software requirements, which are a separate set from the web requirements, and further, the content must be coded at a minimum to allow the plug-in to provide equivalent functionality to the technical requirements listed.

  2. Providing a link to an "accessible" plug-in does not ensure accessibility. Each document or function that is enabled through a plug-in must be tested for accessibility. Plug-ins shall not be required unless absolutely necessary.

  3. The content to be displayed via the plug-in must be coded from vendor specifications for accessibility to provide equivalent functionality to the following technical requirements in this IRM.

    • For Technical Requirement (a): A text equivalent for every non-text element shall be provided.

    • For Technical Requirement (b): Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

    • For Technical Requirement (c): Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

    • For Technical Requirement (g): Row and column headers shall be identified for data tables.

    • For Technical Requirement (h): Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

    • For Technical Requirement (j): Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz (cycles).

    • For Technical Requirement (n): When electronic forms are designed to be completed on-line, the form shall 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.

    • For Technical Requirement (p): When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

  4. Detecting plug-ins and applets: Plug-ins can usually be detected by examining a page's HTML for the presence of an <object> tag. Some plug-in manufacturers, however, may require the use of proprietary tags. Like plug-ins, applets can also be identified by the presence of an <object> tag in the HTML source for a web page. Also, an <applet> tag may also signal the inclusion of an applet in a web page.

  5. Ensuring Compliance: Compliance with this requirement can be verified by completing the following:

    1. Assistive technology is required to test for this requirement. Ensure there is a link to the plug-in provider next to the link to the document on the web.

    2. OR provide a single accessibility page with all the plug-ins listed and make that link available somewhere on every page that links to a document that needs a plug-in.

    3. AND the document or function must be tested with assistive technology and browser enabled with the plug-in. Proper accessibility structure tags shall be used as recommended by the vendor.

2.25.5.4.5.13  (11-01-2003)
On-Line Forms, Technical Requirement (n)

  1. Technical Requirement (n). When electronic forms are designed to be completed on-line, the form shall 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. Input field selection must follow logically through the form when using the Tab key. This is established through sequential numbering of the tabindex attribute which is used in creating form tags.

  2. The two general ways to use correct form tags is by using implicit labels and explicit labels. However, IRS web developers shall not use " Implicit Labels" when creating web forms.

  3. Explicit Labels: Explicit labels shall be used in all but the very simplest of tables for creating form tags.

    1. The "Title" attribute shall be used instead of the <label> tag in the associated form element when coding new pages.

    2. Do not use both the "Title" attribute and the <label> tag.

    3. The <label> tag is acceptable when dealing with legacy code if the code is known to be accessible. Legacy code may use the <label> tag and associated "FOR" attribute to tag labels. Identify the exact words that are to be used as the label for the form element and enclose those words in a <label> tag. Use the "FOR" attribute to uniquely identify that element.

    4. Use the "ID" attribute in the associated form element. Every form element supports the "ID" attribute. By setting this attribute to the identifier used in the "FOR" attribute of the associated <label>, "tie" that form element to its associated label. For instance, the HTML code has been rewritten for the simple form-inside-a-table to include explicit labels, as shown in Figure 2.25.5-13.

    Figure 2.25.5-13

    Preferred Form Code

    <form>  
    <<!-PREFERRED METHOD: input type TEXT→  
    Text Input type <input type="text" name="Input_Box" size="20
    " tabindex="1" title="Enter text here" ></p>     		 
    <<!-PREFERRED METHOD: input type TEXTAREA→  
    <p>TextArea Input Type  
    <textarea rows="2" name="TA cols " ="20" title="enter text here." tabindex="2" ></textarea></p>  
    <<!-PREFERRED METHOD: input type CHECKBOX→  
    <p>Input type check box  
    <input type="checkbox" name=" CB" value="CB" title="first check box" tabindex="4" >  
    Check 2 <input type="checkbox" name=" CB2" title="second check box" value=" CB2" tabindex="5" >  
    Check 3 <input type="checkbox" name=" CB3" value="CB3" title="third check box" tabindex="6" ></p>  
    <<!-PREFERRED METHOD: input type RADIO→  
    <p>Input type radio  
    <input type="radio" value="r1 " checked name="R1"
    title="select radio button" tabindex="7" >     		 
    Radio 2 <input type="radio" title=" second radio button"
    name="R1" value=" r2" tabindex="8" >     		 
    Radio 3 <input type="radio" title=" third radio button"
    name="R1" value=" r3" tabindex="9" ></p>     		 
    <<!-PREFERRED METHOD: input type SELECT→  
    <p>Input Type Select  
    <select size="1" name="Choices " title="drop down box" tabindex=" 10" >  
    <option>choice 1</option>  
    <option>choice 2</option>  
    <option>choice 3</option>  
    </select> </p>  
    <<!-PREFERRED METHOD: input type BUTTON→  
    <p>Input Type Button  
    <input type="button" value="yourvalue " title="Perform Action"
    name=" B3" tabindex="11" ></p>     		 
    <<!-PREFERRED METHOD: input type SUBMIT→  
    <p><input type="submit" value=" Submit" name="B1" tabindex="12" ></p>  
    </form>  
    <!-ACCEPTABLE LEGACY CODE→  
    <table>  
    <tr>  
    <TD><B><LABEL FOR="first" > FIRST NAME:</LABEL> </B></TD>  
    <TD><INPUT TYPE="TEXT" TITLE=" FIRSTNAME"
    NAME="FIRSTNAME" tabindex=" 3" ></TD>     		 
    </TR>  
    <TR>  
    <TD><B><LABEL FOR="last" > LAST NAME:</LABEL> </B></TD>  
    <TD><INPUT TYPE="TEXT" TITLE=" LAST NAME"
    NAME="LASTNAME" tabindex=4></TD>     		 
    </TR>  
    </table>  
    </FORM>  

  4. Ensuring Compliance: Compliance with Technical Requirement (n) should be tested with a screen reader. Assistive technology devices, such as the screen reader JAWS, can optionally be used to determine the accessibility of each form field. The first rule is to place labels adjacent to input fields, not in separate cells of a table. For the web developer who does not wish to place form elements immediately adjacent to their corresponding titles, the HTML 4.0 specification includes the <label> tag that lets web developers mark specific elements as "labels" and then associate a form element with that label.

2.25.5.4.5.14  (11-01-2003)
Skip Repetitive Navigation, Technical Requirement (o)

  1. Technical Requirement (o). A method shall be provided that permits users to skip repetitive navigation links. This method is called SkipNav.

  2. Navigational links are usually placed at a standard location on every menu page--often across the top, bottom, or side of a page. This forces a visually impaired user to listen to every link on every page before reaching the main content. In order to alleviate this problem, this IRM requires SkipNav.

  3. Providing for SkipNav: The phrase " skip to main content" shall be used in SkipNav links. The target will be in the HTML of the main content. The SkipNav link shall be the first link encountered in the browser window when using the Tab key. Use tabindex=1 in the link to correctly format the SkipNav function. If left or right navigation menus are used, SkipNav is also required. A SkipNav link must also be the first element encountered in side navigation bars. A spacer gif or a blank gif can be used in either a header or sidebar navigation for this purpose. The gif will have an alt attribute of "skip to main content. " Content developers may also use hyperlink text that says, " skip to main content." In this case, the text will be colored so that it is transparent to sighted users.

  4. Tabbing Order: An example of a tabbing order format is tabindex1 = skipnav. Tabindex2 = Text-only (if implemented). Tabbing then hits the links in the top navigation bar. If there is left-side navigation, that comes after the top bar. The first link (tab) in the left navigation bar is SkipNav.

  5. Ensuring Compliance: Using only the Tab, Arrow, and Enter keys, navigate through the web site. Press enter when SkipNav is selected and ensure the arrow key now controls the content window. Attempt to jump to main content from all navigation bars. Technical Requirement (o) requires no assistive technology for compliance testing, although screen readers should be used to test if transparent gifs or gifs with the same background color are used, making them invisible except to the screen reader.

2.25.5.4.5.15  (11-01-2003)
Timed Responses, Technical Requirement (p)

  1. Technical Requirement (p). When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. Figure 2.25.5-14 provides a sample JavaScript when a timed response is required.

  2. A user’s disability can have a direct impact on the speed with which he or she can read, move around, or fill in a web form. Many forms, when they "time out" automatically, also delete whatever data has been entered. The result is that a user with a disability who is slow to enter data cannot complete the form.

  3. A timeout provision is not needed for pages that do not use session state, or will retain the contents and function of any form until the submit button is clicked.

  4. Ensuring Compliance:There is no assistive technology required for compliance testing for Technical Requirement (p).

    Figure 2.25.5-14

    Sample JavaScript for a Required Timed Response

    <script language="javascript" >  
    <!--  
    /*========================  
    SessionTimer()  
    PURPOSE: This acts as a counter and times the session, alerts the user
    when the designated minutes remains in the session. */     		 
       
    // Don't touch these two below  
    var GlobalTimer = '';  
    var GTCount = 0;  
       
    /* Set the three variables below to be specific to your application */  
    var WarnAt = 1; //The time in minutes to display the warning with no activity  
    var SessionTimeOut = 2; //The actual session timeout time in minutes  
    var appName = 'Example'; //The name of the application for display purposes  
       
    // This line activates the time  
    GlobalTimer = setInterval('SessionTimer()',60000);  
       
    function SessionTimer() {  
    var TheDate = new Date();  
       
    var AText = '';  
    AText += 'WARNING!\//nYour session in the '+appName+' has been
    INACTIVE for '+WarnAt+' minutes.\//n\//n';     		 
    AText += ''+appName+' Sessions will expire after
    '+SessionTimeOut+' minutes of inactivity.\//n';     		 
    AText += 'If you do not perform any action within
    '+SessionTimeOut+' minutes, your session will expire.\//n';     		 
    AText += 'Once your session expires, DO NOT
    attempt any further activity. Return to the HOME page\//n';     		 
    AText += 'to reset your session, then continue with your current process.\//n\//n';  
    AText += 'This alert generated: ' + TheDate.toString();  
    GTCount++;  
    if (GTCount == WarnAt) {  
    alert(AText);  
    }  
    if (GTCount > SessionTimeOut) {  
    alert('Your session in the '+appName+' has expired.\//n\//nWhen you click \//'OK\//',
    you will be returned to the HOME PAGE to reset your session.');     		 
    clearInterval(GlobalTimer);  
    document.location = '/';  
    }  
    }  
    //-->  
    </script>  

2.25.5.4.5.16  (11-01-2003)
Non-HTML Content

  1. IRS Technical Requirement (q). When a specific document format such as Microsoft Word, Excel, PowerPoint, PDF and others are posted to a web site, the document must be accessible in its native format. If the native-format document cannot be made accessible, the document must be converted to HTML and the HTML modified so that it is accessible. Documents that cannot be converted to HTML, such as image formats, must have an accessible alternative that complies with all technical requirements in this IRM.

  2. For all documents in specific formats:

    1. Special document accessibility instructions may be available from vendors, and other accessibility organizations.

    2. Columns shall be titled with text that facilitates column identification and navigation, and provides specific column separation.

    3. Information arranged in columns and rows may not be aligned using the Tab key or by using spaces. Whenever possible, a table function must be used.

    4. Technical Requirements (a) through (q) above should be met by some equivalent facility. If a particular format is used because it is the only format to accomplish a specific function, then providing an alternate format may not be required, since it would also not be able to perform the same functionality. This is best illustrated by Excel timesheets, where calculation is the key functionality.

    5. Meaningful images and graphics must be described in text. This can be through alt tags or through descriptive text that is part of the body of the document. Meaningful graphics are those that convey content or information such as an organization chart.

    6. Refer to http://508.web.irs.gov, http://amc.enterprise.irs.gov, and http://irap.no.irs.gov for new instructional materials for creating accessible content. These three IRS sites all publish new materials about this subject.

  3. For Microsoft Word Format:

    1. Requirements from (2) above apply.

    2. Images must have alt tags.

    3. Charts or graphs must be accompanied by a text description of their contents.

    4. Tables will be labeled with column and row information that describes the table’s contents.

    5. Instructions are available at: http://wiscinfo.doit.wisc.edu/ltde/ORFI/ces/webpages.htm and at http://www.acb.org/accessible-formats.html.

  4. For Microsoft Excel Format:

    1. Requirements from (2) above apply.

    2. HTML equivalents are required if the Excel spreadsheet has no calculations in it. If calculations are being performed, such as with timesheets, Excel spreadsheets are allowable as is, since the functionality would be broken otherwise.

    3. HTML files from Excel documents must be edited to include header and <scope=> statements where needed to ensure accessibility.

  5. Microsoft PowerPoint Format:

    1. Requirements from (2) above apply.

    2. PowerPoint shows that no meaningful graphics or images are accessible in their native format. Meaningful graphics are those that convey content or information.

    3. PowerPoint presentations that include meaningful graphics or images must be converted to HTML. The HTML must then be edited so that images or graphics contain meaningful alt text.

  6. Adobe Acrobat PDF Documents:

    1. Document creators shall use procedures found at the http://access.adobe.com site.

    2. PDF documents that are not properly structured according to Adobe’s Access web site shall not be placed on an IRS web site.

  7. Macromedia Flash:

    1. Flying or scrolling text should be avoided.

    2. Users with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with motor disabilities might not be able to move quickly or accurately enough to interact with moving objects.

    3. Flash creators should use instructions available at http://www.macromedia.com/macromedia/accessibility/policy.html. Flash creators cannot deploy Flash until the IRS Common Operating Environment (COE) includes Macromedia Flash Player 6.

    4. The only acceptable format for Macromedia Flash presentations is FlashMX or its successor format.

    5. Flash may not be used on any intranet web site until the Macromedia Flash 6.0 reader is distributed through the COE to IRS workstations.

2.25.5.5  (11-01-2003)
Exhibits

  1. Exhibit 2.25.5-1 provides the statue for Section 508, Exhibit 2.25.5-2 provides accessibility coding examples in this IRM, and Exhibit 2.25.5-3 provides an alphabetic listing of the terms and definitions used in the Section 508 standard.

Exhibit 2.25.5-1  (11-01-2003)
Section 508. Electronic and Information Technology

    PL 105-220, 1998 HR 1385  
    PL 105-220, enacted on August 7, 1998, 112 Stat 936  
    codified as: Section 504 of the Rehabilitation Act, 29 U.S.C. § 794d  
           
    WORKFORCE INVESTMENT ACT OF 1998  
           
SEC. 508. ELECTRONIC AND INFORMATION TECHNOLOGY.  
(a) REQUIREMENTS FOR FEDERAL DEPARTMENTS AND AGENCIES.--  
  (1) ACCESSIBILITY.--  
    (A) DEVELOPMENT, PROCUREMENT, MAINTENANCE, OR USE OF ELECTRONIC AND INFORMATION TECHNOLOGY.--When developing, procuring, maintaining, or using electronic and information technology, each Federal department or agency, including the United States Postal Service, shall ensure, unless an undue burden would be imposed on the department or agency, that the electronic and information technology allows, regardless of the type of medium of the technology--  
      (i) individuals with disabilities who are Federal employees to have access to and use of information and data that is comparable to the access to and use of the information and data by Federal employees who are not individuals with disabilities; and  
      (ii) individuals with disabilities who are members of the public seeking information or services from a Federal department or agency to have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities.  
    (B) ALTERNATIVE MEANS EFFORTS. --When development, procurement, maintenance, or use of electronic and information technology that meets the standards published by the Access Board under paragraph (2) would impose an undue burden, the Federal department or agency shall provide individuals with disabilities covered by paragraph (1) with the information and data involved by an alternative means of access that allows the individual to use the information and data.  
  (2) ELECTRONIC AND INFORMATION TECHNOLOGY STANDARDS.—  
    (A) IN GENERAL.--Not later than 18 months after the date of enactment of the Rehabilitation Act Amendments of 1998, the Architectural and Transportation Barriers Compliance Board (referred to in this section as the 'Access Board'), after consultation with the Secretary of Education, the Administrator of General Services, the Secretary of Commerce, the Chairman of the Federal Communications Commission, the Secretary of Defense, and the head of any other Federal department or agency that the Access Board determines to be appropriate, including consultation on relevant research findings, and after consultation with the electronic and information technology industry and appropriate public or nonprofit agencies or organizations, including organizations representing individuals with disabilities, shall issue and publish standards setting forth--  
      (i) for purposes of this section, a definition of electronic and information technology that is consistent with the definition of information technology specified in section 5002(3) of the Clinger-Cohen Act of 1996 (40 U.S.C. 1401(3)); and  
      (ii) the technical and functional performance criteria necessary to implement the requirements set forth in paragraph (1).  
    (B) REVIEW AND AMENDMENT. --The Access Board shall periodically review and, as appropriate, amend the standards required under subparagraph (A) to reflect technological advances or changes in electronic and information technology.  
  (3) INCORPORATION OF STANDARDS. --Not later than 6 months after the Access Board publishes the standards required under paragraph (2), the Federal Acquisition Regulatory Council shall revise the Federal Acquisition Regulation and each Federal department or agency shall revise the Federal procurement policies and directives under the control of the department or agency to incorporate those standards. Not later than 6 months after the Access Board revises any standards required under paragraph (2), the Council shall revise the Federal Acquisition Regulation and each appropriate Federal department or agency shall revise the procurement policies and directives, as necessary, to incorporate the revisions.  
  (4) ACQUISITION PLANNING. --In the event that a Federal department or agency determines that compliance with the standards issued by the Access Board under paragraph (2) relating to procurement imposes an undue burden, the documentation by the department or agency supporting the procurement shall explain why compliance creates an undue burden.  
  (5) EXEMPTION FOR NATIONAL SECURITY SYSTEMS.--This section shall not apply to national security systems, as that term is defined in section 5142 of the Clinger-Cohen Act of 1996 (40 U.S.C. 1452).  
  (6) CONSTRUCTION.—  
    (A) EQUIPMENT.--In a case in which the Federal Government provides access to the public to information or data through electronic and information technology, nothing in this section shall be construed to require a Federal department or agency--  
      (i) to make equipment owned by the Federal Government available for access and use by individuals with disabilities covered by paragraph (1) at a location other than that where the electronic and information technology is provided to the public; or  
      (ii) to purchase equipment for access and use by individuals with disabilities covered by paragraph (1) at a location other than that where the electronic and information technology is provided to the public.  
    (B) SOFTWARE AND PERIPHERAL DEVICES.--Except as required to comply with standards issued by the Access Board under paragraph (2), nothing in paragraph (1) requires the installation of specific accessibility-related software or the attachment of a specific accessibility-related peripheral device at a workstation of a Federal employee who is not an individual with a disability.  
(b) TECHNICAL ASSISTANCE. --The Administrator of General Services and the Access Board shall provide technical assistance to individuals and Federal departments and agencies concerning the requirements of this section.  
(c) AGENCY EVALUATIONS. --Not later than 6 months after the date of enactment of the Rehabilitation Act Amendments of 1998, the head of each Federal department or agency shall evaluate the extent to which the electronic and information technology of the department or agency is accessible to and usable by individuals with disabilities described in subsection (a)(1), compared to the access to and use of the technology by individuals described in such subsection who are not individuals with disabilities, and submit a report containing the evaluation to the Attorney General.  
(d) REPORTS.--  
  (1) INTERIM REPORT.--Not later than 18 months after the date of enactment of the Rehabilitation Act Amendments of 1998, the Attorney General shall prepare and submit to the President a report containing information on and recommendations regarding the extent to which the electronic and information technology of the Federal Government is accessible to and usable by individuals with disabilities described in subsection (a)(1).  
  (2) BIENNIAL REPORTS.--Not later than 3 years after the date of enactment of the Rehabilitation Act Amendments of 1998, and every 2 years thereafter, the Attorney General shall prepare and submit to the President and Congress a report containing information on and recommendations regarding the state of Federal department and agency compliance with the requirements of this section, including actions regarding individual complaints under subsection (f).  
(e) COOPERATION.--Each head of a Federal department or agency (including the Access Board, the Equal Employment Opportunity Commission, and the General Services Administration) shall provide to the Attorney General such information as the Attorney General determines is necessary to conduct the evaluations under subsection (c) and prepare the reports under subsection (d).  
(f) ENFORCEMENT.--  
  (1) GENERAL.--  
    (A) COMPLAINTS.--Effective 2 years after the date of enactment of the Rehabilitation Act Amendments of 1998, any individual with a disability may file a complaint alleging that a Federal department or agency fails to comply with subsection (a)(1) in providing electronic and information technology.  
    (B) APPLICATION.--This subsection shall apply only to electronic and information technology that is procured by a Federal department or agency not less than 2 years after the date of enactment of the Rehabilitation Act Amendments of 1998.  
  (2) ADMINISTRATIVE COMPLAINTS. --Complaints filed under paragraph (1) shall be filed with the Federal department or agency alleged to be in noncompliance. The Federal department or agency receiving the complaint shall apply the complaint procedures established to implement section 504 for resolving allegations of discrimination in a federally conducted program or activity.  
  (3) CIVIL ACTIONS.--The remedies, procedures, and rights set forth in sections 505(a)(2) and 505(b) shall be the remedies, procedures, and rights available to any individual with a disability filing a complaint under paragraph (1).  
    (g) APPLICATION TO OTHER FEDERAL LAWS.--This section shall not be construed to limit any right, remedy, or procedure otherwise available under any provision of Federal law (including sections 501 through 505) that provides greater or equal protection for the rights of individuals with disabilities than this section.  

Exhibit 2.25.5-2  (11-01-2003)
Accessibility Coding Examples

Exhibit 2.25.5-2 provides examples of accessibility coding presented in this IRM.

Assigning Text to Elements:There are several methods of providing textual information so that it can be recognized by assistive technology devices. For instance, the <img> tag can accept an " alt" attribute that can include text to describe the picture. This example can be found in Section 2.25.5.4.5.1, paragraph 4.
Example: <img src="logo.gif" alt="IRS Logo" >. 		 
Non-Text Descriptions for Images:Images that do not convey content or aid in navigation need null alt tags. For example, transparent gifs are often used for spacing. Adding a text description to these elements will produce unnecessary clutter for users of assistive technology. For such graphics, an empty alt attribute is required. This example can be found in Section 2.25.5.4.5.1, paragraph 5. Example: <img src=" transparent.gif" alt="" >.  
Text Descriptions for Images: If an <a> tag surrounds both text and an image, use alt="" on the image, as the text in the link should explain the purpose of the link, not the alt. There is no reason to duplicate the text. This example can be found in Section 2.25.5.4.5.1, paragraph 6. Example: <a href="info.html" ><img src="info.gif" alt="  " > More Information </a>.  
Avoiding alt Tags: If a textual description of the image is embedded in the context of the page, an alt tag may not be necessary. This example can be found in Section 2.25.4.4.5.1, paragraph 8. Example: ‘Here is a sample picture of our library.’ <imgsrc="pictureoflibrary.jpg " >.  
Alternative Text for Applets:An alternative text is required between opening and closing <applet> or <object> tags. This example can be found in Section 2.25.5.4.5.1, paragraph 9. Example: <APPLET CODE="MyCoolApplet.class" WIDTH="200" , HEIGHT="100" > This applet displays current stock prices </APPLET>.  
Testing for Color:Insert the text between brackets below in the address of the page to be tested in Internet Explorer (IE). This example can be found in Section 2.25.5.4.5.3, paragraph 3. Example: [javascript:document.body.style.filter='gray()';void(null) ].  
External Style Sheets: The IRS requires "external" style sheets, in which the style rules are set up in a separate file. This example can be found in Section 2.25.5.4.5.4, paragraph 3. Example: <link rel=stylesheet type="text / css" href="section508.css" >.  
Turning off the Style Sheets: To turn off the style sheet control set up a link called "Kill Style Sheet" under "Favorites" in IE that contains the URL: "javascript:for(i=0;i<document.styleSheets.length;i++)document.styleSheets[i].cssText= " ;void(null). This will display the web page or application without the style sheets. This example can be found in Section 2.25.5.4.5.4, paragraph 4.  
Invoking JavaScript Functions:JavaScript URLs are one way to invoke JavaScript functions, and will work even if JavaScript is turned off. Typically, this technique is used as part of <a> anchor links. This example can be found in Section 2.25.5.4.5.11, paragraph 7. Example: The following link invokes a JavaScript function called myFunction: <a href="javascript:myFunction();" >Start myFunction</a>.  
Meaningful alt Tags in JavaScript Functions: When an image is used in place of text inside a JavaScript URL, the image shall have a meaningful alt tag. Developers shall not use the title tag in place of the alt tag in this case. The following link invokes the JavaScript function myFunction, but requires the user to click on an image instead of the text "Start my function." The alt tag makes the link accessible. This example can be found in Section 2.25.5.4.5.11, paragraphs 8 and 9. Example: <a href="javascript:myFunction();" ><img src="myFunction.gif" alt="myFunction" ></a>.  
Non-Scripted Solution: For those users who will not be able to access the scripted version use a JavaScript function, as the URL will correctly run even when JavaScript has been disabled. This example can be found in Section 2.25.5.4.5.11, paragraph 22. Example: <a href="javascript:NextPageLink();" > Next Page</a>.  

Exhibit 2.25.5-3  (11-01-2003)
Terms and Definitions

Exhibit 2.25.5-3 provides an alphabetic listing of the terms and defintions used in the Section 508 standard.

Access Board: An independent Federal agency, known as the Architectural and Transportation Barriers Compliance Board, whose primary mission is to promote accessibility for individuals with disabilities.  
Access Board Standards: Also known as "EIT Accessibility Standards" , this regulation at 36 CFR Part 1194 sets forth technical provisions to:  
  1) Address the required functionality/performance of specific technologies and product categories  
  2) Identify broader functional performance criteria to cover technologies or components for which there is no specific provision (either because the technology or product does not yet exist or was not contemplated by the Access Board when the standards were promulgated)  
  3) Include requirements for accessible information, documentation, and support for EIT. Section 508 Technical Standards lists the technical standards contained in Subpart B of the regulation.  
Agency: Any Federal department or agency, including the United States Postal Service.  
Alternate Formats: Alternate formats usable by people with disabilities may include, but are not limited to, Braille, ASCII text, large print, recorded audio, and electronic formats that comply with this part.  
Alternate Methods: Different means of providing information, including product documentation, to people with disabilities. Alternate methods may include, but are not limited to, voice, fax, relay service, TTY, Internet posting, captioning, text-to-speech synthesis, and audio description.  
Assistive Technology: Any item, piece of equipment, or system, whether acquired commercially, modified, or customized, that is commonly used to increase, maintain, or improve functional capabilities of individuals with disabilities.  
Electronic and Information Technology (EIT): Includes information technology and any equipment or interconnected system or subsystem of equipment that is used in the creation, conversion, or duplication of data or information. The term electronic and information technology includes, but is not limited to, telecommunications products (such as telephones), information kiosks and transaction machines, World Wide Web sites, multimedia, and office equipment such as copiers and fax machines. The term does not include any equipment that contains embedded information technology that is used as an integral part of the product, but the principal function of which is not the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. For example, HVAC (heating, ventilation, and air conditioning) equipment such as thermostats or temperature control devices, and medical equipment where information technology is integral to its operation, are not information technology.  
Equivalent Facilitation: Allows the use of designs or technologies as alternatives to those prescribed in the technical standards provided that they result in substantially equivalent or greater access to and use of a product for people with disabilities. This provision recognizes that future technologies may be developed, or existing technologies could be used in a particular way, that could provide the same functional access in ways not envisioned by the technical standards.  
Information Technology: Any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. The term information technology does not include any equipment that:  
  1) Is acquired by a contractor incidental to a contract  
  2) Contains imbedded information technology that is used as an integral part of the product, but the principal function of which is not the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information.  
Non-Text Element:An image, graphic, audio clip, or other feature that conveys meaning through a picture or sound. The following are possible examples of non-text elements: Buttons (when button text is an image), photographs, line art, charts, graphs, image maps, animated gifs, ASCII art such as ;-), audio files, video files, maps, math equations, images used as bullets, scripts, streaming media and so forth. HTML bullets <ul> are NOT considered a non-text element.  
Non-Developmental Item:  
  1) Any previously developed item of supply used exclusively for governmental purposes by a Federal agency, a State or local government, or a foreign government with which the United States has a mutual defense cooperation agreement  
  2) Any item described in paragraph (1) of this definition that requires only minor modification or modifications of a type customarily available in the commercial marketplace in order to meet the requirements of the procuring department or agency  
  3) Any item of supply being produced that does not meet the requirements of paragraphs (1) or (2) solely because the item is not yet in use.  
Operable Controls:A component of a product that requires physical contact for normal operation. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, or keypads. Products consist of electronic and information technology and self contained, closed products. Some products generally have embedded software and are commonly designed in such a fashion that a user cannot easily attach or install assistive technology. These products include, but are not limited to, information kiosks and information transaction machines, copiers, printers, calculators, fax machines, and other similar types of products.  
Telecommunications: The transmission, between or among points specified by the user, of information of the user's choosing, without change in the form or content of the information as sent and received.  
TTY: An abbreviation for teletypewriter. Machinery or equipment that employs interactive text based communications through the transmission of coded signals across the telephone network. TTYs may include, for example, devices known as TDDs (telecommunication display devices or telecommunication devices for people who are deaf or hard of hearing) or computers with special modems. TTYs are also called text telephones.  
Undue Burden: Undue burden means significant difficulty or expense. In determining whether an action would result in an undue burden, an agency shall consider all agency resources available to the program or component for which the product is being developed, procured, maintained, or used.  

More Internal Revenue Manual