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.

From Education & Outreach

Revision as of 15:12, 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:

• Research legal and other requirements for accessibility of your web products.
• Research accessibility standards and guidelines for your type of web product.
• Develop internal policies for accessibility.
• Budget and schedule to include people with disabilities as collaborators in your project.
• Develop accessibility knowledge and skills through training and hiring, as appropriate.
• Evaluate the accessibility support in design and development tools you are considering for the project. For example, how well does the authoring tools you are considering support ATAG? How well does the UI tool kits you are considering support WAI-ARIA?

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 Web Projects for Better, Easier Accessibility
  • includes section on How Involving Users Early Helps

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

• Improving the Accessibility of Your Website
  • includes sections on Evaluating to Identify the Issues, Optimizing Your Retrofitting, Prioritizing the Repairs

• Implementation Plan for Web Accessibility
  • Has sections on Conduct Initial Assessment and Develop Accessible Website]
  • Is from 2002 - iss it still point-to-able, or too old? how much work to update it?

• B-Case, Financial Factors, Decreasing Costs
  • has section on "Incorporating accessibility from the beginning"

• Designing for Inclusion
  • doesn't have info on design process, but some people might come looking here for it

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

other inputs

• Text EOWG is welcome to use:
  • Incorporating Accessibility Early and Throughout
  • Evaluate Throughout Design
  • Evaluating for Accessibility, e.g., Design Walkthroughs
• email from Phill Jenkins includes some considerations early
  • 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.
• Cost Savings of Early Accessibility
• Bringing Accessibility into the Development Process
• Accessibility_Responsibility_Breakdown draft

Misc Notes

• @@ comment template {name}

Title ideas

• Accessibility Early, Accessibility Often (play off RERO)
• Accessibility Early in Process
• Address Accessibility Early
• Accessibility Now.