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
(To Do)
m (To Do)
Line 202: Line 202:
* <span style="background:yellow;">Ian</span> to edit Development Stage sections <>
* <span style="background:yellow;">Ian</span> to edit Development Stage sections <>
* <span style="background:yellow;">Sharron</span> to add to Design Stage section <> ''(Sharron were you done with this, or do you have more ideas to add?)''
* <span style="background:yellow;">Sharron</span> to add to Design Stage section <> ''(Sharron were you done with this, or do you have more ideas to add?)''
* <span style="background:yellow;">Vicki</span> to consider Suzette's input in "Just some thoughts for consideration {Suzette}" ''(Vicki, did you already complete this? if so, would you add breif notes on how you addressed it and move it to the "Comments - Closed" section of this wiki page?)''
* <span style="background:yellow;">Vicki</span> to consider Suzette's input in "Just some thoughts for consideration {Suzette}" ''(Vicki, did you already complete this? if so, would you add breif notes on how you addressed it and move it to the "Comments - Closed" section of this wiki page?)'' <span style="background:yellow;">Response from Vicki</span>:  ''I read through the comments and replied some time in December that the comments appeared to be directed for group discussion and I think Suzette agreed with this.  For this reason, I did not make any changes.''
{<span style="background:yellow;">Response from Vicki</span>}:  ''I read through the comments and replied some time in December that the comments appeared to be directed for group discussion and I think Suzette agreed with this.  For this reason, I did not make any changes.''
* <span style="background:yellow;">EOWG</span> to comment on titles ideas <>
* <span style="background:yellow;">EOWG</span> to comment on titles ideas <>

Revision as of 21:18, 10 January 2013

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

This resource addresses how and where accessibility fits through the lifecycle of a web 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. Many organizations use WCAG as a target for accessibility. For example, an organization sets its target to meet WCAG 2.0 Level A and Level AA success criteria. Developing an accessibility policy is a good way to clarify and communicate your target.

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 is necessary in order to assess the level of accessibility within the organization. The authoring tools, the software specifications and the technical solutions should all be considered. A frequent cause of accessibility barriers is simply that web developers are not aware that they should make websites accessible.

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

  • Evaluate the accessibility support in design and development tools for the project
  • Assess the level of accessibility knowledge and if there is need to provide training
  • Ensure that everyone knows that accessibility is a requirement, in particular, stakeholders, even if an official policy is not yet available
  • Estimate resources required to address the needs identified in the initial assessment. Include software replacement, staff training, retrofitting of site, monitoring of site, etc., as needed.

Technical specifications

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

  • Software specifications
  • Design specifications
  • Functional design specifications
  • User acceptance criteria


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

Design Stage

Designers are responsible for the design and user interface of web pages and applications. It is important to recognize that accessibility is not only an issue for developers and programmers. People who are knowledgeable about accessibility must work together with designers throughout the project life cycle to understand relationships that help the team collectively develop an accessible, usable, and quality product.

Choosing accessible technologies to begin with makes the process much more intrinsically accessible. Evaluating early design prototypes helps to validate design aspects that work well, and to 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 to accessibility standards and best practices.

Evaluate Accessible Design

Effective evaluation during the design period can include:

  • Establishing clear requirements for the expected accessibility conformance level
  • Ensuring common understanding among team members
  • 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
  • alerts for planned dynamic interactions

At this early stage, accessible design elements can be built into the project to allow stakeholders to understand from the start where and why changes are introduced.

Content Creation

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

  1. Address Accessibility Early

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 useful at the product requirements and design stage.

{I think this is too specific and we don't want to be this prescriptive — Shawn.
If we do keep a list, then need to separate technical aspects from content aspects as usually different groups — Andrew}
{Hopefully dealt with in latest changes — Ian}

The items on the checklist will vary depending on the project, so during the planning stage give some time to creating your list. It does not need to be exhaustive, as it is not possible to anticipate all possibilities, but should aim to cover the mostly likely points.

Before you start development you should make sure that all of the questions on your checklist have been answered.

An example list might include:

- 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

A great place to start when designing your project's checklist is WCAG 2.0 Appendix B: Checklist. If you are confident that you have all of the information you need to meet all of it's points, or a list of the answers you need to ask, then your checklist is complete.

The Development Cycle

{This section needs editing to be less specific and prescriptive. Could present the steps as an example.}
{Hopefully dealt with in latest changes — Ian}

