Planning Enterprise Level Web Accessibility

I was invited to attend a meeting between a communications committee and the new IT director at a college. Among the new director’s responsibilities was the college website and accessibility was on the agenda. What I heard were fairly vague reassurances that the website would be accessible, but really no substantive plans to make that happen.

After the meeting I sent the chairperson a brief list of the sorts of things one should be hearing when accessibility is going to be integrated into the web production process. I thought I’d share those here. Bear in mind that this not the only approach and someone else could come up with different list. But these are the main building blocks to publishing an accessible enterprise level website.

Accessibility Guidelines
The foundation to accessible web delivery is identifying the guidelines you intend to comply with. The government’s 508 and W3C’s Web Accessibility Content guidelines are cited most frequently. 508 is concise, while W3C tries to be complete and overarching. W3C recently updated their guidelines and 508 is in the final stages of revision as well. “Being accessible” is rather vague, but complying with a set of published standard should be concrete and verifiable.

Implementation
How do you intend to ensure the guidelines are followed in your web production? This goes to how pages are created. Will a professional developer or development team create maintain the site or will a content management system (CMS) allow for all level of employees to contribute content? If you use a CMS, then the more accessibility the CMS can automate the less testing and verification may be required later. Automation is attractive, but it still may require thoughtful response. A CMS may prompt for an alt attribute, but what your employee creates for that attribute may require some careful consideration.

Any web elements routinely used on your site and not handled by the CMS may require either training for the staff or outsourcing. For example, a complex data table can be completely accessible, but coding it is not trivial and difficult to automate. Either staff will need to know how to create these or the production can be outsourced.

Verification
How do you test for compliance of either your live site or a pre-live test site? This is where independent validators are attractive. See: http://www.w3.org/WAI/ER/tools/complete.html. Validators have their supporters and their detractors. I tend to stay out of that debate. But no matter what, you need an articulated process for ensuring that your accessibility guidelines are making it into you web site. Even a process in which random pages added within the past two months are spot checked for accessibility is better than no process at all.

Maintenance and Complaint Resolution
Maintenance is either checking new pages for compliance or for evaluating the accessibility of new “widgets” that heretofore have not been used on the site. I acknowledge that “complaint resolution” comes across heavy handed, but the reality is this is an area that could easily turn into a legal issue. If we are informed that a person feels that they cannot use one of our websites on the basis of their disability that can become a serious issue. Simply put, articulate the process of maintaining accessibility, testing new web “mini apps” and assessing end-user complaints about accessibility.

The Take Away
The process of ensuring accessibility of enterprise level web sites is a deliberate and involved process. The process should be clearly articulated from: standards to development to verification and finally deployment and maintenance. Anything less, will more than likely result in a site that is unfriendly and not useful to people using assistive technologies.