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 "Eval in process"

From Education & Outreach
Jump to: navigation, search
(Do we want to develop a new document, or do existing documents cover it sufficiently?)
(If new document, what should be the scope?)
Line 160: Line 160:
<li>A comprehensive approach seems best to me, but we should be conscious (and vigilant) about length and scope creep. <span style="color: #808080;">{Sharron}</span></li>
<li>A comprehensive approach seems best to me, but we should be conscious (and vigilant) about length and scope creep. <span style="color: #808080;">{Sharron}</span></li>
<li>A broad approach addressing where accessibility fits through the project, i.e., before, during, after but careful about length and style.  It should act as guidance to the valuable other information already available.<span style="color: #808080;">{Vicki}</span></li>
<li>...comment <span style="color: #808080;">{name}</span></li>
<li>...comment <span style="color: #808080;">{name}</span></li>

Revision as of 19:17, 6 December 2012

Nav: EOWG wiki main page

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


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:

Technical specifications

In drafting the technical specifications, once the standard and level of conformance is agreed upon, this may need to be documented in some or all of the following areas:

  • software specifications
  • design specifications
  • functional design specifications


If accessibility is only addressed late in design, it can be very costly to make required design changes. Retrofitting sites can be a long process. Therefore, include accessibility into the budget at the start of the project.

  • 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 organization
  • Budget for training and/or hiring in order to develop accessibility knowledge and skills

Quality Plan

Iteratively test for accessibility throughout the development process

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.

Evaluate Accessible Design

Effective evaluation during the design period can include:

  • Establishing clear requirements for the expected accessibility conformance level
  • Involvement in initial planning meetings for the site
  • Agreeing on a review schedule during the development process
  • 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.

If content is created with accessibility in mind, all users will be included, for example,

  • if audio content, such as videos with voices and sounds, contain captions or transcripts, this will enable people with auditory disabilities to access the information
  • if navigation mechanisms and page layouts are simple, they are much easier to understand and use by persons with cognitive disabilities
  • if sufficient time is given to respond or to complete a task, such as to fill out an online form, this will ensure that persons with physical disabilities are not time-barred
  • if websites offer alternative means of communication, such as including e-mail and feedback forms, this will ensure that persons with speech disabilities are not confined to contact by phone and can, therefore, interact
  • if text, images, and page layouts can be resized, this will ensure that persons with visual impairment can also benefit and access the information

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

More Information

{@@link to some of the resources listed under #Current_related_WAI_information ?}

Analysis & Notes

Comment template: @@ comment {name}

Open issues

...comment {name}

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

Existing documents listed below

  • 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}
  • Agree with the above approach of Sharron{Vicki}
  • ...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}
  • A broad approach addressing where accessibility fits through the project, i.e., before, during, after but careful about length and style. It should act as guidance to the valuable other information already available.{Vicki}
  • ...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?

current related material in other documents listed below
Would some of the information in other documents move to this page, and we would delete it on those pages and point to it here? Or would it be handle differently?

  • My tendency is to integrate and reduce the number of documents, but related documents will have to be reviewed and decided as this one develops.{Sharron}


  • Convince readers of the benefits of addressing accessibility early and throughout the design & development process -- and provide them guidance
  • Have a place to point to from WCAG-EM (and other docs that talk about evaluating existing sites) that says do it early & do it often

See also Eval Analysis for use cases for this and related documents

Current related WAI information

  • Involving Users in Evaluating Web Accessibility
    • says things like "including them throughout the development process to complete sample tasks on prototypes so you can see how the different aspects of the design and coding could be improved"
  • Designing for Inclusion
    • doesn't have info on design process, but some people might come looking here for it; therefore, we might want to add pointers to related information in the "See also" sections

(Outreach Planning page has info on dated-ness of some docs.)

other inputs

Misc Notes

  • @@ comment template {name}

Title ideas

  • Accessibility Early, Accessibility Often (play off RERO)
  • Accessibility Early in Process
  • Address Accessibility Early
  • Accessibility Now.
  • Accessibility First
  • Plan for Accessibility Early
  • Accessibility Early
  • Accessibility in Development Early
  • Accessibility in Web Projects
  • Early Accessibility
  • Build Accessibility Early into Web Projects
  • Start with Accessibility


Thanks to:

  • Vicki Menezes Miller for significant drafting and editing of several sections
  • Ian Pouncey for editing and drafting some sections
  • Shawn Henry for working on the framework and commenting on drafts
  • Sharron Rush for commenting on open issues
  • Suzette Keith for some initial ideas