{This section doesn't seem to address the typical information site where the templates are developed for use within a CMS along with most scripting and the CSS, and then the content is added — Andrew}
{Hopefully dealt with in latest changes — Ian}

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 users find them.

As with the pre-development checklist there is no single correct development cycle, and will vary based on the feature being implemented, environments available for testing (including desktop and mobile devices), and other factors.

Here is an example development cycle. Not all of these steps would need to followed on every iteration or for every feature, but all of the testing points in your development cycle 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

Some times you won't have all of the content, for example when developing a template for a CMS. In that case follow your development cycle as normal, but when you come to add the content modify it to only apply to the markup output, and not to interactions.

Quality Assurance

If possible it is a good idea to test iterations of your product with real users during the development phase. See the #Quality_Plan section for more information.

Quality Plan

{Making this a separate section, as developers are not usually (and should not primarily be) responsible for QA — Ian}

Iteratively test for accessibility throughout the development process.

  • Include accessibility testing stages in the quality assurance plan
    • Web Accessibility Preliminary Evaluation provides detailed guidance on how to check accessibility
    • Consider developing a Compliance Matrix

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.

Content Creation

{Andrew to add some notes here - see also earlier draft for ideas}

Project Closure

In the project sign-off, include the sign-off for accessibility conformance and celebrate this as an achievement in the project launch.

Document the lessons learned in implementing accessibility. This can be a very useful source of information in the post project phase and for other projects within the Organization.

Post Project

In order to maintain a level of conformance, a post project plan should be in place to ensure that

  • regular checks are performed for continued accessibility
  • all aspects of implementation plan for effectiveness are periodically reviewed
  • new barriers are not introduced when redesigns or updates are planned
  • accessibility knowledge of staff is a continued requirement (offer repeated training opportunities as staff and responsibilities change)

More Information

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

Analysis & Notes

Comment template: @@ comment {name}

To Do

Open issues & Comments

...comment {name}

What to do with the related material in other documents?

OPEN: Need to look more closely at the content of this new page and the content that we currently have elsewhere to decide what to do with it. (Vicki has incorporated some of it already.)

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}
  • Where information in other documents is particularly relevant, introduce passages (with some minor modifications) into this document and point to the other relevant documents through links within the text. I wouldn't do away with the other documents unless something is totally out of date.{Vicki}

Just some thoughts for consideration {Suzette}

Vicky and Ian have made a good start on an important topic. It is good to have clearly defined roles and stages and references out to appropriate documents that will support getting accessibility in at the earlier planning stages. Design process: My comments mainly relate to how we conceptualise the design processes being applied to web design and development.

I think it would help if we could establish an agreed process strategy. Some people may still mash a website overnight but it is hard to help people improve quality when they are not being systematic – unless they are really, really good!

I think we should broadly assume and establish that designing today’s sophisticated websites demands a relatively formal multi-stage design process. This will allow accessibility issues to be addressed early and at each stage, and is why we are writing this document.


Essential to set the tone – the two key points to sell the benefits of early intervention AND that this document establishes a strategy for early and continuing engagement.

This is a good place to establish something about having a systematic process eg: “Best practice in web design shows that it is important to follow a systematic design process, and for accessibility issues to be addressed at each stage”

Project initiation stage:

This seems to be linked to the Project Manager and picks up on the legal case – although it could equally well pick up on the pages on the Business Case. The output of this stage appears to be a policy document on accessibility. Stage naming: We’ve named this stage Project Initiation but then in the 1st paragraph the stages are defined as definition, planning, development and closure. It would be neat to correlate these stages in the text description with our chosen headings. My suggestion for discussion is: Project planning, Design, Development. See comments later about Quality plan, Project closure and post project which are also planning issues

Design Stage:

Linked to role of Designer. Good to bring in aesthetic design and content creation, and essential to talk about mock-ups and prototype testing, and opportunities to talk to representative disabled people and accessibility experts.

Maybe also consider ‘how’ the content is delivered - especially in relation to multi-media and interactive elements. Where else can you consider needs of low literacy, print impairments as well as visual impairment, and keyboard only use?

Development stage:

Linked to role of Developer – some confusion here about scope and timing of this role.

Alternatives to the waterfall model of design process: Some design processes like Agile are much more comfortable with the expectation of parallel development. Maybe we can establish that design and development stages are fully interlinked. Maybe also need to establish the relationship with the content creators, I’m sure the PR and marketing people start to get involved especially in medium to large government sites or media heavy commercial sites.

Check and test lists: Pre-development checklist and the development cycle list both seem too detailed. Maybe just have one and go higher level eg Content, style, design, features, navigation. Can then point to our other stuff on evaluation such as the Preliminary Evaluation.

Preliminary Evaluation – I’m not sure that we have this group fully in mind. They are going to have to deal with some quite complex decisions which we have currently excluded as too difficult to describe simply. Good also to repeat about testing the later stage mock-ups and prototypes, and simulations as part of development not Quality testing.

Final stages:

Quality plan, Project Closure and Post project. Quality is iterative but otherwise these are not about ‘early’ as such, but belong with the project manager and could be dealt with in the planning/initiation stage.

Review and Comments {Wayne 14 Dec}

This is excellent for the need: a high level overview of fully integrated accessibility at initial stages.

I was confused by the sentence: "Some analysis is necessary in order to assess the level of accessibility within the organization." To what organizational entity does accessibility refer?

