The clone of documents war

A web project manager produces different kinds of documents including analysis, presentations, benchmarking, debrief, even wireframes. I work for many different companies and it happens that i am asked to use ready-to-use templates with institutional logos, colors and fonts.

This is where the battle begins. If it usually takes a couple of hours to produce the documentation, trying to make it fit into the template that was handed to me is often a titanic task.

The problem is that it is not, in most cases, a real template, but a clone of documents that have been emptied of content and with no trace of formatting guidelines.

Font type and size have not been made as document styles, but they have been applied to the text whenever necessary. And even if styles were used, they were only for the main text and (perhaps) for a type of header.

This approach is inefficient for several reasons:

  • every time you insert a new element, such as a title, you have to copy its style from the previous one
  • you lose the “semantics” of the document: headers should be as that because the information is specified in the document, while in these documents they are headers simply because the font is “bigger” than the one used for normal text
  • quality will degrade over time: the first two documents will comply with the standard in some way, the next will lose almost all the formatting
  • it is not possible to apply the styles at a later time, for example in the case of documents already produced; they have to be re-edited item by item

This occurs with Word documents, but not only. Powerpoint and Keynote also suffer the same problem. Rather than invest a half a day to create the master slide which can then be applied in each presentation, it is considered a simpler approach to create a presentation with some slides which are then copied and pasted over and over again.

Whenever I can I ask for the clients their “template” before producing documentation, so that I can check how they are made. If the quality is not satisfactory to me, but the number of documents that I plan to write is small, I still use these templates to produce the documentation.

But if have to write many documents, I usually prefer to invest some hours to completely rebuild the template. The operation usually takes me a couple of hours (in case of a presentation a little more), but it is time well spent, especially for me.

On the surface, compared to the template that was handed to me, nothing changes. But the work of producing the documentation is surely reduced.

Learning from one’s mistakes

Some projects fail. Once I received this email from one of our clients:

Good morning [account manager] and Antonio,

we want to express our disappointment regarding your behavior and the work done.

We believe that the many requests and modifications we are asking you are a direct consequence of your work. We refer, in particular, to the fact that we asked you a_b_c while you proposed us d_e_f. You can agree with us that in this way our objectives were not met. We are now in the process of putting online a product that is quite different from the one that we wanted.

Our criticism is based on the lack of suggestions and ideas from your side – experts in this field – and on your attitude of mere executors.

Shocking, isn’t it?

A message with such a tone isn’t a bolt from the blue, but rather a direct consequence of an email sent by us in which, rudely, we ask the client to allow us to close the several activities in progress and to stop adding new ones every couple of days. Obviously this is not the right approach. It’s just the last in a series of errors that, from both parties, characterized the whole project.

Before analyzing what has gone wrong it’s important to put the project in its context:

  • the first meetings with the client were held  a year and a half before this email;
  • the project covered the creation of a web site with features such as booking, searching, non-standard e-commerce procedures, and with a link to an external and proprietary information systems for price lists and address books;
  • the site was meant to substitute the previous version, built by our agency;
  • after the requirements analysis phase and several brainstorming sessions, we presented a working prototype containing the main features of the project.  The client was given the opportunity to experiment with the prototype for some weeks;
  • the total effort estimate was 350 man-hours.

The client, even if it doesn’t seem so by reading the email, has been involved in every step of the project

  • the gathering of useful elements for the project were based on a series of meeting where the client set his expectations;
  • we developed a working prototype of the application, sharing every detail with the client;
  • we chose to split the project in about 5 parts to shorten the deployment and let the client test the various functionalities

These seems to be solid basis for building a valued product. The email we received, however, is not on the same wave lenght: our client is unsatisfied, convinced this is not the product he wanted and expresses doubts regarding our expertise. How can this be possible?

