Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Content which is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility. Accessible content requires little effort and increases usability at large. Websites and web tools that are designed for people with a broad range of abilities will benefit everyone, including people without disabilities.

+

Content which is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility. Accessible content requires little effort and increases usability at large. Websites and web tools that are designed for people with a broad range of abilities will benefit everyone, including people without disabilities.

+

+

<span style="color: #808080;">{Maybe flip this around to be a list of examples of what TO DO instead of what not to do? &mdash;Shawn}</span>

If content is not created with accessibility in mind, it can create real barriers to groups of users.

If content is not created with accessibility in mind, it can create real barriers to groups of users.

This page explores the possibility of providing additional guidance on evaluating early and throughout the design & development process -- or more broadly on including accessibility early.#Analysis_&_Notes at the end of the page includes open issues.
Archived info from previous drafts is at Accessibility Early Archive.

[Draft] Address Accessibility Early

Introduction

Consider accessibility early and throughout the design process for seamless and elegant integration into web and application development projects. Incorporating accessibility from the start increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility.

Avoid situations in which accessibility is considered only at the end of the development process. This often results in awkward, "tacked on" accessibility features that are much less effective for people with disabilities and less beneficial overall. As an example, consider a building that is architecturally planned for accessibility from the beginning and has a wheelchair-accessible entrance that fits with the building design aesthetically and practically. Compare that to a building with a ramp added on after the building was already designed and the ramp looks awkward and is less useful to all. Incorporating accessibility from the beginning of a design project is significantly easier, more effective, and less expensive than waiting until later in the project.

It is almost always better to integrate accessibility considerations throughout your existing processes, rather than addressing accessibility separately. While you may need some additional steps for accessibility, most of it fits nicely within what you're already doing. For example, instead of evaluating accessibility separately, integrate accessibility checks where they fit best within your current testing and quality assurance (QA) processes. That's just one example; integrating accessibility applies all the way through a project.

Project Initiation Stage

The role of the Project Manager is vital to the success of an accessible web project. At the very start, the Project Manager needs to ensure that every stakeholder understands their role and the requirements at every stage of the project (definition, planning, development, closure).

In the initiation phase, there are several accessibility considerations that need to be addressed in the project document and which may require some research as regards legal requirements, the understanding of accessibility within the organization, the tools which are used and so forth.

Legal requirements

There may be legal requirements of the country which should be taken into consideration.
The following resources provide information on:

At the same time, in order to enable continuity of the accessible site or application, an internal policy and an implementation plan should be developed. The following pages provide guidance on how to:

Discovery & Analysis

Some analysis of the environment is necessary in order to assess the support available in the organization to maintain the level of accessibility. The authoring tools, the software specifications and the technical solution should all be considered. The following resources provide some guidance on the essential aspects pertinent to accessibility requirements gathering:

Design Stage

Designers are responsible for the design and user interface of web pages. Specifications need to be identified early in the project to include conformance to accessibility.

Evaluating early design prototypes helps to validate design aspects that work well, and find potential accessibility barriers while it is still relatively easy and inexpensive to fix them.

In the role of Web Designer, a number of tasks associated with quality control of the design, e.g. graphical and user interfaces, navigational elements, contextual changes and other general design elements of content pages are of relevance and should be checked for conformance.

Providing information on evaluation approaches so that the developers can at least do preliminary reviews on their own

Initial Mock-ups

Even before coding begins, wireframes or visual mock-ups can be evaluated through early screening by performing checks on

information architecture

color scheme

contrast of colors

At this early stage, accessible design elements can be built into the project and stakeholders will understand from the start where and why changes are introduced.

Development Stage

The implementation is the last part of the process of building a site or application, but that does not mean that developers should not be involved early. They often have a broad knowledge of usability and accessibility issues as everything from the product owner's and content writer's requirements to the user experience designer's vision of the product are filtered through them.

Make sure to use developers to spot issues that would normally only be caught at the development stage as early as possible.

Pre-Development Checklist

Checklists often work well for the developer mindset, and can be checked at the product requirements and design stage.

{I think this is too specific and we don't want to be this prescriptive —Shawn}
Ensure requirements specify:

exact foreground and background colours

tab order

focus handling

focus styles

alt text for images

additional hidden content for AT where required

placeholder / summary / title text where required

error message text and placement where required

simple /clear text in buttons, titles and content

[Create list from the various sources we have gathered]

The Development Cycle

{This section needs editing to be less specific and prescriptive. Could present the steps as an example.}

The development stage can make or break the accessibility of a project. A good development workflow with a focus on accessibility can find problems before the QA phase, or worse, before the users find them.

Not all of these steps need to followed on every iteration or for every feature, but all of the testing points should be hit at least once for each release.

Markup content

Test simple keyboard (tab and return keys) interaction without CSS

Add CSS

Test with text increase 200%

Test with screen reader / keyboard

Add JavaScript enhancement

Test with screen reader / keyboard

Re-factor and repeat

Content Creation

Content which is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility. Accessible content requires little effort and increases usability at large. Websites and web tools that are designed for people with a broad range of abilities will benefit everyone, including people without disabilities.

{Maybe flip this around to be a list of examples of what TO DO instead of what not to do? —Shawn}

If content is not created with accessibility in mind, it can create real barriers to groups of users.
For example,

Audio content, such as videos with voices and sounds, without captions or transcripts will exclude people with auditory disabilities

Complex navigation mechanisms and page layouts will be difficult to understand and use by persons with cognitive disabilities

Insufficient time limits to respond or to complete tasks, such as to fill out online forms will present issues for persons with physical disabilities

Websites offering phone numbers as the only way to communicate with the organization will be problematic for persons with speech disabilities

Text, images, and page layouts that cannot be resized, or that lose information when resized will impact persons with visual impairment

Diversity of web users describes the types of disabilities, situations, problems and remedies to making content accessible.

Analysis & Notes

Open issues

Do we want to develop a new document, or do existing documents cover it sufficiently?

A new document that integrates key points from all of the others would be useful. However, it will only be so if we can keep it focused and quite clear. {Sharron}

...comment {name}

If new document, what should be the scope?

Should it focus only on evaluation throughout design & development process, or more broadly addressing including accessibility from early and throughout in all projects?

A comprehensive approach seems best to me, but we should be conscious (and vigilant) about length and scope creep. {Sharron}

...comment {name}

If new document, how long and how detailed?

Would we just give general guidance, or would we include specific steps and tasks that apply broadly?

I like the tendency that I am seeing in relating the content here to the roles that were developed earlier this year. I would caution against too much specificity unless we also commit to a schedule of updates and revisions to keep the information current and accurate{Sharron}

...comment {name}

If new document, what would we do with the current related material in other documents?

more: Yes, please add in some specifics about doing a design review and for accessibility prior to development of running or prototype code.Seems you have a step already listed:Design specification: We want an independent assessment of high level objects during early stage design planning. We can provide sample use cases, early page mock-ups, wireframes and simple prototypes.The other step is a "review of the technology choices" for accessibility support for the new/redesigned site. Such as user interface components (UI widgits) from jQuery, DoJo, and other JavaScript libraries and embedded video playersfor example that do (or don't) a good job of supporting accessibility.