Annual Report: Progress and Planning

This document represents a sample template of the data necessary to meet the reporting requirements stipulated in the OSU Web Accessibility Policy (rev. 06/30/04). Reporting units are not required to use this template, but may submit equivalent information in an alternate format.

Directions: You can fill out this form online and then choose "View Printable Version" to see your entries displayed in a printer-friendly format. You can also:

1. Download/print this form in PDF format to complete this form offline (requires Adobe Reader). Note: you'll need either Acrobat or Reader version 6.0 or above to fill-out the fields electronically and print your changes. You will need Acrobat 6.0 Professional in order to save a new copy of the document with your changes.
2. Download/print this form in Microsoft Excel format.

Help with this form: Implementation Activities Key || Definitions and Terms || Alternate Repair Implementation Strategies.

Implementation Activities Key.

Section I: Overview

This section overviews the entire site (all pages) and asks you to identify the pages evaluated this period, target goals for next period, and long-term development.

Total Pages

Total number of pages (as defined below) in the specified site. This total should also be subdivided into three primary groups, based on functionality and immediacy -- functional, informational, and archival pages. Do not include pages outside your management or oversite, such as personal folders for faculty or students or subsections of the site primarily updated by other managers. Note: your college, program, or division may need to co-ordinate efforts to insure comprehensive and consistent reporting of the entire site; specifically, where primary responsibility for particular pages may overlap or be unclear.

Current -- Total pages evaluated and/or repaired this reporting period

Number of pages receiving full evaluation (as defined below) for compliance with the OSU Minimum Web Accessibility Standards. Note: when using validation software, a page should only be considered "evaluated" when both automated and manual checks have been completed. All pages that have been repaired should be included in this category. Some pages may have been evaluated and not yet repaired and should also be included in this category.

Planned -- Pages to be evaluated next reporting period

Use this entry to set your target goals for the next reporting period. Web sites should be evaluated and repaired at a minimum rate of 15% of pages per year. Priority should be given to functional pages followed by informational pages. Archive pages do not have to be retrofitted unless requested by a user.

Future -- Pages not yet scheduled for evaluation

This section should include any remaining pages not evaluated this year and not planned for evaluation and retrofit in the next reporting cycle.

Section II: Pages evaluated

This section is a subset of the "Current -- total pages evaluate and/or repaired this reporting period" and categorizes those pages evaluated during this reporting period. Note: when using accessibility validation software (such as A-Prompt, LIFT, Bobby, WAVE, or Ask Cynthia), a page should only be considered evaluated and, where applicable, fully compliant when both automated and manual checks have been completed. Any page that has been repaired during this reporting period should be counted in the "errors found" category.

No errors found (fully compliant)

Of the pages evaluated this reporting period, specify the number of pages in each category that were found to be fully compliant and did not need additional repair or retrofit.

Errors found (not compliant)

Of the pages evaluated this reporting period, specify the number of pages in each category that were found to have one or more errors (as defined below) that required repair or retrofit. Any page that has been repaired during this reporting period should be counted in this "errors found" category and included in Section III below. That is, errors were both found (Section II) and repaired (Section III).

Section III: Pages repaired

This section is a subset of Section II, pages evaluated. Of those pages that were evaluated and found to be in need of repair, identify how many pages were repaired in this reporting period, how many are scheduled to be repaired in the next reporting period, and how many are not yet scheduled for repair or will be repaired beyond the next reporting period.

Pages repaired (brought into compliance)

Of the pages identified as having errors (in the question above), specify the number of pages in each category that received the necessary repairs/retrofit and were subsequently evaluated to be fully compliant (no errors found). Pages that have received repairs, but have not been re-evaluated using both automated and manual checks, where necessary, should not be assumed to be compliant and should not be included in this category.

Pages planned to be repaired next reporting cycle

Of the pages identified as evaluated with errors (above), specify the target number of pages in each category that will be repaired, re-evaluated, and brought into full compliance in the next reporting period.

