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.

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.

[Draft] Address Accessibility Early

{Shawn put some text here just to get something started — but is not at all attached to it. Please feel free to totally rewrite it, edit significantly, etc.}

Introduction

When accessibility is considered early and throughout design, it can be seamlessly and elegantly integrated with overall design. Incorporating accessibility early decreases the time and money to design accessible web products and increases the positive impact that accessibility can have on design overall.

If accessibility is only addressed late in design, it can be very costly to make required design changes. Furthermore, accessibility "tacked on" at the end is usually much less effective for people with disabilities and less beneficial for others. 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 Planning Stage

Even before the design process begins, there are accessibility considerations you can address. For example:

Research legal and other requirements for accessibility of your web products.

Design Stage

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

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.