Planning accessibility

Considering accessibility a final step in the process and ignoring the transversality of accessibility practice

The first mistake that many managers and project leaders make in planning the various phases of a Web project is to view accessibility as an extra link added at the end of the Web production chain.

In this incorrect approach, accessibility is seen as an additional verification step to be included in the project’s quality control phase, just before putting the product online. The checklist provided with the accessibility standards certainly does not dissuade this approach.

When accessibility is applied at the end of the process, accessibility experts find too often that certain decisions have undermined the project’s accessibility potential. We offer the following situations as examples:

• Navigation systems on a Web site are entirely mouse dependent and thus inaccessible to anyone navigating by the keyboard;
• Technology choices that are naturally incompatible with adaptive computer technologies or operated in a manner that is incompatible with them;
• Content placed online in downloadable formats rather than in HTML and which cannot be interpreted by screen readers;
• Developers fail to provide for text alternatives to non-text content even though the editor, or the organization, was prepared to provide for such alternatives and to devote the necessary effort to them;
• Graphic art work with inadequate colour contrasts and this visual signature is already plastered all over the city and the Web.

As a result of these choices, the organization is often confronted with the reality that it is too late to do things properly, either because budgets or timelines make it impossible to go back, or because the technology choices restrict the ability of a team to produce accessible content. Simply asking the right questions at the right time can avoid failures in the vast majority of cases.

Unlike the “traditional” dimensions of the Web, such as design, analysis, ergonomics, user friendliness, editing, integration and even programming, accessibility is not a separate, additional step. It must be an integral part of each link in a Web production chain so that each intervention can be planned at the appropriate time. It requires transverse integration.

Certain choices made at the beginning and in the middle of the process make it easier to ensure accessibility or, contrarily, create barriers. Transverse integration of accessibility avoids important oversights, particularly when making technical or strategic choices; such oversights may result in delays and costly additional effort to correct the situation, if it can be corrected at all. Obviously, it is always better to prevent than to fix.

Managers and project leaders must recognize the transversality of accessibility. They will then understand the need to determine which links in the Web production chain must be assigned which responsibilities and tasks associated with the requirements set out in the standards.

Assigning responsibility for accessibility only to Web integrators

At present, the responsibility for applying accessibility requirements too often falls to the Web integrator alone. It is unrealistic to think that this responsibility can rest on the shoulders of a single accessibility champion in an organization.

Although it is true that a great many of the accessibility requirements require intervention by Web integrators, many decisions and directions have to be taken in the initial phases of the project to ensure efficiency. A successful accessibility initiative requires that every person on the team understands the accessibility elements that fall under his or her responsibility. This will avoid having to go back to:

• editors to ask for text equivalents for images;
• designers to ask them to review their graphic chart to adopt colours with adequate contrast;
• programmers to ensure an explicit association between text labels and their corresponding form controls; or
• the project leader to question the technology choices, which limit or prevent conformance with certain requirements.

Every analyst, ergonomist, designer, editor and information architect has to make decisions or take actions that may affect the project’s accessibility potential. To avoid having these interventions negatively impact the final result, it is important for accessibility to become a shared responsibility.

Limiting accessibility verification solely to the requirements contained in the standards

Making a website accessible is often perceived as a test to be carried out using a small checklist of requirements, as though by verifying compliance with each requirement will ensure an accessible website. In reality, it is not that simple.

Applying all of the requirements described in the standards produces conformance with a standard. However, systematic application of only those requirements is not a sufficient gauge of accessibility: functional tests must also be performed with adaptive computer technologies in order to ensure that the user’s experience is positive. It is entirely possible to produce a Web site that meets all of the accessibility requirements, but is still not accessible in certain aspects. A few missed subtleties are enough to create significant confusion for the user who is unable to visually perceive the interface.

Functional testing means using adaptive computer technologies, such as speech synthesis, screen readers and text enlargement software, to verify that the result interpreted by these tools actually corresponds to the result observed during a visual check of the web pages. For example, missing punctuation in the text alternative for images or visual punctuation based solely on the layout or content reading sequence of the content in an HTML table can produce a very different result than what had been imagined. Furthermore, it is often in rereading a web page with a screen reader that it becomes apparent that some information transmitted visually will be missing when using speech synthesis or Braille. Speech synthesis reading can also reveal confusing information resulting from pronunciation or the linking of certain content (example: “standards et normes” and “standards énormes”).

By adding functional tests to technical tests, Web content producers ensure that nothing has been missed by the accessibility quality controls.

