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.


Eval in process

From Education & Outreach

(Difference between revisions)
Jump to: navigation, search
(→Pre-Development Checklist)
(→[Draft] Address Accessibility Early)
Line 8: Line 8:
=[Draft] Address Accessibility Early=
=[Draft] Address Accessibility Early=
-
 
-
<span style="background-color: yellow;">''{Shawn put some text here just to get something started &mdash; but is not at all attached to it. Please feel free to totally rewrite it, edit significantly, etc.}''</span>
 
==Introduction==
==Introduction==

Revision as of 16:54, 30 November 2012

Nav: EOWG wiki main page

Contents


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

In the initiation phase of a project, there are several accessibility considerations the role of the Project Manager needs to address. For example:

Legal requirements

There may be legal requirements of the country which must be taken into consideration. At the same time, in order to sustain accessibility, an internal policy and an implementation plan should be developed.

Technical specifications

At the start of a project, in order to ensure accessibility of the product, the software specifications, the technical solution and the authoring tools should be considered.

Budget

If accessibility is only addressed late in design, it can be very http://www.w3.org/WAI/bcase/fin#decreasing 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
  • 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.

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

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

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}
  • ...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?

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}

Purpose

  • 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"

(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



Retrieved from "http://www.w3.org/WAI/EO/wiki/Eval_in_process"
Personal tools