Writing a solid web accessibility policy: Cornell gets it right
One of the most common requests we get from the field is for information and resources on policy creation. Most often, people want to see samples of what this looks like in higher education. Of course it is because people benefit from models they can look to, as they create their own. Those wanting to create their own policy should feel heartened, as there are many good examples available. A couple of months ago I wrote an article on the topic; Looking to the Work of Others as You Create Your Institution's Web Accessibility Policy. While this article contains some fantastic resources, it also assumes that the reader would want to pick through several policies to find the right match of language, style, and substance.
I thought it a good idea to profile the complete policy from a single institution. I have long been a fan of the draft policy in place at Cornell. The Director of IT Policy at Cornell, Tracy Mitrano, facilitated the development of this university-level policy. It is still a draft, and in process, but it is expected to be promulgated in some relative form such as this one by the end of the calendar year.
With permission, I have dissected their policy to show how they address critical components, and I have made the entire policy available as a single intact PDF document so the reader can see all the elements in context and intended sequence.
While there are a few items I would take issue with, in my thinking Cornell gets this policy [mostly] right and deserves to stand as a model for others. If Charles Colton is correct that "imitation is the sincerest form of flattery", then perhaps we'll see many policies in the future emulate what Cornell has begun. Hats off to them from the NCDAE team!
To begin, let's review what we believe to be the minimum components of a web accessibility policy. Please remember that this is different from the implementation plan that is written by an institution to set in motion the policy document. Our recommended minimal policy components include:
- Summary statement of the policy
- Effective dates
- Scope of the policy
- A technical standard
- A provision for procurement
- Consequences for non-conformance to the policy
- Mechanisms for ongoing review
The following sections detail each of the above policy components and show how Cornell elected to address each in their (draft) policy. I also discuss the very few items that diverge from an ideal plan. However, I recognize the complexities of the work they have presented here, and I don't want to make assumptions about the reason(s) they are in the draft document. At the end of the document is a link to a PDF of the complete policy draft so you may read all sections in context. Thanks to Tracy Mitrano, Director for IT Policy at Cornell University for sharing this document with us, and with you.
Summary statement of the policy
It is important that the policy provides a summary to explicitly state the rationale for the policy, expected outcomes, when key steps are to be completed, and how these steps are to be achieved.
How Cornell addressed this:
Cornell provided most of these items in their Policy Overview (p. 1). They provide the reader with quick references to the when and how elements through a table of contents (p. 2). The authors also cover the importance and rationale in more detail in the Principals sub-section Overview (p. 9). Placing this content in both summary, and longer forms, helps to highlight its importance to the reader.
Effective dates
The date the policy comes into effect is stated. For institutions with a phased implementation of policy, multiple dates, deadlines, or interim dates for each aspect of the plan may appear.
How Cornell addressed this:
In the overview section (p. 8) they note that they have divided the Cornell web space into different sectors, each with different dates for implementation. Then in the section, Timing for Adoption of Standards (p. 13) they note which sections must conform within broad timelines (i.e., "within one year of promulgation" of the policy). It is important that they recognized the work cannot occur all at once and that some elements must be prioritized. This is reflected in their choices of a phased timeline.
Scope of the policy
Web content that falls under the scope of this policy is defined and included (e.g., are students' pages included or exempt? Does the policy apply to all content under the institutional domain? What is the protocol for institutional content that is not under the main domain, such as alumni pages?). If the institution exempts legacy pages, they are defined or identified? Any exceptions to the policy, and those who can authorize exceptions, are identified and a process for obtaining exemptions is described.
How Cornell addressed this:
They begin by highlighting for the reader the differences that exist across pages in their Definitions section (pp. 9-10) by grouping pages, sites, and applications into those for whom the accessibility requirements will apply and those for whom it will not. They then reinforce this notion when they refer to the timelines for adoption (p. 13). Here is where I found a divergence from the ideal. Again, let me reiterate that it is not my intent to second-guess the authors of a complicated set of institutional policies, and I realize that often times, compromises occur. However, it is my opinion that exempting the institutional alumni organization and student groups confirmed by the institution (e.g., the Greek system on campus) from this provision will facilitate lack of access by some who would like to have it. Moreover enabling an undue-burden clause, typically seen in accessibility policies, without a requirement to contact any campus office or document the logic behind this decision or any attempts at accessibility efforts, may be an invitation to widespread abuse. Cornell may find that in the future, faculty and staff alike invoke "undue burden" as the recurring rationale for inaccessible content, even when the actual reason was lack of desire or attention to conforming to the accessibility policy.
A technical standard
A technical standard provides the institutional criterion for accessibility and as such is included in the policy. The stated standard helps staff members understand if their web content is in compliance with the policy of the institution. Web accessibility standards most commonly used by academic institutions as well as federal and state entities include Section 508 or WCAG 2.
How Cornell addressed this:
Throughout the document Cornell sprinkled references to their chosen technical standard. They began with mentioning it in their Policy Statement (p. 1), included it in their Definitions (p. 5), and made it explicit in their Overview (p. 8). They also devoted a section, "Web Accessibility Requirements" (pp. 11-12) to the technical standard. I am curious as to how they will deal with the impending refresh of Section 508? While they did not mention this in the document that I could find, I was unsure if they would stick with Section 508 once it refreshes to new standards, or stick with the technical definitions of accessibility as defined on pages 11 and 12 (i.e., the current Section 508 standards)? Finally, if my interpretation is correct, I do have concerns with the allowance of text-only sites.. While Section 508 does allow for it in the event that content cannot be made accessible in any other way, this is not how I read the Cornell declaration (See p. 12). If so, it seems to me that anyone could choose a text-only alternative as his or her first choice.
A provision for procurement
Accessibility is a factor in all purchases, licensing agreements, requests for proposals, or other contracts. Procurement of accessible goods and services, in line with the stated policy, is expressly included in the policy. Accessible goods and services include any contracts for goods or services that will impact the institutional web including: content creation and delivery tools; authoring tools; course or learning management systems; student, financial and administrative tools; course resources that are shared but originate from other institutions; and products developed by the institution.
How Cornell addressed this:
The policy document begins with including procurement in the definition of "to whom this policy applies" (p. 7). They also refer to it in their Procedures section (p. 9), and they danced a delicate and grey line well. We all know that while our society is in a transition stage of web accessibility there will be products that do not yet meet accessibility provisions. What needs to happen is assurance that a market advantage exists for accessibility. This can occur during procurement (i.e., vendor accessibility in products is reinforced through purchases). Cornell does allow for the procurement of inaccessible web applications "when no equivalent alternative exists (p. 9). And, they further detail on a footnote on page 13 a requirement to ensure that accessible alternatives do not exist by stating; " If the vendor does not offer a compliant product, all market alternatives must be explored". In this way they will continue to put pressure on the vendors for accessible products. Moreover this practice will help mitigate the age-old cost shifting that occurs when vendors provide inaccessible products to postsecondary institutions that are compelled by law to provide accessible products and services. Brilliant!
Consequences for non-conformance to the policy
Statements are included that detail consequences when the policy is not followed. These statements are included, or referenced, in the policy and are referenced in other governing documents.
How Cornell addressed this:
While not specified in the accessibility policy documentation, it is implied that bodies for whom this policy applies must conform. This is because the accessibility policy is tied to all official Cornell policies, where conformance is expected. This can be found in their 4.1 Policy on Policies statement
Mechanisms for ongoing review
Changes over time may require that the institution's accessibility policy be periodically reviewed to assess the appropriateness of current measures and make adjustments as necessary. A defined system for review and revision, along with provisions for who is responsible for these decisions, is included in the policy.
How Cornell addressed this:
Much like the section above (i.e., nonconformance), mechanisms for ongoing review are covered in the broader Cornell policy domain. They do have Policy Review groups, and this topic is covered in their Policy on Policies statement.
A worthwhile institutional web accessibility policy requires careful deliberation and support from the top. Cornell has done an excellent job of creating a template that others can use to guide their efforts. We appreciate their willingness to let us share it to help inform your efforts.