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 h1-h6 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.