Start with Accessibility

From Education & Outreach

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 Introduction

  • Leaving accessibility until the end of a project can also result in some aspects not being able to be addressed due to design or coding features being locked in and unable to be changed without starting over. Also needs to be considered and specified right at the start to be sure the platform and tools support accessibility. {Andrew, 2014.07.04}
  • @@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, procurement, 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 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

When accessibility is not yet part of an organization, 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 Project Initiation Stage

  • @@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 need to work together throughout the project life cycle to understand the relationships between design, content and functionality which ensures 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. Test the first mock-ups, each release of the prototype, and if possible, test with real users.

Evaluation

Effective evaluation includes:

  • Establishing clear requirements on the expected accessibility conformance level
  • Ensuring a common understanding among team members (designers, developers, content providers)
  • Involving 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 AddOn 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 Planning Stage

  • @@comment {name}

Design Stage

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.

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.

At the same time, content should be addressed. Content that is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility and should be addressed in the design of the project. In this manner, content will be written to include all users and the presentation aspects will be considered by the designers.

Initial Mock-ups

Even before coding begins, the initial wireframes or visual mock-ups can be evaluated through early screening by performing checks. 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

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

  • @@comment {name}

Development Stage

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

Once developers understand the requirements for accessibility, they are quick to find solutions and program accordingly, frequently spotting and addressing issues early in the process. Document the solutions for accessibility so that they can be re-used and shared as resource. In this way, developers automatically start to include accessibility as a standard in their daily programming practices and it is no longer considered as a separate requirement but part of their development process.

Pre-Development Checklist

Checklists often work well for the developer mindset and are essential at the planning stage when product requirements are defined, at the design stage in the creation of the design, and during development when implementation of the product begins.

During the planning stage, set aside sufficient time for creating such a list. The items on the checklist will vary depending on the project. It does not need to be exhaustive, but it should aim to cover the mostly likely points. The checklist can be very useful for re-use in future projects. A useful resource which can assist in the design your project's checklist is WCAG 2.0 Appendix B: Checklist.

Before starting development, ensure that all of the questions on the checklist have been considered so that development will include solutions to address those questions.

Development Cycle

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.

This may be a new area for some developers, rest assured that there are many experts in the field of accessibility who are willing to offer advice to developers in search of solutions. For example, the Web Accessibility Initiative Interest Group is a good point to start.


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

  • @@comment {name}

Project Closure

In the project sign-off, include the acknowledgment for accessibility conformance. Celebrate this as an achievement with the team and 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 future projects.

EOWG notes on Project Closure

  • Project may have closed (i.e. delivered), but the website or application lives on and needs a maintenance (and maybe improvement) plan. This is where many projects fail - accessibility is an ongoing requirement as sites are updated and applications expanded. {Andrew, 2014.07.04}
  • @@comment {name}

Post Project

A frequent myth in accessibility is to assume that once a project is closed and the product is delivered as accessible that it continues to be accessible. The fact remains that people change jobs, technologies change and solutions evolve. Thus, 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
  • New barriers are not introduced when redesigns, new features or updates are planned
  • Solutions selected remain current
  • Accessibility knowledge of staff remains a continued requirement (offer repeated training opportunities as staff and responsibilities change)

Conclusion

Start early with Accessibility. Starting early has many benefits including that it is much less costly than assessing accessibility at the end of a project. Involve the whole team. Ensure that all concerned (project board, team members, designers, content providers and developers) all understand the requirements for accessibility. Once the "why" of accessibility is understood, the "how" is easy to implement and can eventually be introduced as a best practice within the organization.

The most robust way to ensure long-term accessibility is to ensure that the accessibility knowledge is incorporated and remains within the organizations.

EOWG notes on Post Project

  • @@comment {name}