Pages not yet scheduled for repair

Of the pages identified as evaluated with errors (above), specify the number of pages neither repaired this year nor scheduled in the target repairs for the next reporting cycle.

 

[top]

Definitions and Terms.

Archive Pages

Archive pages are those pages no longer actively accessed or updated and are maintained on the web site primarily for internal reference or as a means of documentation, not distribution. Archive pages will have few, if any, "hits" by users in a given year and often contain outdated information or resources. Examples of archived pages may include: copies of old versions of the web site maintained for reference or used as redirects to new pages; collections of past newsletters, calendars, agendas, or announcements; course materials from courses no longer being offered or supported; and other materials unlikely to be of relevance or use to current site visitors. Archived pages do not have to be brought into compliance with the current standards, unless access is requested by a user.

Error

An error is defined as any violation of the current OSU Minimum Web Accessibility Standards. These standards include issues detectable by available accessibility validation tools and those that must be identified through manual evaluation of the page or site. Web managers may use accessibility validation software (such as A-Prompt, LIFT, Bobby, WAVE, or Ask Cynthia), but should not limit error reporting to these automated evaluation reports.

Pages should be identified as having errors when 1 or more errors are detected either by validators or through manual evaluations. Thus, any page detected by accessibility validation software as having an error should be included in the "Evaluated with errors" category. Pages not flagged by evaluation software require additional manual evaluations to determine if they can be designated as "compliant" (no errors found).

Evaluation

A page is evaluated to determine if it meets all of the OSU Minimum Web Accessibility Standards. These standards include an array of elements that can be automatically evaluated using available accessibility validation software (such as A-Prompt, LIFT, Bobby, WAVE, or Ask Cynthia). However, some aspects of the standards require manual review. When using validation software, a page should only be considered "evaluated" when both automated and manual checks have been completed.

Exception

Where compliance is not technically possible or may require extraordinary measures due to the nature of the information and the intent of the web page, exceptions may be granted by the ADA Coordinator's Office.  Request for such exceptions must be made in writing and must be based on issues other than cost alone. Pages identified as approved exceptions do not need to be included in Section I-III, but should be identified in the Notes.

Functional Pages

Functional pages are designated as receiving the highest implementation priority. These pages must be brought into full compliance with the current standards before evaluating and repairing pages in other categories.

Conceptually, functional pages are those pages that individuals must access in order to effectively participate in a program, to utilize a service or benefit from information offered by your reporting unit. These pages are necessary to conducting daily business with your college, department, or program and typically include interactive elements (forms) or time-sensitive information that is updated and/or accessed frequently. Examples of functional pages include: primary web entry/portal pages (must be accessed to access the rest of the site and the functions the site supports), updated course descriptions (used for registration), requests for information, online enrollment or registration for courses or events, access pages to retrieve database information (such as faculty or staff directories or online collections or galleries), and other necessary pages and/or interactive forms and queries.

An operational definition of functional pages should encompass:

1) Any interactive page requiring user input to submit, retrieve, or otherwise manipulate content or date. Any forms page (HTML, Java, ColdFusion, Flash, or other) will be included in this category by default.

2) Any portal or entry page giving access to the primary locations of the site. These are defined as any "default", "index", or "home" page within any directory (folder) of the site or any other page of a different name that is the "resolved" file location when visitors input a URL without specifying a file name. For example: if a visitor inputs: www.mysite.edu/students/ and the URL resolves to www.mysite.edu/students/getregistered.htm, then the file "getregistered.htm" would be considered a functional page.

3) Any page, regardless of its file name or location in the site, that posts critical information and expects users to use this page to retrieve this information. Examples include: lists of current course offerings, lists of key dates or deadlines, and instructions for conducting essential business or activities (e.g. "How to submit your completed application.").

Implementation Priorities

