The 2008 web project managers’ census

In April the webzine A List Apart published the findings from a survey that – for the second year – tries to highlight patterns and behaviours among web job titles.

Last year I isolated some information regarding web project managers [in Italian] so it’s quite interesting to compare this hypothesis with the new findings.

There are several confirmations. A web project manager:

  • follows an educational path that usually starts in the programming field
  • usually works for small or mid-sized businesses
  • it’s 30 to 40 years old
  • works for a corporate more often than as a freelance

Let’s have a closer look at the findings.  Some questions are different from the 2008 so a direct comparison is only approximate.

Corporate versus freelance

Job title by workplace (2008)

This analysis was not included in the 2007 survey and it represents the percentage of web project managers that work for corporates rather than as freelances. Compared to the other job titles, a web project manager more often works as for a corporate rather than as a freelance.

This is not an unexpected finding and I’ve already answered to a similar question in the FAQ (Does the web project manager work for a company or is he a freelance?): in most cases a web project manager works for the company he manages projects for because the quality of the project depends on reciprocal people acquaintance. This approach is not profitable if the web project manager works as a freelance.

There are, however, situations in which the web project manager is a freelance; it works for one or more periods of time (usually semesters) in order to help the company in improving project management skills.

Percentage of web project managers

Job title (2007)

Job title (2008)

Looking at the 2 years there are not significant differences compared to the other job titles.

Quite impressive the “other” category, more than 1/4 of the total.

Job title distribution by organization type

Job title distribution by organization type (2007)

Job title distribution by organization type (2008)

The table shows the percentage of web project managers employed in different organizations (note that some categories have been merged with respect to last year).

The majority of web project managers (8.4%) work in small organizations.  This confirms a trend:  a web project manager most of the time works for a startup, an organization where frequent deployments and strict timing require a professional in charge for the achivement of the objectives.

Job title distribution by age group

Job title distribution by age group (2007)

Job title distribution by age group (2008)

There are not many differences between the two years. One is not born web project manager, but becomes a web project manager after some years of experience (usually when she is 30/35 years old).

Gender distribution by job title

Gender distribution by job title (2007)

Gender distribution by job title (2008)
There is a small increment regarding the role of females in web project management, and the same increment is shared by all the job titles, maybe an indication of the improved visibility given this year to the survey.

Percentage of job-title holders who earn salaries of $100k+

Percentage of job title holders who earns salary of 1000k (2007)

Percentage of job title holders who earns salary of 1000k (2008)

The trend of last year is somehow confirmed.

Perceived relevance of education by job title

Perceived relevance of education by job title (2007)

Perceived relevance of education by job title (2008)

There are some changes regarding the perceived relevance of education.

The fact that all job titles experienced an increase in satisfaction can be considered a sign that the question was better understood by participants than last year. In general, however, a bit more than 50% indicated as relevant their education, suggesting that there is room for improvement.

Job satisfaction by job title

Job satisfaction by job title (2007)

Job satisfaction by job title (2008)

The percentages increase a lot with respect of last year: maybe this is another case where the question was better understood.

Compared to other job titles, however, web project managers’ satisfaction increase in less proportion, leaving the top of the list.

It’s quite difficult to explain the reasons considering that the variation happened in just a year. Maybe the web project manager’s role, in some context, can’t find the room that it deserves.

But, on the other hand, it’s high time for the web project management to grow from a discipline that confine all the responsibilities to the project manager towards a source of leadership and vision.

Prelevance of blogging by job title

Prelevance of blogging by job title (2007)

Prelevance of blogging by job title (2008)

The web project manager is the tail-end when it comes to writing for a blog.

As suggested last year, the reason can be that it’s difficult to write regarding a job strictly related to human interactions and with many facets. Difficult, but not impossible. A pity.

Participation in formal training by job title

Perceived relevance of education by job title (2007)

Perceived relevance of education by job title (2008)

The web project manager is one of the job title holders that more take part in formal training. The percentage is close to the ones of professionals that are used to a constant training, such us usability and accessibility consultants.

This result can be explained by the heterogeneity of skills (managerial and technical) required for a web project manager.

Perceived skill gaps

Perceived back end skill gaps by job title (2007)

Perceived back end skill gaps by job title (2008)

Concerning back-end programming, less that 17% states to have some skill gaps. This result, compared to the other skill gaps graphs, confirms a trend: one becomes web project manager usually starting to work in areas close to programming, rather then design or marketing.

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.