Accessible Technology Initiative (ATI)

First year web report

 

Purpose

This report is deliverable as a status update (15 May 2007), but its primary purpose is to provide the foundation for your Web Accessibility Implementation Plan as specified in Coded Memorandum AA-2007-04.

Format

Section 508-compliant HTML, probably but not necessarily prepared in Word and converted with Dreamweaver or the Illinois wizard, and posted in your “campus folder” directory of the ATI Blackboard site.

Contents

  1. Executive summary
  2. Link to HiSoftware report (format provided separately) on all “campus cross section” pages, including those currently unremediated, with a brief description of the process used to select the cross section pages.
  3. Link to HiSoftware report on the “repair sample” selection, updated to reflect remediation accomplished during this process. Also include a brief description of the process used to select the repair sample pages.
  4. For each page of the repair sample, a link to the page and a brief written summary of actions taken or planned, which may include the following or additional points as applicable:
    1. Extent of problems found and difficulty of fixing these problems (for example, a page might have missing alt-text in many images, but fixing these might take just minutes – on the other hand, a single problem in multimedia might take hours to fix or might not be fixable at all with current resources.). Please focus on the most important problems.
    2. Extent to which fixing this page also fixed other pages (for example, fixing a template or script versus fixing local content on the page)
    3. Any key lessons learned, techniques developed, or other generalizable repair practices (technical or organizational)
    4. For pages or problems that cannot be fixed immediately, describe current actions (technical or organizational) to provide equally effective access to the page content.
    5. For pages or problems that cannot be fixed immediately, describe how a long-term fix is to be accomplished, who will need to do it (for example, a product vendor), and the estimated time and cost of repair or replacement
  5. An estimate of the difficulty, time, and cost to completely fix the campus cross-section, based on your experience with the repair sample.
  6. Any campus-wide trends that you have identified in development techniques, developer skills, common accessibility problems, and so on.
  7. Any organizational and infrastructure problems in web development and maintenance that you have identified.

Final Clarification for the First Year Web Report

Note: The items listed here are meant to streamline and clarify the process. If part of this report appears to make your job harder then either you misunderstood the item or we did not state it clearly. Before making any heroic changes based on this document contact us. It should really make your job easier.

  1. Problem: Our skills with Hi Software differ from campus to campus- At least half of the campuses cannot use the software effectively or at all as of April 1, 2007.

    Simplifications:

    • Use Cynthia Says on each page one by one.
    • This first year project does NOT require professional competence using the Hi Soft enterprise software.
    • If your campus has never used Hi Soft before, build training into your planning for future years.
  2. Problem: Highly distributed campus webs- Campuses with distributed webs are having difficulty with the repair phase of sites that are not under central control.

    Simplification:
    • Limit your Repair Sample to pages under central control.
    • If you want to include some of the pages that are out of your control in your Repair Sample you may treat them like off-campus vendors. Don't repair them. Define an equally effective access.
    • Make a note of all such "difficult" pages and try to estimate their prevalence so you can address them in your future planning.
    • Remember: your Repair Sample can have as few as 10 sites. You are not expected to do more. Make your cross section broad and representative, but when you actually repair just do what you can do. 10 is enough.
  3. Problem: Staff limitations- Many if not most campuses are finding that their web team is under staffed. The act of performing this accessibility assessment is stressing some web staffs beyond their limits.

    Simplification:
    • Limit the scope of your study to fit your staff.
    • If there are sites you know need repair and definitely require urgent attention don't included them in your study. Mention these exclusions and document your reasons for skipping them, but you don't waste time testing cases that you know don't work and must be fixed.
  4. Problem: Ambiguity in the Regulations- The actions to satisfy 508 are not always clear: The fact is that Section 508 and WCAG 1.0 have known areas that lack precision. That is why Congress and W3C are developing new guidelines. The new standards will make it easier to verify when you have met the standard or law. Until these changes are complete, we must guess a little.

    Simplification:
    • The newest Manual Checklist has items marked as "must fix". To repair a site you need only do the "must fix"steps. Everything else is optional for repair.
    • Note: When you design and develop new sites or completely replace outdated sites, you should do everything in the Manual Checklist, but that is NOT part of this first year assessment effort