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.

Difference between revisions of "Start with Accessibility"

From Education & Outreach
Jump to: navigation, search
m (Discovery & Analysis)
m (Discovery & Analysis)
Line 53: Line 53:
* [ Ensure that everyone knows what accessibility means and that accessibility is a requirement], in particular, stakeholders, even if an official policy is not yet available
* [ Ensure that everyone knows what accessibility means and that accessibility is a requirement], in particular, stakeholders, even if an official policy is not yet available
* [ Evaluate the accessibility support in design and development tools] for the project
* [ Evaluate the accessibility support in design and development tools] for the project
===<span style="color:#808080;">EOWG notes on @@section</span>===
<div style="color:#808080;">
* @@comment {name}
==Planning Stage==
==Planning Stage==

Revision as of 15:43, 11 February 2013

Nav: EOWG wiki main page

Previous versions and notes: Eval in process

Start with Accessibility: How to Integrate It into Web Projects


Consider accessibility early and throughout the design and development process for seamless and elegant integration into web projects.

Incorporating accessibility from the start of a project increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility when it is addressed much later. 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. In addition, this approach - i.e. to address accessibility later and at the end of a project - can result in additional costs.

When accessibility is considered for the first time in a project, some additional steps to ensure accessibility are required, but most of the planning, design, checking and implementation will fit easily into the processes already in place. For example, instead of evaluating accessibility separately, integrate accessibility checks iteratively within the current testing and quality assurance (QA) processes. That's just one example of how integrating accessibility applies through a project. Best practices in web design indicate that it is important to follow a systematic design process and that accessibility issues are addressed at each stage.

This resource addresses how and where accessibility fits through the lifecycle of a web project.

EOWG notes on @@section

  • @@comment {name}

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 (initiation, planning, design, development, closure).

In the initiation stage, there are several accessibility considerations that need to be addressed in the project document and which may require some research, for example, are there legal requirements which should be considered, what is the understanding of accessibility within the organization from the level of stakeholders through the team, is training required, are the tools used accessible?

Legal requirements

There may be legal requirements of the country which should be taken into consideration. Many organizations use WCAG as a target for accessibility. For example, an organization may set its target to meet WCAG 2.0 Level A or Level AA success criteria. Developing an accessibility policy is a good way to clarify and communicate its target.

The following resources provide information on:

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

Discovery & Analysis

Some analysis of the level of understanding of accessibility within the organization is necessary: stakeholders, designers, developers, content providers are all concerned. A frequent cause of accessibility barriers is simply the lack of awareness on the subject. Assess the level of accessibility knowledge and if there is need to provide training for the content providers, designers and developers. This is an initial investment but once staff understand the requirements for accessible products, then, accessibility becomes part of the required standards and is no longer considered as a separate additional requirement and investment.

The authoring tools, the software specifications and the technical solutions should also be considered. Estimate resources required to address the needs identified in the initial assessment. Include staff training, software purchase or replacement, testing, retrofitting of site, monitoring of site, etc., as needed.

The following resources provide some guidance on the essential aspects pertinent to accessibility requirements gathering:

EOWG notes on @@section

  • @@comment {name}

Planning Stage

It is important to recognize that implementing accessibility is not only a concern for developers, but for the whole team, which includes designers and content providers. People who are knowledgeable about accessibility must work together throughout the project life cycle to understand relationships between design, content and functionality which ensures that a team collectively develops an accessible, usable, and quality product. If the knowledge of accessibility needs to be introduced, plan a budget for training and testing so that this knowledge can be incorporated into the team and standards of the organization.

Including accessibility at the start in the establishment of the technical specifications is necessary. Choosing accessible technologies makes the process much more intrinsically accessible.

Technical specifications

In drafting the technical specifications, the criteria for an accessible product (based on the standard and level of conformance) will need to be documented in some or all of the following areas:

  • Software specifications
  • Design specifications
  • Functional design specifications
  • Developer's checklist
  • User acceptance criteria


Include accessibility into the budget at the start of the project. Incorporating accessibility from the beginning of a website development or redesign process is almost always significantly easier, less expensive, and more effective than making accessibility improvements to an existing site later as a separate project. When accessibility is only addressed late in design, it can be very costly to make required design changes. Furthermore, retrofitting a site can be a long process.

  • Plan a budget and schedule to include people with disabilities as collaborators in the project
  • Budget for testing accessibility in case resources are not available within the team
  • Budget for training and/or hiring in order to develop accessibility knowledge and skills noting that training is required for content providers, designers and developers

Quality Plan

Ensure iterative testing in the quality assurance plan by including specific accessibility checks within the quality assurance control processes. This is where the technical specifications come to play. In testing for accessibility, refer to the technical specifications of the project in order to ensure that compliance is obtained at each level. Again, start early.

Effective evaluation includes:

  • Establishing clear requirements on the expected accessibility conformance level
  • Ensuring a common understanding among team members (designers, developers, content providers)
  • Involve designers, editors and developers in initial planning meetings for the site
  • Agreeing on a review schedule during the design and development processes
  • Providing information on evaluation approaches so that both designers, content providers and developers can perform preliminary reviews on their own

There are a variety of methods to test for accessibility with varying levels of detail:

  • Browsers often have an Add on for a quick accessibility check
  • Software tools are available
  • An in-house checklist can be a helpful aide for repeated projects, similarly a Compliance Matrix
  • The service of an external company or expert can be initially very informative
  • The Web Accessibility Preliminary Evaluation provides detailed guidance on how to check for accessibility

Whilst accessibility evaluation is performed with a combination of tools, services and experts, there are many benefits to evaluating with real people to learn how your website or web tool really works and to better understand accessibility issues.

Including users throughout the development process to complete sample tasks on prototypes can assist in understanding how the different aspects of the design and coding can be improved.

EOWG notes on @@section

  • @@comment {name}