Confusing the concepts of conformance with the accessibility standard and of ensuring accessibility

For most project leaders and Web developers, the concepts of conformance with accessibility standards and of ensuring the accessibility of Web content are interchangeable. However, these two concepts have very different meanings and one does not ensure the other.

The concept of conformance with the accessibility standard is based on efficient, satisfactory and systematic compliance with all of the requirements set out in a standard. In the standards field, conformance with a standard means that the application meets all of the requirements of that standard. The result is dichotomic: the application conforms or it does not. From a standardization perspective, a statement that “This Web site conforms to 60% of a standard” makes no sense. This concept is therefore objective because it is limited to the application of prescribed and measurable requirements.

As for the concept of ensuring a site’s accessibility, it is based on an effort to eliminate as many barriers as possible to the use of Web content by persons with functional limitations. A subjective concept, it involves putting in place numerous measures for adapting content to meet the specific needs of users. Unlike the conformance concept, it assumes functional tests to ensure that, in addition to meeting the requirements of the standards, the effort invested has a real beneficial impact on the user experience of persons with disabilities who consult the content.

The results of ensuring accessibility are not, however, measured objectively because it is impossible to determine at what point a Web site is “accessible enough”. Thus, it comes back to the Web developer to determine, based on the organization’s intentions or available budget, the point at which the result will be considered satisfactory.

Consequently, it is possible to create a Web site that meets a standard but which does not actually meet the needs of users because certain details may have been overlooked by the developers. In the same spirit, a Web site deemed “sufficiently accessible” in the eyes of those same developers might not fully meet the needs of a specific clientele left by the wayside during the process. It is therefore important to address both concepts to achieve the best possible outcome.

Assuming that verification tools will do all the work

Accessibility cannot be measured solely on the basis of the presence or absence of certain key elements that can be automatically detected by an evaluation tool. Like ergonomics, accessibility requires the good judgment of developers and thus, also, competent human evaluation.

In an ideal world, quality control would be handled by machines. There would be no need to think about the adaptive needs of persons with disabilities on the Web because the tools would be able to look after that concern. Depending on the legislation in place in the countries from which the tools come, they often include promotional statements that inflate their capabilities in terms of accessibility potential. Many managers and project leaders tend to believe that these tools can do all the work in their place but, in fact, that is not the case. Anyone who relies on their tools or platforms to achieve their accessibility objective will be greatly disappointed the day that they conduct evaluation tests to measure the project’s real level of accessibility.

Only a small percentage of the accessibility requirements set out in the standards can be verified automatically to the extent that no human intervention is required. It is generally estimated that about 30% of the requirements can be verified completely automatically. As an example, although it is easy to verify through programming the existence of an alt attribute for an image’s text alternative, it is impossible to automatically verify whether the captured text equivalent encompasses all of the text appearing in the image.

Underestimating the impact of technology platforms

In addition to the interventions required for each requirement to be allocated throughout the Web production chain, it is crucial for certain strategists within the Web production team – generally those responsible for technical decisions such as managers, project leaders or analysts – to examine the potential of the proposed tools and technology options. The best Web team, with the most rigorous accessibility processes, cannot achieve its conformance objectives if the tools used make the task impossible.

Moreover, many managers and project leaders wrongly assume that since they are using high level technology platforms at great cost, accessibility issues will necessarily be handled automatically and satisfactorily.

In accessibility practice, numerous organizations are working with technology platforms of all orders where the most basic accessibility requirements come up against the technical limitations of the tools in place. For example, very simple changes in appearance requiring an easy correction to the HTML or XHTML code are impossible in practice because the Web developers do not have access to the source codes of their tools. In this context, one cannot hope to achieve the objectives of standard conformance.

Although the technology platforms in open source software generally have better accessibility potential because of the ability to change the generated code using the same tools, it should not be assumed that proprietary tools cannot ensure compliance with accessibility requirements. Certain tools are more flexible than others. What is important is to be aware of this reality and to ask “good questions” when the time comes to choose one platform over another.

Here are a few examples of the questions to ask:

• To meet the organization’s accessibility objectives, is it possible to alter the generated HTML code using the proposed tool?
• Is the proposed tool flexible enough to adapt to the organization’s internal development practices?
• Does the proposed tool already make it possible to meet some of the basic web accessibility requirements?
• Did the supplier of this tool clearly target accessibility as a major element in the development of its software solution?
• Will the organization conduct a detailed evaluation of the tool’s potential for accessibility prior to entering an agreement with the supplier proposing it?