Pages must be brought into compliance following the implementation priorities specified by the revised policy. These priorities include: 1) all new and redesigned Web pages published by any university college, department, program, or unit after, 06/30/04; 2) functional pages; 3) informational pages, and 4) archive pages (optional).

Conversion should occur at a minimum rate of 15% of pages per year, but may be required at a higher rate when a greater percentage of pages are identified as "functional pages." Since functional pages are required to conduct necessary business with your program or unit, they should be addressed as soon as possible, regardless of the implied timeline. Pages repaired beyond the 15% minimum in any given year may be counted toward the following year's requirement.

Example 1 -- accelerated timeline: If a site has 1,000 pages, including 200 functional pages, 650 informational pages, and 150 archive pages, an acceptable implementation strategy might be:
Year 1: all 200 functional pages (20%),
Year 2: 100 additional informational pages (carry forward 5% or 50 pages from year one to meet the year two 15% minimum),
Year 3: 150 additional informational pages,
Year 4: 150 additional informational pages,
Year 5: 150 additional informational pages,
Year 6: 100 informational pages.

Example 2 -- following the implied timeline: If a site has 1,000 pages, including 100 functional pages, 700 informational pages, and 200 archive pages, an acceptable implementation strategy might be:
Year 1: all 100 functional pages and 50 informational pages (total: 150 pages or 15%),
Year 2: 150 additional informational pages,
Year 3: 150 additional informational pages,
Year 4: 150 additional informational pages,
Year 5: 150 additional informational pages,
Year 6: 50 informational pages.

Beginning Year 2 (or after all functional pages have been brought into compliance), an alternate strategy for implementation may be used with the approval of the ADA Coordinator's Office (see below).

Informational Pages

Informational pages are those pages not essential to conducting business or using a service of the reporting unit, but made available as reference, research, general information, or explanation. Informational pages are not perceived as functional pages because they are not essential or not required by the user within a limited time-frame to complete transactions with the reporting unit. However, they are not considered archive pages because they are accessed frequently, updated regularly, or otherwise in "active" use by visitors. Examples of informational pages may include: department histories and overviews, activity reports, guides and reference texts, welcome statements or letters, and other non-essential information. Informational pages must be brought into compliance with the current standards after all functional pages have been evaluated and repaired.

Page

A page is defined as any file stored on the web server and linked to at least one other page in the web site. Where pages are generated by user input or created by a collection of available files or data sources, the presence of a unique and static URL determines the existence of a page. A page defined by a static framework and changed only by the access of different data sets (either by the user or by automated server script) should be considered a single page. Different permutations of the page with different data sets should not be counted as separate pages.

[top]

Alternate Repair Implementation Strategies.

Functional pages must be brought into full compliance first, regardless of level or number of errors. Once this high-priority category of pages has been addressed, web managers may request approval for alternate repair strategies to the "whole page" repair method reflected in this report template. Strategies such as repair by error or group of errors or repair by section/area of the site may be acceptable alternatives. Keep in mind that any alternate repair strategy must meet or exceed the implied timeline for site-wide compliance, as outlined by the policy. In addition, requests for accommodations or access to any page, regardless of its current position in the repair priorities, moves that page to the highest-priority and should be addressed as soon as possible.

To request approval for your alternate repair implementation strategy, contact the ADA Coordinator's Office:

L. Scott Lissner, ADA Coordinator
ADA Coordinator's Office
The Ohio State University
2054 Drake Center
1849 Cannon Drive
Columbus, OH 43210
Phone: 614-292-6207 (Voice)
614-688-8605 (TTY)
614-688-3665 (Fax)
E-mail: ada-osu@osu.edu

[top]

OSU Web Accessibility Center -- 2004. All documents in this guide may be reproduced and distributed in print or electronic format only if offered at no cost to recipients. Visit the WAC online: www.wac.ohio-state.edu. Email the WAC: webaccess@osu.edu.