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 "Start with Accessibility"

From Education & Outreach
Jump to: navigation, search
m (Content Creation)
m (EOWG notes on @@section)
Line 149: Line 149:
 
[http://www.w3.org/WAI/intro/people-use-web/diversity Diversity of web users] describes the types of disabilities, situations, problems and remedies to making content accessible.
 
[http://www.w3.org/WAI/intro/people-use-web/diversity Diversity of web users] describes the types of disabilities, situations, problems and remedies to making content accessible.
  
 +
===<span style="color:#808080;">EOWG notes on @@section</span>===
 +
 +
<div style="color:#808080;">
 +
 +
* @@comment {name}
 +
 +
</div>
 +
 +
== 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.
 +
 +
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 [http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html 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 ===
 +
 +
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.
 +
 +
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.
 
===<span style="color:#808080;">EOWG notes on @@section</span>===
 
===<span style="color:#808080;">EOWG notes on @@section</span>===
  

Revision as of 15:48, 11 February 2013

Nav: EOWG wiki main page

Previous versions and notes: Eval in process

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.


EOWG notes on @@section

  • @@comment {name}

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:

EOWG notes on @@section

  • @@comment {name}

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.

EOWG notes on @@section

  • @@comment {name}

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.

EOWG notes on @@section

  • @@comment {name}

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.

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

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.

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.

EOWG notes on @@section

  • @@comment {name}