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
(Purpose)
(Analysis & Notes)
Line 74: Line 74:
  
 
'''''Comment template:''''' @@ comment <span style="color: #808080;">{name}</span>
 
'''''Comment template:''''' @@ comment <span style="color: #808080;">{name}</span>
 +
 +
==Open issues==
 +
* [open] Would this page mostly talk about evaluation? Or more broadly including accessibility early?
 +
* [open] What about the related information already on other WAI pages (listed below)? Would some of that move to this page? Or would it be handle differently?
  
 
==Purpose==
 
==Purpose==

Revision as of 15:09, 20 November 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.

[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:

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.

... design walkthroughs ...
... evaluating information architecture, wireframes, colour schemes, visual mock-ups ...

Development Stage

Development workflow

Pre-development

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

Development cycle

  1. Markup content
  2. Test simple keyboard (tab and return keys) interaction without CSS
  3. Add CSS
  4. Test with text at 200%
  5. Test with screen reader / keyboard
  6. Add JavaScript enhancement
  7. Test with screen reader / keyboard

Re-factor and repeat

Content Creation

@@

More Information

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




Analysis & Notes

Comment template: @@ comment {name}

Open issues

  • [open] Would this page mostly talk about evaluation? Or more broadly including accessibility early?
  • [open] What about the related information already on other WAI pages (listed below)? Would some of that move to this page? Or would it be handle differently?

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.