Eval in process

From Education & Outreach

Nav: EOWG wiki main page 

Start with Accessibility latest draft

This page has previous version and notes

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.

Start with Accessibility: How to Integrate It into Web Projects

Introduction

Consider accessibility early and throughout the design and development process for seamless and elegant integration into web projects.

Incorporating accessibility from the start of a project increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility when it is addressed much later. 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. In addition, this approach - i.e. to address accessibility later and at the end of a project - can result in additional costs.

When accessibility is considered for the first time in a project, some additional steps to ensure accessibility are required, but most of the planning, design, checking and implementation will fit easily into the processes already in place. For example, instead of evaluating accessibility separately, integrate accessibility checks iteratively within the current testing and quality assurance (QA) processes. That's just one example of how integrating accessibility applies through a project. Best practices in web design indicate that it is important to follow a systematic design process and that accessibility issues are addressed at each stage.

This resource addresses how and where accessibility fits through the lifecycle of a web project.

Vicki - old version: 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. Best practices in web design indicate that it is important to follow a systematic design process and that accessibility issues are addressed at each stage.

It is almost always better to integrate accessibility considerations throughout existing processes, rather than addressing accessibility separately. While some additional steps for accessibility may be required, most of it fits nicely within what is already being done. For example, instead of evaluating accessibility separately, integrate accessibility checks where they fit best within the current testing and quality assurance (QA) processes. That's just one example of how 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 (initiation, planning, design, development, closure).

In the initiation stage, there are several accessibility considerations that need to be addressed in the project document and which may require some research, for example, are there legal requirements which should be considered, what is the understanding of accessibility within the organization from the level of stakeholders through the team, is training required, are the tools used accessible?

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 may set its target to meet WCAG 2.0 Level A or Level AA success criteria. Developing an accessibility policy is a good way to clarify and communicate its target.

The following resources provide information on:

At the same time, in order to enable continuity of an accessible site or application, an internal policy and a plan to implement the policy should be developed. The following resources provide guidance on how to:

Discovery & Analysis

Some analysis of the level of understanding of accessibility within the organization is necessary: stakeholders, designers, developers, content providers are all concerned. A frequent cause of accessibility barriers is simply the lack of awareness on the subject. Assess the level of accessibility knowledge and if there is need to provide training for the content providers, designers and developers. This is an initial investment but once staff understand the requirements for accessible products, then, accessibility becomes part of the required standards and is no longer considered as a separate additional requirement and investment.

The authoring tools, the software specifications and the technical solutions should also be considered. Estimate resources required to address the needs identified in the initial assessment. Include staff training, software purchase or replacement, testing, retrofitting of site, monitoring of site, etc., as needed.

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

Planning Stage

It is important to recognize that implementing accessibility is not only a concern for developers, but for the whole team, which includes designers and content providers. People who are knowledgeable about accessibility must work together throughout the project life cycle to understand relationships between design, content and functionality which ensures that a team collectively develops an accessible, usable, and quality product. If the knowledge of accessibility needs to be introduced, plan a budget for training and testing so that this knowledge can be incorporated into the team and standards of the organization.

Including accessibility at the start in the establishment of the technical specifications is necessary. Choosing accessible technologies makes the process much more intrinsically accessible.

Technical specifications

In drafting the technical specifications, the criteria for an accessible product (based on the standard and level of conformance) will need to be documented in some or all of the following areas:

  • Software specifications
  • Design specifications
  • Functional design specifications
  • Developer's checklist
  • User acceptance criteria

Budget

Include accessibility into the budget at the start of the project. 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 a site can be a long process.

  • 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 team
  • Budget for training and/or hiring in order to develop accessibility knowledge and skills noting that training is required for content providers, designers and developers

Quality Plan

Ensure iterative testing in the quality assurance plan by including specific accessibility checks within the quality assurance control processes. This is where the technical specifications come to play. In testing for accessibility, refer to the technical specifications of the project in order to ensure that compliance is obtained at each level. Again, start early.

Effective evaluation includes:

  • Establishing clear requirements on the expected accessibility conformance level
  • Ensuring a common understanding among team members (designers, developers, content providers)
  • Involve designers, editors and developers in initial planning meetings for the site
  • Agreeing on a review schedule during the design and development processes
  • Providing information on evaluation approaches so that both designers, content providers and developers can perform preliminary reviews on their own

There are a variety of methods to test for accessibility with varying levels of detail:

  • Browsers often have an Add on for a quick accessibility check
  • Software tools are available
  • An in-house checklist can be a helpful aide for repeated projects, similarly a Compliance Matrix
  • The service of an external company or expert can be initially very informative
  • The Web Accessibility Preliminary Evaluation provides detailed guidance on how to check for accessibility

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.

Design Stage

Designers are responsible for the graphic and user interface design of web pages and applications. Including accessibility at the start in the establishment of the technical specifications is required in order to ensure that colors, font sizes, interface design meets accessibility requirements. 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 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.

Initial Mock-ups

Even before coding begins, wireframes or visual mock-ups can be evaluated through early screening by performing checks on

  • Information architecture
  • Text alternatives for image content
  • Color scheme and contrast of colors
  • Alerts for planned dynamic interactions
  • Strategies in place to provide keyboard operation of interactions that are commonly mouse-dependent such as drop down menus, drag and drop mechanisms, and accordion controls.

At this early stage, accessible design elements can be built into the project thereby allowing 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

