The Accessibility Challenge
2/2/2005
We recently completed a large website redevelopment project. The site, when launched, contained nearly 1,000 individual content items. Since launch, that number has grown. We expect it to continue to increase, especially as the departments who took a wait and see attitude start contributing content to the site. If past experience holds true, this site will have close to 5,000 content items within a year or two.
One of the stated goals for the site was accessibilty. Granted, this was not the term used, but as we went through the process of identifying the site’s customers, local senior citizens were mentioned. Because this is a city website, they do not have to comply with Section 508 — however, as many local government agencies choose to do, the city made compliance a goal. Throughout the design process, we kept this in mind, and, because the backend of the site is a content management system, we included “hooks” to ensure things like alt attributes weren’t forgotten.
Okay, fine. Mission accomplished.
Sort of. The day-to-management of the website is handled in a decentralized manner by non-technical staff. The final review before new content is published is done from an an editorial perspective — the webmaster doesn’t know HTML, and the chances of her learning it are slim. When we loaded the original batch of content on behalf of the client, we converted as much as possible to plain HTML. Unfortunately, due to a variety of factors, not everything could be converted, and there are many documents posted as PDF files.
As the person tasked with converting the bulk of the content on the site, I realized that the goal of accessibility faced multiple challenges, all which are part of a bigger challenge:
-
Non-Technical Staff Updating The Site. Have you ever tried to create an accessible table in HTML? I have, and it’s not a simple process. In fact, if you don’t do it regularly, you’re going to require a refresher course. Every time you create a new table. Let’s see, you have the actual table structure, the summary, the caption, grouping of columns and/or rows, the thead, the tbody…I’m sure I’ve missed a few pieces, but you get the picture. Just the idea of explaining the differences between caption and summary makes my head spin; if you want enforcement, we need to talk.
Basic HTML is easy, but most people think it’s hard. Hard enough that they don’t want to be bothered learning it. I see this every day. A WYSIWYG HTML editor works just fine for the average content creator. When you get to fun stuff like acronyms and abbreviations and the art of remembering what code works with which browser, you’ve lost your audience (heck, even if you get someone who has the time and energy to do the right thing, there will always be a few who pop out of the woodwork to argue the semantic differences between acronyms and abbreviations). Coding for accessibility is easy when you’re looking at lightly formatted content. It’s not easy, as evidenced by the various discussions on the WAI lists, when the requirements of the content move beyond the basics.
-
Time and Money. Our content migration process bumped up against the very real constraints of time and money. Like most cities, the particular agency didn’t have unlimited funds to devote to the project. As it was, we took a loss on this aspect of the project, partially because we, the developers, were committed to doing it right. Even so, we were confined by project deadlines. Eventually a site must be handed over to the client and launched.
As staff integrates updating their areas of the website into their day-to-day activities, they will also face this challenge. Content will be added between meetings, phone calls, constituent questions, even emergencies like fires (including while the fire is raging). Careful HTML coding will necessarily give way to “get it up fast” attitudes. This organization cannot afford the luxury of a full-time staff member working on the website. The webmaster mentioned above already has a full, full-time job; the mandate to increase web content adds to her job.
-
Lack of Effective Tools. As noted, we posted a lot of items as PDF files. Sometimes this was because of the time/money issue; sometimes it was because the documents were heavily formatted and converting to HTML didn’t make sense; sometimes it was because the information presented didn’t lend itself to HTML — like complex spreadsheets. Inevitably, these documents were created in applications such as Word or Excel and converted to PDF.
Yes, Acrobat has accessibility tools. Have you used them? Even well-formatted Word documents require scrubbing after conversion. And I doubt anyone is going to pretend that the vast majority of Word documents are well-formatted. Drilling down into documents and fixing conversion errors is a time-consuming process. See above for more information on why this is a problem.
For some documents, there’s the option of copying and pasting from Word. The CMS used by the city allows users to copy items as plain text, and we trained them on this process. A few people will likely remember the steps for stripping out the extraneous Word code and there’s an extra process run on content to clean up the HTML as much as possible. Bottom line, of course, is that these are band-aids, and most users will copy and paste directly into the HTML editing box, note that the document “looks” okay, and post. All of the lovely semantic coding will be forgotten because very few word processor users consider structuring their documents properly.
If Word allowed someone to copy and paste plain text, maybe the final result would have better structure because the HTML mark-up tools in the editor would provide structural elements. Personally, I’d advocate for removing the bold, italic, underline, font selection and size options from the toolbars. Clearly, nobody’s asked me, and users will continue to hit the “B” button at will.
We did everything we could — from design to tool integration to template development to training — to ensure the goal of an accessible website was met. Now the full burden of maintaining the site is on non-technical staff. This is not an uncommon situation — in our experience, more websites are maintained in this manner than are sites under the control of individuals who live and breathe HTML with all of its nuances. Whenever I read that content owners “should” do this and that to achieve accessibility, I wonder how many people dictating the “shoulds” actually understand the process from the perspective of someone who drew the short end of the straw and must now add updating their department’s area on a website to their daily duties?
When we work with clients, nobody questions the goal of accessibility. Quite the opposite. But businesses and government agencies do not have unlimited resources, and they don’t always have technically-oriented staff. I realize there are many individuals pushing for improved user agents and technology; until someone can copy and paste clean HTML from Word or convert to a well-formatted (even if structurally incorrect) PDF file, websites will be littered with the ghosts of well-intentioned content authors who had to balance the “shoulds” with reality. It probably wouldn’t hurt if actual coding guidelines were evaluated from the perspective of people in the trenches, either.