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.
Great advice! I can’t believe I haven’t seen your site before, excellent stuff.
On a related, but different note, you don’t seem to mention on your “about” or “contact” pages which country you’re actually based in. US?
we are facing the same challenges with a similar govt site redev. there are currently hundreds of PDFs on the site and it is going to be a huge if not impossible task to create html versions of them all once the new site goes live.
quality of markup aside remember another challege is that most people have little idea how to write good content for the web. unless all contributors are trained you will need an editor or editorial team to not only clean up markup but edit content.
If you’re doing the conversion for a government agency, they may not have the budget to redo their PDFs. It’s a time consuming process unless all of the files are short and simple. It might make more sense to set a long-term goal of converting documents as time permits. I realize this sounds harsh, but (unless budget permits), it’s going to be a huge process, and most government sites have a lot of content that needs to be prepared outside of the legacy content. By prioritizing legacy content and developing a game plan, you might make better use of your resources.
Writing for the web is an entirely different challenge. Every person has a different view of what is the appropriate level for writing. Sure, it’s easy to say clear and concise, but what does that mean exactly? The next answer is it depends on the subject matter and the audience. This is not an easy concept to address, much less teach.
Okay, that probably sounded a bit cynical, but writing is not easy for everyone, and chances are, especially in a government agency, the person tasked with the job is not naturally a writer. A similar situation exists with editors. It’s a tough job, and if you’re job is editorial on top of other things (or you’re the “webmaster” because it’s a title that corresponds with your job duties), this may not be part of your skill set.
Yes, in an ideal world, writing and editorial functions would be factored into the mix, but my reality (and yours may differ!) is that these tend to be afterthoughts. While most government agencies still have websites, they, like many for-profit businesses, haven’t quite worked out how to integrate their websites (and other Internet functions) into regular workflow. There are a lot of models, but not a lot guidelines.
Wow. We’re having the same issue where I work. We’re a government organization and I’ve been part of a (very small) team that has been building our own in-house CMS system. We’ve seen some progress, but we still have a ton of legacy content stuck in Word and PDF documents. What’s worse is that rarely, if ever, are these source Word files properly formatted in any logical manner that would aid in accessibility.
It’s a daunting task. The one thing we’re trying to do is to get folks to stop thinking in terms of ‘documents’ and instead in terms of ‘content’. Is this content the public needs? Is there a strong reason to keep a MS Word version? If not, stick the content into the CMS and keep it there as the source.
I do agree that a ‘content guidelines’ policy of some sort is a good first step. The reality is that few people have ever been properly trained in preparing content for the web…let alone properly using basic tools like MS Office. A bit of training goes a long way toward getting broader understanding.
Have you considered training them on some simple assessibility tools? One of the free toolbars for IE or Firefox, or the Checky Firefox extension to make it easy to do a Bobby or Cynthia check on the content once published may help them.
We’ve tried training and offered guidelines, but the issue is that these are not web professionals. They don’t know enough about HTML to understand the Bobby or Cynthia checks. Reading the accessibility reports requires fairly in-depth understanding of coding for the web (heck, I do this all the time, and often find myself puzzling over the best way to handle things). These checking tools can be very helpful, but I firmly believe that widespread acceptance of coding for accessibility requires making it as easy as possible on the people doing the actual work. I’m not sure there’s an easy solution to this, but we continue to work on achieving this goal.
It’s really a lack of training at the root. It’s not even about the web per-se. It’s about good writing skills first and foremost. Second to that, it’s about using the basic tools like MS Word properly. Few folks actually use MS Word to produce structured documents (ie, using actual headers, lists, etc.). And I’m not even going to go into the organizations that have most of their content stuck in Powerpoint files… ;o)
You’re correct about the lack of training (and it not necessarily being a web problem. However, users have close to 20 years of using their tools incorrectly, retraining them at this point is going to be rough. I’m working on a series of articles about challenges relating to gathering, preparing, and migrating content to a content management system. If you’ve ever done this for a large site, you know it’s not pretty.
As for writing skills, I could go on for days about that particular issue. I’ll spare you the diatribe.