I do think the check lists are essential, but I'm not sure how to address Shawn's issue with prescription. Perhaps these check lists need be introduced as a getting contrite phase of design. When you are at phase X you should consider issues like ... [check list]. It might be made clear that this list is neither exhaustive nor mandatory. However, omission of lists makes the document to abstract and vague.

I don't understand refactor in this context.

Comments - Closed

[Closed] In the "Introduction", second paragraph, I would like to suggest removing the following sentences:

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

I think a shorter introduction with focus on guidance in the framework of a web project is more likely to grasp attention. {Vicki}

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

Decision: Develop new document.

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}

[closed] If new document, what should be the scope?

Decision: Broad scope - accessibility early & throughout.

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., at the start, during, after but careful about length and style. It should act as guidance to the valuable other information already available.{Vicki}
  • ...comment {name}

[closed] If new document, how long and how detailed?

Decision: Keep as short. Not detailed. Link to existing material elsewhere, or that might developed elsewhere.

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}
  • Not a lengthy document, if possible. Keep it to the point and reference to the other valuable information already available under WAI. Later, once webplatform docs has some tips and trick, especially under "Development Stage", we could link there{Vicki}
  • ...comment {name}


  • 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"
    • [done] There's a pointer under "Quality Plan" to the above link. I could expand on the wording as suggested.{Vicki}
  • Improving the Accessibility of Your Website
    • includes sections on Evaluating to Identify the Issues, Optimizing Your Retrofitting, Prioritizing the Repairs
    • [done] Yes - some points especially from "Clarifying requirements" (could be used 'Discovery & Analysis', /DONE/ "Validating solutions" (second paragraph could be inserted under 'Quality Plan', /DONE/ "Next: Strategic Planning" (parts could be used under "Legal requirements") ({Vicki}
    • [done] Under "Setting the target", the first paragraph could be used under "Legal requirements" and the first sentence of the last paragraph of this section ({Vicki}
  • Implementation Plan for Web Accessibility
    • Has sections on Conduct Initial Assessment and Develop Accessible Website
    • Is from 2002 - is it still point-to-able, or too old? how much work to update it?
    • [OPEN] Also interesting points under "Develop Accessible Website" which could possibly go under "Development stage" with some minor modifications ({Vicki}
    • [done] A paragraph to close with the points from "Monitor Website Accessibility" could be added at the end of this document({Vicki}
    • There's good stuff there. I could try to integrate /DONE/some points briefly into this document. Wouldn't move anything out of the original since I think it is all still quite relevant. Perhaps, some minor updating but the document is a very good source of information for anyone starting out.{Vicki}
  • B-Case, Financial Factors, Decreasing Costs
    • has section on "Incorporating accessibility from the beginning"
    • [done] Yes, this sentence can be slightly modified and added under Budget {Vicki}
    • Interesting paragraph to add under "Design" on "Addressing accessibility and mobile together" {Vicki}
  • 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

comment template: summary - Comment {name}

  • Start with Accessibility
    • like! - I think this is perfect: simple and complete. A sub-title like "How to and What to Address" might help {Wayne}
    • like - "Start" is good - supports the idea that accessibility is fundamental and leads to innovation! might also get SEO for searches like "getting started with accessibility" {Shawn}
    • like - Clear and catchy. I agree with Wayne that a sub-title might add to it {Anna Belle}
  • Build Accessibility Early into Web Projects
    • like- kinda like "build into" {Shawn}
    • like- because it sounds "solid" and "serious" and contains the words "web projects"{Vicki}
    • like- because it sounds clear and good. {Sylvie}
    • like- to the point. {Anna Belle}
  • Integrating Accessibility in Your Web Project
    • like- "integrating" is nice, saying it's not a separate thing {Shawn}
    • best- like for the same previous reasons "solid", "serious", and also since the document (now) encompasses a project framework, I like the idea of having the words "web project" in the title. This would be my favorite {Vicki}
    • like - this too, because it sounds positive. I like both above better than the following proposals. {Sylvie}
  • Accessibility Early in the Process
    • ...
  • Address Accessibility Early
    • ...
  • Early Accessibility
    • no - this one doesn't do anything for me. {Shawn}
    • no - sounds more like a history of accessibility. {Anna Belle}
  • Accessibility Now
    • ...
  • Accessibility First
    • ...
  • Plan for Accessibility Early
    • caution - Wonder if developers and designers would realize this applies to them, or think it's targeted to managers {Shawn}
  • Accessibility Early
    • ...
  • Accessibility in Development Early
    • caution - maybe designers & content creators wouldn't think this applies to them? {Shawn}
  • Accessibility in Web Projects
    • caution - maybe too broad {Shawn}
    • okay - similar to previously mentioned, the focus being accessibility on projects {Vicki}
  • Accessibility Early, Accessibility Often (play off RERO)
    • caution - probably most people won't get the RERO play. without that, I think "often" makes it sound like a lot of work {Shawn}
  • How Accessibility Planning Works
    • ...


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 and detailed review and comment on December draft