What is required? Harvard is required to adhere to Section 508 of the Rehabilitation Act of 1973 (The most important Section of which is 504, but that doesn’t directly apply to web development).
The best way to understand the requirements of Section 508 is to read through the text of it. Specifically 1194.22 and by proxy, 1194.21. It should only take a few minutes. It’s not as bad to read through as the W3C’s Web Content Accessibility Guidelines (WCAG). And, more importantly it’s not as comprehensive.
Once you get the highlights, WebAIM has provided a handy checklist. WebAIM is an open consortium that exists just for discussions such as this, similar to what OWASP is for Security. From the spec, (a) through (j) are reasonably straightforward. (k) needs to be understood, as “text only versions” seems to be a common accessibility misconception and isn’t necessary if all of the other items are taken care of.
(l) is a biggie because it requires a different approach to javascript than 99% of js writers do. What it means is to make all interfaces possible to navigate without a mouse, in a way that’s readable to screen readers. That just means following the spirit of (a) through (j) as it pertains to your interface. This seems borderline impossible when you look at things you’ve built and try to add it in after the fact, but is much more reasonable when you design it from the start with this in mind.
Which seems to be a recurring theme when it comes to best practices. These things need to be thought about from the start, not thrown in last minute. So I think the solution for this is to spread information around. Not try to force this into existing projects, but bring them up as new projects / rewrites begin. It’s a lot to think about, I think the trick is to introduce the topics slowly but consistently into our culture until it becomes something we all know and just do without having to be told.
I don’t think Section 508 is that useful a resource; it’s not the most relevant section of the law for the University and the parts you cite are too dated and too prescriptive in a limiting way. From the beginning, developers have looked at these checklists, thrown up their hands, and ignored the issue because it seemed too hard or too limiting.
Section 508 1194.22(l)’s instructions for scripting is particularly opaque but your comment about following the spirit of the preceding listed items is good to keep in mind. I wouldn’t consider it impossible to address depending on your practices. If you’re already trying to incorporate web semantics, separation of content/presentation/code, and/or approach development with a progressive enhancement strategy, you’re more likely to be closer to these accessibility goals. And where there are still gaps, that’s what ARIA is for.
Yes, accessibility is something that’s hard to “tack on” after the fact. Like coding to web standards, like security, it’s best if it’s baked into development practices. But there’s nothing new about the University’s obligations or the guidance on how to meet them on the web so it’s not a good idea to ignore existing systems with many users.
And this is at least as big an issue for software we buy, maybe bigger. The biggest lawsuits brought against universities have been over both developed and licensed software (including Google Apps). And in this new era of LME and a “loosely coupled” approach, it’s essential that accessibility is a part of the assessment. Again, like security, it’s a risk management issue.
Section 508 is dated, but it’s still the only “law” that software developers in a University are responsible for. I have seen articles from other universities that misrepresent Section 508 as “you have to be WCAG 2.0 AA compliant”. That’s definitely how it “should” be, but it’s not how it is. I wanted that to be clear.
I think you’re right about the typical developer reaction to these lists — I think what helped me is I read through WCAG first, which is a monstrosity of redundancy in nested lists. My original goal was to simplify that, but then I looked toward our legal responsibility and read through Section 508 and that seems like a more reasonable, understandable goal.
I also think you’re right that I shouldn’t get into the mindset of ignoring existing systems just because it “seems daunting”. Presenting it as “risk management” is a good angle to get management more interested supporting it.
A lot of good things for me to think about. Thanks.
Legal statutes just aren’t a useful way of approaching the work. The University is responsible for providing access to the actual individuals in its community; you could do your best to use Section 508 but if there was a person in the community who had need to use something and couldn’t, the University would still need to address that. The Section 508 site has some best practices materials that could be useful but WCAG 2.0 and resources based on it (like WebAIM’s) are better guidelines to work from. “Better” in that they’re more likely to lead you to meet all the goals of a project, including making it reasonably accessible.
Depending on the site, AA can be difficult, particularly the audio & video related sections, but there’ some low hanging fruit like minimum contrast.
“More accessible” is also a good phrase to keep in mind. There is no list of steps you can follow that ends with “there, now it’s accessible.” Accessibility is more of a continuum so if you keep some broad principles in mind (“perceivable” and “operable” being two biggies), you can exercise them in specific cases, “if we add/change X, it will make this more accessible to people who need/use Y.”
5-6 years ago, Liz Eagan (who was under the University CIO at the time) let a working group that developed a presentation for the University’s Risk Management board on this subject. I think what was proposed was received positively but the University didn’t really follow through on them. The biggest disappointment to me was training and resources were not provided. I think they tried to create them internally (in CWD) when what they should have done it just bought an existing curriculum from some place like WebAIM.
At the time, the group definitely didn’t want to recommend the creation of some IT accessibility office, recognizing that it’s not something that can be tacked on or fixed after the fact. I’ve come around to the idea that it would be good if the University had at least an IT accessibility guru/evangelist. Web & software professionals are expected to be familiar with addressing accessibility but it would still be helpful if there was someone who had that as their whole job; to be a resource, to develop (or point to) best practices, to do some evaluations, and sometimes to point out places where accessibility could be improved, unbidden.