Web Accessibility First Year Report
Of the estimated 100,000+ administrative pages on the SSU Web, virtually all require a variety of repairs to meet Section 508 requirements. Errors with HTML and CSS syntax are very common, as are problems with semantic markup, accessible tables, color contrast and equivalent alternative text. These problems are found in all web documents, including HTML, PDF, DOC and PPT. Evaluating and repairing pages is technical and time consuming. Campus web standards are out of date, unpublicized, and unenforced. Going forward, the campus lacks the infrastructure and trained personnel to make all future web pages compliant with accessibility requirements.
The SSU ATI Web Accessibility Subcommittee selected 100 pages that were representative of the University website and critical to student and employee success. This cross section included all pages linked on the University homepage, most academic department homepages, and some other pages that were highly used by students and employees, both current and prospective. Some academic department homepages were omitted from the cross section when they used templates that were identical to other pages already in the cross section.
- Cross Section Pages to Test
- HiSoftware AccMonitor Report for Cross Section
Note: Due to a problem with HiSoftware configuration of webs for some campus web servers, approximately 20 pages were unintentionally included in the report.
The Repair Sample was selected randomly from the Cross Section list by Elaine McDonald, Faculty Chair, Assoc. Professor of Mathematics, and ATI Web Accessibility subcommittee member. Her process:
"I used Excel. I selected Analysis ToolPak and used the random number generator (1 variable with 20 numbers generated from the uniform distribution on 1 to 100. I set the seed at the time I woke up this morning. I rounded the numbers to integers)."
The repair team, Barbara Moore and Christine Hayes, met with the department staff responsible for each of the pages, and walked through the manual evaluation. Repairs were made on most pages - 11 were fully repaired, 7 partially repaired, and 2 not yet repaired. Most repairs were made by the repair team, and department staff made repairs on 6 of the pages.
- List of Repair Sample Pages
- Hisoftware AccMonitor Report for Remediated Repair Sample
- Detailed Manual Evaluation Results for Each Page
- Summary of Repair Sample Results - HTML
- Summary of Repair Sample Results - PDF
Fixing the Campus Cross Section
On average, Repair Sample HTML pages had 109 errors and took 80 minutes to repair. Evaluation of each page took about 1 hour. If we use the same process to evaluate and repair the rest of the Cross Section, where the majority of work was done by the IT and Library webmasters, it will take approximately 187 hours, approximately 1.15 person-months.
The following time and cost estimate to repair the remaining Cross Section pages assumes the repairs would be made by a permanent employee with the appropriate skill set classified as Information Technology Consultant – Career level.
|evaluation time/page||60 minutes|
|repair time/page||80 minutes|
|# of HTML pages in Cross Section||80|
|total repair time||186.66 hours|
|ITC Career monthly salary
(10% above bottom step + benefits)
The total time to repair will depend on how much of the developer's time can be devoted to repairing pages. At half time, it would take approximately 2.5 months. Currently, there is no skilled staff member with this amount of unscheduled or flexible time.
PDF and Word DOC Repair
We evaluated 13 PDF files - 12 failed Acrobat Professional's accessibility test. A few of the files were very simple in format and needed few repairs. Three documents were very complex in structure and layout, and took 1-3 hours to repair. Two of these could be repaired using Acrobat Professional's Accessibility tools to insert tags, alt text and semantic markup, and correct read order. Another was rewritten from the original MS Word Doc source file. We applied semantic markup, then exported to PDF and cleaned up in Acrobat Professional. One PDF could not be made accessible from within Acrobat, and will have to be recreated from the source document, or recreated from scratch.
The 100 HTML pages in the repair sample link to 284 PDFs. Unless we can acquire a tool that automates evaluation and repair of PDFs, we will need to examine and manually repair each file individually.
|evaluation & repair time/page||54 minutes|
|# of PDFs in Cross Section||284|
|total repair time||255.6 hours|
|ITC Career monthly salary
(10% above bottom step + benefits)
For many PDFs, it may be more effective to recreate the content as accessible HTML. Most department content developers do not have Adobe Acrobat Professional. The learning curve for Acrobat Professional is steep, probably more difficult than learning good HTML techniques.
None of the Repair Sample pages linked to MS Word DOCs, however, the Cross Section links to 65 DOCs. Each will need to be inspected and evaluated.
For PDF and DOC repair we will need:
- A decision about who will repair the PDFs and DOCs in the Campus Cross Section - Web Office, department staff, or someone else;
- Training for department staff in MS Office Suite and other common applications used to create PDF content - specifically in how to structure a document semantically before the PDF is generated;
- Acrobat Professional licenses for department PDF developers;
- Training in Acrobat Professional accessibility tools for department PDF developers;
- Reprographics staff will need training in applying semantic markup to InDesign documents that may be used for PDF and other web formats.
- Guidelines for department DOC and PDF developers - when to use DOC, PDF or HTML.
Common Accessibility Problems
The most common problem found in the Repair Sample was syntax error. Over 50% of manual evaluation errors were syntax validation errors. Problems with styles and lack or misuse of semantic markup were also common issues.
- Syntax Validation - 53.9%
- Checkpoint D, Styles - 12.3%
- Semantic Validation -11.9%
- Checkpoint A, Alt Text- 5.4%
- Checkpoint C, Color - 4.1%
- Checkpoint H, Complex Tables - 4.0%
- Checkpoint G, Simple Tables - 3.2%
Developer Skills and Resources
There are 178+ unique web developers with editing access to one or more pages in the Cross Section. Of those, we know of only 5 who are employed primarily as web developers. Each of the 5 has other duties, including system administration, supporting faculty and student WebCT use, designing and producing printed publications, and more. These 5 estimate the amount of time they work on web development is somewhere between 3.0 and 3.8 FTE.
While evaluating eht repair sample, we noticed many other problems with administrative websites. Most sites had one or more of the following problems:
- Important content such as advising or class schedule information was out of date;
- Old content was still publicly available on web server – for example, many pages named default-old.html;
- Design, layout or navigation not consistent from page to page within department sites;
- A wide variety of HTML, CSS and other design errors had snuck into good templates, then copied into new pages over time;
- Browser-specific design problems that the department web developer was not aware of because the pages had never been tested in multiple browsers.
We also heard many comments from the department staff. Most expressed frustration - lack of training, skills, time and other resources needed to maintain department websites. Following are a few paraphrased comments which were typical.
- "I don't understand any of this HTML stuff and I never will."
- "We just haven't had the time to update our site since the last student assistant left - now it (the content) is four years out of date."
- "I'm not sure what most of that stuff in the directory is. It's been there for years, but I'm afraid to delete it because something might break."
- "The last student assistant made a bunch of changes, but didn't give me copies of the files."
- "I went to the Dreamweaver training, but I don't work on the pages very often and forgot everything from the training."
- "Gee, I didn't realize the navigation was broken!"
Most of the department staff we met with were happy to learn more about web accessibility, and pleased to have help making their pages more accessible. However, a few expressed doubts about the need to make sites accessible, and whether SSU was really legally required to do so. Some paraphrased comments:
- "Why do I have to do this if I don't have any blind students in my department?"
- "Why do I have to make my site accessible, when (some other university) doesn't have to?"
By chance, none of the repair sample pages included video, though SSU has a growing collection of streaming video. Almost none of it is captioned. Most of the videos were live, streamed lectures open to the campus community. Many of these videos will also fall under ATI Priority 2 - Instructional Materials.
Organizational and Infrastructure Challenges
Probably the biggest issue is the staggering scope of Sonoma State's web presence. At this time, the Web Accessibility subcommittee does not have an estimate of the total number of administrative web pages at SSU. However, our campus search engine finds 227,043 unique URLs on SSU websites it crawls. How much of that falls under ATI Priority One, we do not know.
We do have page counts for the main campus web server, www.sonoma.edu.
|File Type||In Department Directories||In User Directories [see note]||Total|
The numbers above do not include:
- Other web servers run by IT for campus use
- Web servers run by Schools (Education, Science & Technology, Library)
- Web-based tools and front-ends to campus services
- Web front-ends to departmental filemaker databases
- SSU sites hosted off campus
Many of the pages on www.sonoma.edu are probably very out of date. When redesigning a page or site, it's common practice for department staff to move files to an "old" subdirectory in case links break and an old file is needed again. Some department web staff don't realize the "old" pages are still publicly accessible, and in some cases might even be easier to find via the campus search engine than the "new" page.
Decentralized Web Development
Web development at SSU is decentralized. On www.sonoma.edu, there are more than 300 department faculty, staff and student assistants with editing access to one or more of 150+ administrative websites. It is unknown how many department developers have access to other web servers that fall under ATI Priority 1.
Shortage of Professional Web Developers
The IT Web Office is staffed by two staff (one Administrator I and one ITC Foundation) and two student assistants. The ITC's primary responsibilities are to support the campus learning management system (WebCT) - she does not provide web development support.
Outside IT, few departments have full time web staff. The 5 developers discussed above report to different departments: Information Technology, School of Extended Education, Student Affairs and Enrollment Management, and the University Library. Reporting to different departments and housed in different buildings, collaboration and sharing of skills and techniques between these five developers are limited.
Most departmental staff with web responsibilities inherited the sites as an extra duty beyond their "real job."
There is no content management system available on the main campus webserver, and there is no support for any "Web 2.0" functionality. Server technology is limited to static web pages, a few pre-approved CGIs (no custom CGI development or installation), and server side includes. Funding for improved infrastructure needed to run PHP, MySQL, content management systems, and similar modern web tools and technology has been requested several times over the years, but has never been prioritized. Also, the campus web server is not highly available (HA).
If departments want to include Web 2.0 functionality in their sites, or have needs for content management, they must set up their own servers or use off-campus hosting services. These sites are more likely to have accessibility problems.
Out of Date Web Policy
The University's Web Policy is out of date. Issued in 2000, it does not require University websites meet accessibility standards. Attempts to update the policy and make accessibility a requirement stalled in 2004.
Little Oversight, No Central Authority
The University's web policy requires all new web designs or redesigns be reviewed by University Affairs for consistency with the the University's image. This requirement has not been well publicized, and most departments are unaware of it. Many websites go through redesign without review by University Affairs. University Affairs does not review websites for accessibility issues.
There is no central web authority. The Web Office attempts to resolve problems reported to the Web Office, but does not have the authority to enforce legal or policy requirements. In some cases, departments have ignored requests to correct websites that violate state law or campus policy. Reporting the violations to the department's division Vice President and the Office of University Affairs has not lead to a resolution or correction to the problems.