If we take a deeper look at what happened, however, we can easily notice that many mistakes were made, on both parts. Here’s a list with the most important ones:

  • Mistake #1: you need a brand new site – It all started when the client expressed some perplexity regarding the site currently online. The site was fine after all, but there were some bugs (above all there were usability problems, especially of interface coherence). At this point the client is persuaded to redesign the whole site and he is promised a better, more usable, faster one. Maybe it was not necessary a complete redesign.
  • Mistake #2: it will cost you 100. No 300. Let’s make a deal: 200 – Without any analysis a first estimate sent to the client is far from the truth. Having developed the previous version doesn’t necessary mean that estimation for the redesign is easier. The real estimate is three times the first one, the client is astonished and we agree on a price that disappoints both parts.
  • Mistake #3: a phantom, not a client – We did not stress enough that we needed their help and approval throughout the project lifecycle. Approving a prototype meant to the client that the development phase was just a boring activity with no decisions to be taken on their side. We did, to be honest, included an estimation of their effort in the project documentation, but it was not enough. We waited weeks for an answer, sometimes.
  • Mistake #4: client contacts not motivated – To succeed, everyone involved in a project has to master communication skills, especially the project manager and the people on the client side that relate with her. That didn’t happen. The project was assigned to a freelance that didn’t succeed in answering doubts and questions and evaluate proposals. When you are in such a situation raise your hand before it’s too late.
  • Mistake #5: software is intangible so you can change it till the last minute – Even if it’s possibile to evaluate a change in the specifications, this has to be seen as an execption, and not a rule. The project seemed ready to be put online, but not on the client’s mind.
  • Mistake #6: the site doesn’t do what i wantThe site doesn’t have to behave as you want, but as your user want.

The lifecycle of web accessibility

Nowadays, building a web site is a task that requires many different professional skills, each one with its own life cycle. Development, as we learned in some software engineering class, has a life cycle and so have usability, design and content.

However, when we discuss web accessibility, it often seems that this discipline comes into play only when we develop templates or write content.
Instead, this is rarely the case.

In this article we’ll divide the life cycle of web accessibility into 5 different phases and we’ll see how they are strictly interconnected with other disciplines such as graphic design, development and content management.

Please note that this cycle is not intended as a linear sequence of steps and that it focuses on skills rather than on people (because the same person can master more than one skill, especially for small size projects).

Requirement Analysis

What’s In This Phase?

During the requirement analysis phase you define the target audience of the site, the business expectations, the technical constraints and the user’s goals. You interact with your client to have an understanding of the site purpose and to know which resources and which tools are needed to build it.

Usually, if you’re doing a good job, you will prepare different scenarios. A scenario is a hypothetical representation of how a specific (imaginary) person will interact with the site, it contains a user profile (called persona) and a schedule of their typical day.

How Web Accessibility Comes Into Play

You need to define specific profiles of people that will use your site, being as detailed as you can. This means that you have to take into account people with a combination of disabilities that can be physical, mental or technological. An excellent example can be found reading Mark Pilgrim’s Dive Into Accessibility, a tutorial meant to help developers in building accessible web logs (and websites), where the author presents 4 different scenarios based on disabled people.

Which disability considered in your scenarios depends on the audience of your site, but bear in mind that a disabled person interacts with almost every kind of site. You could think, for example, that a blind person will never use a site that sells books, but this is far from being the truth. What if this person wants to buy a present for a friend? Can you afford to exclude him?

The scenarios you’ll write can affect several aspect of your project.
If you are redesigning a site, for example, you may decide to exclude previously written content from your site (because it’s totally non accessible) or to convert it in accessible format. This can have a huge impact on costs, so you have to take this decision at this early stage.
If you are evaluating a CMS, you may decide to adopt it or not depending on its support of accessible tags (you may even decide to build your own). What about your content providers? Do they have the required skills to produce accessible content or do they need training?

Conceptual Design

What’s In This Phase

Here you need to define the workflow and information architecture of the site. You will describe the way users interact with your site, how they move through the pages and how they achieve their goals. In this phase you will also structure, organize and label the content of you site, design the search functionalities and last but not least, define the navigational paths.

How Web Accessibility Comes Into Play

The purpose of this phase is to present an interface so that the user can easily use the site and find out what he’s looking for. Accessibility shouldn’t be taken for granted, just remember that you have to address specific needs.

A person affected by dyslexia, for example, may find it difficult to understand the labels you used for the menu bar. For the same reason, limit the number of items on a list and limit the length of a page as well.

On the other hand, a blind person using a screen reader lacks an overall picture of the page, so you have to organize content in a way that can provide him a short summary of what he can find. In this sense an effective search functionality is extremely important because a blind person can’t scan the page and will generally trust the first results he receives (usually, we all do).

A word of caution: don’t design an alternative text-only version of the site: disabled people are not second class citizens; they can and have the right to experience the same page as you do. Don’t forget that web accessibility is an additive process: you have to add things (accessible tags and attributes), not get rid of them. You can read more in an interesting article by Usability Infocentre.

Prototyping and Production

What’s In This Phase?

