Appendix 2-C. Creating Accessible Files and Technologies

Complying With Section 508

On June 21, 2001, a law went into effect to ensure individuals with disabilities have access to electronic and information technology provided by the Federal Government. Section 508 of the Rehabilitation Act of 1973, as amended, requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, they ensure that it is accessible to individuals with disabilities, unless an undue burden would be imposed on the agency. The bar for an "undue burden" is high: If the agency can demonstrate undue burden for particular circumstances and receive an approval for exception from the Department of Health and Human Services (HHS), the information would still need to be provided to individuals with disabilities in an alternate format upon request.

Agency-sponsored Web sites and resources operated either directly or by grant or contract must comply with this law and its implementing regulations and ensure accessibility for users protected by the Americans with Disabilities Act and other applicable Federal laws. The U.S. Access Board (http://www.access-board.gov/508.htm), an independent Federal agency, develops technical standards for Web products.

HHS employees must ensure that all electronic information and technology comply with the accessibility requirements, including new or revised information made available on the Internet and Intranets. Electronic and information technology includes software applications and operating systems, Web resources and applications, telecommunication products, video and multimedia products, self-contained and closed products (such as information kiosks), and desktop and portable computers.

Ensuring access is not optional. AHRQ and HHS take accessibility very seriously. In addition to doing the right thing by ensuring access to Government information for all Americans, AHRQ must comply with Section 508 because it is a legal requirement.

Return to Section Contents

Accessibility Guidance

Specific guidance is available from the sources cited below and:

• Technical guidance by the Section 508 Access Board:
  http://www.access-board.gov/sec508/guide/1194.22.htm
• HHS 508 Web standards and guidance:
  http://www.hhs.gov/web/508/
• AHRQ Alternate 508 Coordinator:
  Biff LeVee, 301-427-1897, biff.levee@ahrq.hhs.gov

Return to Section Contents

Accessibility Requirements

Keep the following accessibility requirements in mind:

Vision impairments

Content must be readable by screen readers (which read text aloud) or Braille readers. That is ensured by following the standards for Section 508. For people with low vision or color blindness, contrast must be sufficient. Ensure that any information conveyed with color is conveyed equally well when color is not available. Asterisks or some other textual cues can be used in addition to the color to convey information.

Mobility impairments

Links and hot spots should be large enough so someone with limited fine muscle control can click the link.

Hearing impairments

Synchronized captioning or transcripts for multimedia files should be provided. For example, if multimedia objects with sound are embedded in PDF documents, both the deaf and the deaf-blind are excluded if there is no transcript. In addition, synchronized captions for video must be supplied because people who are deaf need synchronized captions if the video does not make sense when the sound is turned off.

Return to Section Contents

Web Development Features

Accessibility needs to be built into the development process for any new or updated Web-based resource. Basic features to be addressed include:

• Providing text equivalents for images, sound, and multimedia features, such as alternate descriptive text for images for the blind and captions for audio-video files for the deaf. All streaming media must have written transcripts or captioning.
• Ensuring that information provided does not depend on color for sense without alternate text and color contrast enhances readability for the sighted and does not create barriers for the color-blind.
• Coding so that tables, content or interface elements provided by scripts, and image maps may be read with assistive technology, such as screen readers.
• Controlling the screen flicker rate, as well as the use of blinking or flashing features.
• Using text-only pages as alternatives if needed for accessibility, while maintaining these pages on the same schedule as primary pages.
• Linking to applets, plug-ins, or other applications that must be downloaded.
• Creating accessible forms for business processes on the Web.
• Allowing users to avoid repetitive navigation links and to request additional time on pages requiring timed responses.

If fully accessible, HTML documents are the gold standard for users with disabilities because assistive technologies make the information accessible across platforms and without proprietary technologies. Offering files that are not accessible means that they do not comply with Section 508 and therefore leave AHRQ open to legal action. A copy of the AHRQ Accessibility Notice posted on the Web site appears as Appendix 2-D.

Return to Section Contents

Alternate Text for Accessibility

For images such as figures and charts, alternate text must be used so disabled users can access the information in the image. Every image must have an alternate text tag, even if it is null (alt="") for decorative images. (From the Section 508 standards: http://www.access-board.gov/sec508/guide/1194.22.htm#(a).)

The "alt" tag in HTML code is read aloud by screen readers or Braille readers. To see it, use Internet Explorer and hold the cursor over the image. Alternate text can also be provided as content in the document.

Basic images

For basic images, alternate text is straightforward and should:

• Be accurate and equivalent in presenting the same content and function as presented by the image.
• Be succinct. The correct content (if there is content) and function (if there is a function) of the image should be presented as succinctly as is appropriate.
• Not use the phrases "image of ..." or "graphic of ..." to describe the image.

Complex images

Alternate text is provided for complex images in other ways. The alt tag must still be used, with a longer description elsewhere. Two methods are recommended:

• Provide the full description in the document itself. For example, alternate text can be under the image or refer to a description elsewhere in the document.
• Provide a link to a full description with a normal text link. For example, under the image of this analytic framework, "Select for Text Description" goes to the alternate text: http://www.uspreventiveservicestaskforce.org/uspstf07/chlipid/chliprevfig2.htm.

(Although the "longdesc" attribute can be used, it is not encouraged. Some browsers do not support it, and it cannot be accessed by disabled persons who don't use screen readers.)

Some images are too complex for all of the information to be meaningful as alternate text. In such cases, capture the essence of the image—what it means—without all the detail. For example, giving the 80 data points in a graph might be less informative than describing a trend and what it means. If a graph is meant to present the data, however, the alternate text must reflect that.

The context of the image should determine the content of alternate text. For example, the specific characters in a "screen shot" would not be helpful if the image is only intended to convey what the screen looks like. In that case, describing the interface might be more important.

Return to Section Contents

Creating Accessible Files and Formats

All downloadable files—and Web technologies—either have to be accessible or have accessible alternatives. This appendix addresses:

• Word documents.
• PDF documents.
• PowerPoint® presentations.
• Excel files.
• Flash®.
• Audiocasts, Webcasts, and video.
• Javascript.

Word documents

AHRQ strongly recommends that accessible alternatives, such as Web versions, be created rather than making accessible Word files. HTML is the gold standard for accessibility and works dependably regardless of user platform or software version.

However, making Word files accessible does make it easier to develop accessible PDF documents. To create accessible Word files, use the HHS checklist at: http://www.hhs.gov/web/policies/checklistword.html.

Key points

Many features in Word that make it easier to create or use documents also support accessibility:

• The Styles feature in Word should always be used to for formatting (heading subordination, bullet and number lists, table of contents levels). Styles delineate structure and organization for assistive technologies, such as screen readers.
• Tables of contents, bookmarks, indexes, and hyperlinks all aid navigation.
• The Column feature should always be used when making a multicolumn document so assistive technologies will be able to properly read the document. Never use the Tab key to separate columns.

Other Word¬ accessibility features:

• Alternate text for images permits images to be accessible to disabled persons.
• Tables created with the Word Table feature with row and column headings make tables more accessible. Precede tables with a description.
• Form fields should be labeled.

Styles

The Styles feature in Word makes word processing faster, easier to edit, and more consistent. Styles also greatly increase accessibility because they give a document a hierarchical structure that disabled users need to understand document organization. Use styles to indicate:

• Heading subordination or importance (heading 1, 2, 3, etc.).
• Lists of information (bulleted and numbered lists).
• Table of contents levels.

If the Word document is converted into a PDF file, each assigned style can generate a PDF accessibility tag. Styles also generate PDF bookmarks. Styles can be applied to large documents quickly. Select all elements to be formatted and click on the desired style.

Tables

Tables in Word can pose accessibility challenges, especially complex tables. Use the section on tables in the HHS 508 checklist: http://www.hhs.gov/web/policies/checklistword.html#checklist3.

Forms

Two steps increase a form's accessibility:

• Use concise descriptions next to the objects that have been inserted into the form.
• Add Help Text to each form item.

To add Help Text:

1. Right click on the object that is in the form (i.e. text box, check box, calendar control, etc).
2. Click Properties.
3. Click Add Help Text.
4. Enter text that describes the field's attributes. For example, if it is a drop-down menu in the field provided, enter text that can help the user with navigation: "This is a drop-down menu to select the class you would like. Use the arrow keys to scroll through the list."
5. Click OK twice.

Images and diagrams

Screen and Braille readers will pass over images unless they are accessible. The key to making images accessible lies in using alternate text to identify image content. Alternate text cannot be seen but is read by assistive technologies. More information on alternate text appears later in this appendix.

Typically, diagrams require lengthy descriptions to ensure accessibility because both the appearance and meaning must be communicated. The way to handle this is to provide a text in the caption or the figure's description that explains what the image represents as a whole and then try to step the reader through what the image is trying to convey.

PDF documents

Adobe® PDF (Portable Document Format) documents are widely used because they can be produced quickly while preserving the look and feel of the source document, regardless of the application and the platform used to create them.

If PDF documents are on the Web without accessible equivalents (such as HTML), the PDF documents must be fully accessible. Making PDF documents accessible can be both labor intensive and difficult. Creating an accessible HTML equivalent is usually easier and quicker than making the PDF document fully accessible.

The best way to create accessible PDF documents is to first make the native file (such as Word) accessible. Refer to the previous section for advice on making accessible Word files.

Broad requirements for PDF document accessibility include:

• The PDF document must contain actual text. The PDF document must have characters that can be picked up by screen readers as opposed to scanned pages that contain only images. Actual text is made from word processing or desktop published files.
• The PDF document must have accessibility tags, which are similar to HTML tags. Tagged PDF documents contain information on logical structure about the contents of the file. Examples of accessibility tags include heading subordination and paragraphs. Tagging also should ensure logical reading order.

Word files and accessible PDF documents

The best way to create accessible PDF documents is by first making the files accessible in the authoring application, such as Word. Word accessibility tags are converted to PDF accessibility tags by Adobe® Acrobat® Professional 8 or later.

Well-tagged Word documents are required to make accessible PDF documents. Word 's structural and accessibility features (styles for paragraphs, headings, and lists; alternate text and captions for images; hyperlinks; lists; tables of contents; and accessible forms) will produce special tags when the Word file is converted into PDF. In addition, the resulting PDF document will be automatically bookmarked because of styled headings, aiding navigation.

To create accessible PDF documents, use the HHS checklist at: http://www.hhs.gov/web/policies/checklistpdf.html.

The resulting PDF documents will probably require additional work to be fully accessible. To ensure accessibility of newly created PDF files, refer to the section below on testing PDFs for accessibility.

PDF tags

Tags define the document's structure and reading order, describe graphics, and improve navigation. PDF tags are embedded in the document and are not visually seen. Tags can only be edited with the Tags Palette in the full version of Acrobat®.

Examples of tagging problems include heads not tagged, tags incorrectly subordinated, images without alternate text descriptions, or incorrect tags. Artifacts such as page numbers from the original document should be tagged as artifacts (Tags Palette/Find Artifacts). When tagged, artifacts are invisible to screen readers.

Improperly marked content can create reflow and accessibility problems. If tagged content creates problems for reflow or accessibility, these can be manually corrected by marking content and assigning element types.

PDF tables

Tables require special treatment so that visually disabled users can understand row and column information for each cell. Problems can be minimized when each column has its own head. Table formats in the authoring application should be used, such as table column heading, row heading, and table cell data.

Use the HHS 508 Guidelines for PDF tables at: http://www.hhs.gov/web/policies/checklistpdf.html#checklist3.

Tables pose a special challenge for screen readers because they present textual or numerical data to be easily referenced visually. Content within table cells can be complex and might contain lists, paragraphs, form fields, or another table. The TouchUp Reading Order Table Editor automatically analyzes the selected table into cells and applies the appropriate tags.

The table must be tagged as a table before you can use the Table Editor command. For best results when tagging tables, use the application that you created the document with to add tags before you create the PDF. If a PDF isn't tagged, you can add tags by using the Add Tags To Document command. Most tables are properly recognized using this command; however, the command may not recognize a table that lacks clear borders, headings, columns, and rows. Use the TouchUp Reading Order tool to determine if the table has been properly recognized and to correct recognition problems. To add specialized formatting to tables and table cells, use the Tags tab.

Important:Operations performed in the Tags tab cannot be undone with the Undo command. Save a backup copy of a document before you begin work on it in the Tags tab.

You can use the Table Editor to automatically analyze a table into its components and apply the appropriate tags, but you may still need to check and correct some of these tags manually. By viewing table tags, you can determine whether columns, rows, and cells have been correctly identified. Tables that lack well-defined borders and rules are often tagged incorrectly or contain adjacent page elements. You can correct poorly tagged tables by selecting and redefining them, and you can split combined cells by creating a tag for each cell. To do this:

• Select the TouchUp Reading Order tool, and then click Show Tables and Figures.
• If the table isn't clearly labeled in the document pane, drag to select the entire table, and then click Table in the dialog box.
• Click Show Table Cells to make sure that all cells in the table are defined as individual elements. If cells don't appear as separate elements, do one of the following:
  • If one or more cells are merged, use the TouchUp Reading Order tool to select the area within a single cell, and then click Cell in the dialog box. Repeat for each merged cell.
  • If cells aren't highlighted, the table might not use standard table formatting. Re-create the table in the authoring application.

For more detail, go to the Adobe® Acrobat® 9 Pro Accessibility Guide: Best Practices for Accessibility: http://www.adobe.com/accessibility/products/acrobat/pdf/A9-access-best-practices.pdf.

Alternate text for figures and images

Figures and images are ignored by screen readers unless alternate (descriptive) text is used. All information or data in figures and images must be made available. (Imagine you can't see the image: What needs to be described to convey all information in the image?) To identify the document elements that still need tags, open the Tags Palette, right click, and click Turn on Associated Content Highlighting.

If you want screen readers to describe graphical elements that illustrate important concepts in a document, you must provide the description using alternate text. Figures aren't recognized or read by a screen reader unless you add alternate text to the tag properties. If you apply alternate text to text elements, only the description, not the actual text, is read.

To create alternate text descriptions:

1. Select the TouchUp Reading Order tool.
2. Select Show Tables and Figures in the dialog box. Figures that are missing Alternate Text will have a flag indicating "Figure - No alternate text exists"
3. Right click the figure and choose Edit Alternate Text from the pop-up menu.
4. In the Edit Alternate Text dialog box, type a new (or edit an existing) description for the figure, and then click OK.

Accessible hyperlinks

Adding alternate text descriptions to links makes the links' purpose or use clearer for readers using screen-reading software. To make links in the text accessible:

1. Use the Select Text tool to select the link.
2. Right click and select Properties.
3. Select Tag tab; enter description in Alternate Text box.
4. Select Close.

PDF document language

The PDF's global language must be established to improve readability and accessibility. This must always be done with PDFs converted from Word files. To set the language:

1. Select File/Document Properties.
2. Select Advanced in the Document Properties dialog box and then choose a language in the Language menu.

PDF forms

Forms require special techniques so they are accessible. Use the HHS 508 checklist at: http://www.hhs.gov/web/policies/webstandards/508pdfforms.html.

Accessibility testing

No software can fully test a PDF file's accessibility. Acrobat's Full Check feature can help find problems but cannot verify full compliance with Section 508. For example, the Full Check feature ignores tables and cannot judge if an alternate description for an image adequately communicates information in it. Screen readers, such as JAWS®, should also be used to test PDF files for 508 compliance.

To Use the Accessibility Checker:

1. Click Advanced/Accessibility/Full Check.
2. Select every option for checking, and then select Start Checking.
3. A summary dialog box will appear, along with an Accessibility Report that will include hints for repair. Most problems can be fixed using the Forms Tool or the Tags Palette.
4. Correct the issues and save the file as a copy because Acrobat® has no Undo feature.
5. Test again with Full Check.
6. Check the file for accessibility using a screen reader.

Tab order and structure order.In some cases, even though the tags have been inherited from the source file, the Accessibility Checker will indicate that tab order is inconsistent with structure order. To fix this issue:

1. Open the Pages icon or select View > Navigation Panels > Pages.
2. Click on any page icon and type Ctrl + A to select all the pages.
3. From the Options button on the pages panel, select Page Properties.
4. In the Tab Order Panel, check Use Document Structure.

Table headings.Table headers are not always properly defined after the conversion from Word to PDF. Use the TouchUp Reading Order Table Editor to change table data cells that should be table headings to table headers or change the table data tags directly into table header tags within the tags panel.

Resources on PDF Accessibility

Detailed information is available at the following Web sites:

• Adobe® Acrobat® 9 Accessibility Training Resources
  http://www.adobe.com/enterprise/accessibility/training.html
• Adobe® Acrobat® 9 Pro Accessibility Guide: Best Practices for Accessibility
  http://www.adobe.com/accessibility/products/acrobat/pdf/A9-access-best-practices.pdf
• Adobe® Acrobat® 9 Pro Accessibility Guide: PDF Accessibility Repair Workflow
  http://www.adobe.com/accessibility/products/acrobat/pdf/A9-pdf-access-repair-workflow.pdf
• Adobe® Acrobat® 9 Pro Accessibility Guide: Creating Accessible Forms
  http://www.adobe.com/accessibility/products/acrobat/pdf/A9-creating-accessible-pdf-forms.pdf
• Adobe® Acrobat® 9 Pro Accessibility Guide: Using the Accessibility Checker
  http://www.adobe.com/accessibility/products/acrobat/pdf/A9-using-access-checker.pdf

PowerPoint® Presentations

There are two options for making a PowerPoint® presentation accessible:

1. Create an accessible Web alternative in addition to the presentation.
2. Make the PowerPoint® file accessible.

Accessible Web Alternative

Creating an accessible Web alternative to the presentation is strongly recommended. Accessible HTML files are the gold standard for accessibility. The techniques for making Web pages accessible are well established, and tools exist for testing accessibility, although the results of such testing must be interpreted.

HTML is accessible regardless of the platform (Windows® or Mac) and version, and it does not require proprietary software. For PowerPoint® files to be accessible, the user must have the full software program. The free PowerPoint® Viewer is not accessible. A blind user relying on the free viewer and a screen reader cannot access the information.

When creating Web alternatives, note that HHS policy states that frames should not be used: http://www.hhs.gov/web/policies/webstandards/frames.html.

Creating Accessible PowerPoint® Files

For developing accessible PowerPoint® files, use the HHS Guidelines at: http://www.hhs.gov/web/policies/checklistppt.html.

Before making a Powerpoint® file accessible, other factors must be considered:

• It can be difficult to make PowerPoint® files accessible after the presentation is created. For example, if a text box is used to enter text, that content is usually not accessible to screen readers. To make the text accessible, it will have to be re-entered with the Slide Layout feature.
• There are no tools available for testing the accessibility of PowerPoint® files.
• Testing PowerPoint® files for accessibility is labor intensive, and each slide must be manually reviewed against HHS guidelines.

PowerPoint® files purported to comply with Section 508 must be tested comprehensively against the HHS guidelines before AHRQ can accept them or post them on the AHRQ Web site.

Excel Files

Using Excel for interactive tools is not recommended except when Excel-based tools are intended to be used offline. Web-based versions of Excel tools are easier to make accessible and do not require proprietary software. Excel files can be made accessible, though few developers who create Excel files make them accessible.

Layout and formatting requirements

Merged cells should not be used within the data section of the table. Ideally, merged cells should not be used at all.

All active worksheets in the workbook should have clear and concise file names that allow a user and screen reader to identify the source and contents of the table.

Worksheets should not have flickering or flashing text or animated text. All hyperlinks should display the full URL (i.e., http://www.hhs.gov, not www.hhs.gov). All hyperlinks should be active (i.e., validated to an active and correct Web destination).

Content in text boxes or graphics with embedded text is not accessible. Text boxes are form objects, not text in a cell.

Color should not be used to as the primary means of emphasis. Use an asterisk, border, or other identifier.

Changes must be accepted or rejected. Track Changes must be turned off.

Image requirements

All worksheets with multilayered objects must be flattened into one image and use one alternative text (alt text) description for that image.

Charts are a collection of accessible objects and are not grouped All charts should have Title, Legend, and Axis labels associated with them. This will give users a number of reference points to use to correctly interpret the information being presented.

Complex images (e.g., charts, graphs, flowcharts, etc.) must have descriptive text immediately after the image.

Table requirements

Tables should have a logical layout of the information based on rows and columns. Tables should be oriented so that they are read from left to right and top to bottom. Tables should have clear, concise, and readily identifiable row and column headers.

Tables should be prefixed with the table name and table number (if applicable). This information should be separated from the actual data table so that the screen reader can present it prior to reading the data table.

Table header rows are formatted to repeat on the top of the table as it goes from one page to another. This will allow the screen reader to re-state the header information to the user as the table continues from one page to another.

Excel tables should not have merged cells. Merged cells are only acceptable in the header row of the data table. Row and column headers should start in the first left-hand column of the data table, not the worksheet.

Accessibility requirement

An accessible alternative version of the document should be provided when there is no other way to make the content accessible within Excel.

Best practices

• Indicate, when practical, formula cells that affect cells in other worksheets with a notation in a cell to alert users of the functionality.
• Use only the following fonts: Times New Roman, Verdana, Arial, Tahoma, or Helvetica.
• Create a document file name that is concise and no more than 20-30 characters long to make the content of the file clear within the context in which it is presented. (This is required for Web posting.) The document file name must not contain spaces or special characters.
• Use the Document Properties Summary tab, which lists the document creator and owner. For Author, use the organization name (e.g., HHS), not an individual's name.
• Title all tables to facilitate table identification and help the reader understand the table's purpose.
• Avoid using two or more data tables on the same worksheet when possible.
• Ensure headers are associated with Rows and Columns.

Columns and rows labels

Headers provide information about the column or row cells and how they relate to one another. Row headers are defined in the first column. Column headers are defined in the first row.

There are two methods for labeling Row and Column headers.

First method:

1. Highlight the table. From the Format tab select Auto Format.
2. Select a template from those provided.
3. Select the OK button.

Second method:

1. Highlight the column or row headers. Select Insert/Name/Label.
2. The Label Ranges screen appears with the range that was selected. Select the Add button.
3. The label range appears with the Existing label ranges field (note that the Column labels radio button is selected).
4. Select the OK button

Charts

When creating a chart in Excel, apply a Legend, which acts as a keyed index. To do this,

Select Chart Options from the Chart menu. On the Titles tab:

• Title the chart
• Title the X axis and Y axis

Alternative text

Alternative text must be considered for all images other than charts. It provides a text description of an image or graphic. Informative images (e.g., a flowchart or graph) convey information that needs a text equivalent. Descriptive images (e.g., a logo) provide basic information about the image.

To add alternative text with the Format Picture tool:

1. Right click on the image and select Format Picture from the drop down menu.
2. Select the Web tab and add alternative text in the Alternative Text: box .

Audiocasts, Webcasts, and video

Follow the HHS Web standard for Accessibility and Video/Multimedia Content at: http://www.hhs.gov/web/policies/webstandards/video508.html .

Registration pages

Registration sites must be 508 compliant and resemble an AHRQ Web page.

Captioning

If a product contains speech or other audio necessary for users to comprehend the content, that audio must be provided through synchronized captioning. The captioning may be open (visible all the time) or closed (visible when a user turns it on).

Video

Presenters may embed video into a PowerPoint® presentation or have the contractor videocast it. Either way, the video must be captioned. HHS guidance on captioning video may be helpful (although it is oriented toward HHS agencies). It is located at: http://www.hhs.gov/web/policies/videocaptionguidance.html.

Transcripts

Transcripts of audio need to be delivered in archive-ready HTML format. If the transcript was created from live captioning, misspellings, missing words, and punctuation errors must be corrected before providing AHRQ with a final version.

PowerPoint® presentations

Refer to the section in this appendix on PowerPoint® presentations and accessibility.

Documents posted as .PPT or .PPS must include a link to the free Microsoft® PowerPoint® viewer. File type and size with downloadable files must also be provided. For example: Filename (# MB) (PowerPoint® Viewer).

Planning tips for hosts

Organizations that plan to host an audiocast or a Webcast should ask for presentations about 2 weeks before the event to ensure sufficient time is available to create a transcript. To facilitate the creation of slide scripts, hosts should ask each presenter to provide the context narrative in the Notes section of PowerPoint® slides.

Planning tips for presenters

Presenters should use complete sentences in the Notes section of the PowerPoint® slides so users can understand the main points. If presenters are using visuals to make a point, they should also explain their point verbally. Presenters should avoid using acronyms and abbreviations in slides or when speaking. Further, they should provide a list of medical terms, names, and other unusual terms to the host before the event to increase the accuracy of live captioners and transcribers.

Flash®

Even after all software and hardware requirements are met, the very nature of Flash® can make full accessibility difficult. Because Flash® content is dynamic and can change in response to user input, a wide range of issues must be addressed.

AHRQ follows the HHS Web draft standard on acceptable uses of Flash® at: http://www.hhs.gov/web/policies/webstandards/useflash.html.

Note: All proposed use of Flash® must be approved by HHS at the concept stage. Contact Biff LeVee (biff.levee@ahrq.hhs.gov) at AHRQ for assistance.

JavaScript

JavaScript can cause a variety of problems related to both accessibility and usability. Some accessibility problems stem from the fact that certain assistive technologies do not support JavaScript. Further, some users choose to disable JavaScript in their browsers. However, Web pages can use JavaScript if it is used carefully. For specifics, refer to the section on scripting in the U.S. Access Board's Guide to the Section 508 Standards at: http://www.access-board.gov/sec508/guide/1194.22.htm#(l).

Note:

"Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used."

Return to Section Contents
Return to Guidelines Contents
Proceed to Next Section