When content providers understand the requirements for accessible content, they play a vital role in ensuring that web pages contain information which is well structured with heading levels, links are clearly defined, tables are used for data and not presentation, captions or transcripts are provided for videos or audio recordings, error messages can easily be detected and interpreted.

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

{Andrew's quick starting notes}

[I think the draft below is too prescriptive and listy. I think we don't want to try to provide a list of what to do, instead, give a general idea of the type of things to do... {Shawn}]
Andrew: It wasn't meant to be presented as a list - was just a starting list of topics that maybe should be discussed under 'content'

{Vicki: I've added a sentence above "Diversity of web users". Is it sufficient, Shawn? BTW, perhaps, we indeed need a separate document on "Creating accessible content". Andrew: +1 to that idea!}

Considerations for content creators:

  • Textual content
    • provide a descriptive page title
    • ensure any linked text clearly identifies the destination page
    • use of headings to structure sections of text
    • use of lists
    • use of table headings (and summary attribute to describe table structure)
    • use alternative text to summarise image content or purpose
    • ...
  • @@technical images (graphs, diagrams, etc)
    • ensure color is not the only means of distinguishing aspects of the image
    • ensure suitabe contarst exist between forground and background and between adjacent image components
    • prepare a summary of the image content or purpose for use as alternative text
    • prepare detailed description to be linked to (might be table of data if image is graph)
  • audio & video content
    • ensure sufficient audio contrast between spoken words and background sound
    • for audio only files
      • prepare a transcript including non-spoken sounds
    • for video material:
      • prepare a transcript based around the script
      • organise for captioning
      • consider the requirement for audio description

References:

Development Stage

Whilst development and implementation are the last part of the process in the building of a site or application, developers need to be informed and involved early so that programming integrates accessibility from the start of the development cycle.

Developers usually have a broad knowledge of usability issues and when they understand accessibility issues, they are quick and keen to program accordingly frequently spotting and addressing issues early in the process. Including accessibility from the start of development translates into a requirement in the practice of developers.

Pre-Development Checklist

Checklists often work well for the developer mindset and are essential at the product requirements definition, the design stage and during development.


{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. During the planning stage, set aside sufficient time for creating such a list. It does not need to be exhaustive, but it should aim to cover the mostly likely points. This checklist can be very useful for re-use in future projects.

Before starting development, ensure that all of the questions on the checklist have been considered.

An example list might include:

  • Tab order
  • Focus handling and 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 the checklist being prepared can meet all of the points highlighted, then the checklist is complete.

Development Cyle

{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 will address accessibility issues immediately.

There is no single correct development cycle and will vary based on the feature being implemented, the 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 the development cycle should be checked 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

Sometimes not all of the content will be available, for example, when developing a template for a Content Management System (CMS). In that case, follow the development cycle as usual but when the content is added, modify it only by applying the markup output, and not the interactions.@@ Vicki: I find this paragraph a little puzzling.

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

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.

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

Post Project

In order to maintain a level of conformance, a post project monitoring 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

  • Ian to edit Development Stage sections <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Development_Stage>
  • Sharron to add to Design Stage section <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Design_Stage> (Sharron were you done with this, or do you have more ideas to add?)
  • Vicki 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?) Response from Vicki: I read through the comments - and thanks, Suzette, for your time and effort - and agreed (with Suzette) in December that the comments appeared to be directed for group discussion. For this reason, I did not embark on changes. However, this evening (10.01.2013) I have read through again, introduced one easy change, and indicated where a group discussion may be required
  • EOWG to comment on titles ideas <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Title_ideas>

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}

Dec 2012 comments

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.

Introduction

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”

Response from Vicki: Ok, thanks, Suzette, good point. I've included this in the introduction. Please check.

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

Response from Vicki: Thanks, Suzette, for this. I've modified somewhat. Please review the text.

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?

Response from Vicki: For group discussion. In my view, we should leave this quite high-level. How the content is delivered from the point of view of a designer could well be another document.

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.

Response from Vicki: For group discussion.

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.

Response from Vicki: Thanks, Suzette! I've moved the quality plan and reorganized info quite a bit. Please review.

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?

Response from Vicki: Wayne, thanks for the comment. I've modified the wording. Would you please check to see if it is more understandable now. Below is the old paragraph.

Old version: 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.

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.

Suggestion {Bim 11 Jan}

Under "Discovery & Analysis", the list of roles doesn't include content editors, but staff are mentioned under "Post Project". As new websites can have accessibility degraded within days of launch, might it be an idea to suggest that content editors' knowledge of accessibility should be an early consideration?

Response from Vicki: Thanks, Bim. I've modified the text somewhat. Please review.

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}

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

ideas for Start with Accessibility

  • 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}
    • [OPEN] I'm a little concerned there is too much overlap between the latest draft of this page ("Start with Accessibility") and the existing Implementation Plan. Do we really want two separate documents? If so, how will they be used differently? I think we should talk through this on an EOWG telecon...{Shawn}
  • 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}
  • 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}

See minutes from 11 Jan for title discussion.

  • Start with Accessibility: How to Integrate It into Web Projects
    • not sure - I I find this a bit too long and cumbersome {Andrew}
  • 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, +Andrew}
    • 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}
    • like - the word "your" speaks to people. {Andrew}
  • 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
    • ...
  • Create websites with built-in accessibility
    • ...
  • Project plan for accessible website development
    • ...
  • Process for an accessible website build
    • ...

Acknowledgements

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


Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Eval_in_process&oldid=8262"