As you can imagine, this is the core phase. Here you build graphics and HTML templates, develop all the needed software applications and write the content for the site.

How Web Accessibility Comes Into Play

This phase is deeply affected by accessibility issues.

Graphic Templates

A web designer will translate inputs coming from the preceding phase into something that’s visually appealing. You are surely aware of the constraints about a graphic template that will eventually be translated in HTML by a web developer. But this is not enough. You have to know how to meet a disabled person’s expectations. Here is a non-exhaustive list of things to keep in mind:

  1. try not to use graphics for menu and forms if text can suffice (and, most importantly, don’t use small text on these graphics)
  2. use legible fonts
  3. don’t use small graphics if they are linked (they can be difficult to click)
  4. do not create precision layouts that need to be translated in HTML as fixed pages, prefer liquid layouts
  5. avoid using colors for meaningful descriptions
  6. use high contrast
  7. avoid hiding menu items (that will be rendered using DHTML or applets)
  8. don’t get rid of submit buttons in forms (that will require Javascript)
  9. provide enough space for accessibility-related items (transcripts, D links, skip navigation links, form labels, accesskey descriptions). In other words: don’t design to the pixel
HTML Templates

The work of a web developer is fundamental for assuring the required level of accessibility. The best choice is by far the adoption of standard such as XHTML and CSS (also for layout), but an accessible site can be built also with simple HTML. Whatever is your choice, the code must be valid. This means that you need the help of the graphic designer, because if they have built a very precise, complex and fixed template, you’ll have a hard time reproducing it using only valid markup.

When you build an HTML template you have to use all of the tags and attributes available regarding accessibility:

  1. when coding forms, use a rich set of tags to enhance accessibility
  2. make sure that all meaningful graphics have text equivalents
  3. don’t use DHTML, Javascript or Applet if it’s not strictly necessary (and if you use them, provide alternate access to the information)
  4. include links that a user can click to skip repetitive regions of the page
  5. use the right markup (don’t leave h1h6 on the shelves, use them)
  6. the page has to be read also if CSS are turned off
  7. use relative font size so a user can easily change them from the browser interface
  8. create a logical tab order through links
Application Development

Every application used for publishing content on the site has to accept accessible input and has to produce accessible output. This is especially important for applications like CMS.

If this system doesn’t accept alternative text and descriptions for multimedia (input), the page generated can’t be considered accessible. On the other hand, if it produces a questionnaire using non standard HTML or without description labels, the page can’t still be considered accessible. This is a key point for the accessibility of a medium/large scale web site.

You can spend a lot of time and energy developing accessible templates and content, but if the system doesn’t manage them, all your efforts will be vanished.

Content Development

As a content manager, you need specific skills to produce accessible content. First of all, you need to know how to write for the web, because this skill is strictly related to web accessibility: use a clear and simple language, write short sentences, use the active form whenever possible, and so on. You can find a valuable resource reading Hot Text – Web Writing That Works.

Concerning web accessibility, the list of things to consider seems intimidating:

  1. provide alternative text for images
  2. write audio captioning and transcription
  3. write video subtitling, captioning and transcription
  4. insert data table supplementary information
  5. use the right markup (paragraphs, heading, titles, keywords)
  6. produce content that validates
  7. use the title attribute whenever is applicable
  8. specify changes in natural language

The above are the minimum requirements, but a good content manager needs to possess a general understanding of semantic, so that content can be organized, archived and presented to the user in different ways.

Testing and Launch

What’s In This Phase?

Applications are evaluated to test their adherence to specifications and initial requirements.

How Web Accessibility Comes Into Play

Web accessibility of the entire site can’t be evaluated using automated applications, such as Bobby and A-Prompt. Yes, these tools can give you some suggestions and catch macroscopic errors, but testing accessibility is a human intense task.

Depending on your site, on your content and on your audience, your accessibility level can vary. Using different browsers such as screen readers, voice browsers, or text-only browsers, try to use your site keeping in mind your audience and their goals. Moreover, with the evolution of technology, be ready to refine your accessibility in the future and limit the use of "ad interim" solutions.

Maintenance

What’s In This Phase?

New content is added, new applications are built, new sections are opened.

How Web Accessibility Comes Into Play

Never forget that you have to check all your new initiatives with an eye towards accessibility. The risk is to slowly lose the accessibility of your site by way of non-accessible content, templates and applications. Every modification to your site, no matter how small, needs to be tested for accessibility.

You can’t imagine how easy is to transform an accessible site into an inaccessible one.