Standards for accessibility for the disabled and aging populations upset many habits in organizations that undertake to establish their practices in Web development. The requirements of these standards are questioning practices often deemed adequate so far, proven and best. The desire to integrate these new quality concerns within a team production leads to sudden changes that may destabilize the profitability of a production website.
Although the principles applied in practice accessibility is not difficult to implement, the greater the risk of falling into some traps. This article aims to identify those in which organizations are most likely to fall. This list is not exhaustive, but for the sake of this article, we retained only those most frequently identified in our practice.
Intimately linked to each other, these traps often cause a cascade of negative consequences for the potential accessibility of Web projects. Here's the list:
Consider accessibility as a step in the end and ignore the cross-practice accessibilityAssign responsibility for accessibility to Web integrators onlyLimit the accessibility validation to those requirements outlined in the standardsConfuse the concepts of standard compliance and accessibility of formal accessibilityAssume that the validation tools will do the jobUnderestimating the impact of technology platformsIdentified for each trap, we will attempt to analyze the nature and cause of the problem. We then present some tips to quickly integrate prevention mechanisms that will promote their avoidance.
Some common pitfallsConsider accessibility as a step in the end and ignore the cross-practice accessibility
The first trap that many fall managers and project managers during the planning stages for a Web project, is to perceive accessibility as an additional link that is added to the end of term production chain web .
In this false perspective, accessibility is seen as a grid to provide additional validation when the control phase of the project's quality, just before the launch of the result. The concept of grid control that comes with accessibility standards is certainly no stranger to this perception.
In the case of a formal end-term accessibility, the accessibility experts too often observe that certain decisions have undermined the potential accessibility of the project. As an example, the following situations:
navigation systems on a website that are entirely dependent on the mouse, and therefore unusable for anyone who navigates with the keyboard;of technology choices naturally incompatible with adaptive technology or computer operated in a manner inconsistent with them;content available online in downloadable formats rather than HTML and are impossible to interpret by screen readers;text alternative to non-text content that were not foreseen by the developers as the editor, or even the organization was prepared to predict and devote the necessary effort;graphic layouts color contrasts insufficient, while the visual signature is already plastered across the city and on the web.Consequently, the organization is often found before the statement that it is too late to get it right. Either because budgets or schedules do more to reverse, or because the technology choices limit the ability of a team to produce accessible content. However, the mere fact of asking the right questions at the right time helps to avoid failures in the vast majority of cases.
Unlike dimensions "traditional" Web, such as design, analysis, ergonomics, usability, writing, and even the integration of programming, accessibility does not register as a separate step and additional. It spreads into every link of a chain of web production to provide for each intervention at the appropriate time. This is a mainstreaming.
Some choices made at the beginning and middle of course facilitate the implementation of accessibility or, conversely, generate barriers. Mainstreaming accessibility avoids significant omissions, particularly in technical and strategic choices. These oversights can result in costly delays and additional efforts to correct the situation, when patches are possible. As is known, it is always better than cure.
Any manager or project manager must recognize this peculiarity of the transversality of accessibility. He will then understand the need to determine which links in the production chain must be assigned the Web different responsibilities and tasks associated with requirements outlined in the standards.
Assign responsibility for accessibility to Web integrators only
Currently, the responsibility to implement the requirements of accessibility is still too often the only Web integrator. It is illusory to believe that it can rest on the shoulders of a champion of accessibility within an organization.
While the vast majority of accessibility requirements require intervention of Web integrators, several decisions and policies must be taken in the early stages of the project to ensure efficient work. For an accessibility approach proves successful, it is important that each player of a team understand the accessibility features within its responsibility. This will avoid returning:
the editors ask for text equivalents images;designers to review their graphic to adopt sufficient color contrast;programmers to provide an explicit association between labels and their corresponding fields in a form;or the project authority to challenge the technological choices that limit or prevent the fulfillment of certain requirements.That we consider to analysts, ergonomists, designers, editors or information architects, everyone is called to make decisions or take actions that may affect the potential accessibility of the project. To prevent these interventions have a negative impact on the final outcome, it is important that accessibility becomes a shared responsibility.
Limit the accessibility validation to those requirements outlined in the standards
The development of an accessible website is very often perceived as an audit to be performed from a small list of demands, as if it were enough to verify compliance with each requirement to produce an accessible website. In fact, it's not that simple.
The implementation of all requirements outlined in the standard achieves compliance with a standard. However, the systematic application of these requirements alone is not a sufficient guarantee of accessibility: it should also include functional testing with computer adaptive technologies that can validate the user experience is positive. Indeed, it is quite possible to produce a web site meets all accessibility requirements, but is still not available on some aspects. Missed some small subtleties are enough to cause a significant degree of confusion for the user not being able to perceive visual interface.
For functional testing means the use of computer adaptive technology such as voice synthesizers, screen readers and magnification software to verify that the results interpreted by these tools corresponds to the result observed in a visual validation of Web pages. For example, an absence of punctuation in the texts to replace images or a visual punctuation based solely on the provision or the reading order of content presented in HTML table, can produce a result very different from what we had imagined. Similarly, it is often re-reading a Web page with a screen reader that there is some missing information will be transmitted visually in speech or Braille. Playback speech may also be due to confusion with the pronunciation or the sequence of content (eg 'standards and norms "and" enormous standard ").
By adding functional tests to test techniques, producers of Web content make sure not to let anything escape during quality controls related to accessibility.
Confuse the concepts of compliance with accessibility standards and accessibility into
For most project managers and web developers, the concepts of compliance with accessibility standards and formatting Web content accessibility are interchangeable. However, these two concepts have very different meanings, and one can not be a source of assurance for each other.
The notion of compliance with accessibility standards based on respect effective, satisfactory and consistent with all requirements listed in a standard. In the field of standardization, conformity to a standard means that the application meets all the requirements thereof. The result is dichotomous: the application is compliant or it is not. In standardization, a statement such as: This website conforms to 60% in the standard makes no sense. This concept is objective because it is limited to the application of the requirements and measurable.
The concept of development based on access to it on an effort to bring down a maximum of barriers to the use of Web content for people with disabilities. Subjective concept, it requires the implementation of several measures to adapt content to meet specific user needs. Contrary to the notion of conformity to the standard of accessibility, it involves functional testing to ensure that beyond the compliance standards, efforts have real effects on the user experience of disabled people who visit these content.
The results of the implementation of accessibility can not be measured objectively, however, because it is impossible to judge at what point a website is "sufficiently accessible". Thus, it is the Web developer, according to the intentions of the organization or budget available to determine the threshold at which the result is considered satisfactory.
It is therefore possible to produce a standards compliant website that does not quite yet the needs of users because some details have escaped the developers. In the same spirit, a website considered "reasonably accessible" in the eyes of the developers themselves may not fully meet the needs of a particular clientele that would have been ignored during the process. Hence the importance of combining the two concepts to reach the widest possible result.
Assume that the validation tools will do the job
Accessibility can be measured only by the presence or absence of certain key elements that an assessment tool could automatically detect. Just as ergonomics, accessibility is good judgment developers and therefore a competent human evaluation.
In an ideal world, the concept of quality control machinery would fall. It would be pointless to address the adaptation needs of disabled people on the Web, because the tools would be able to take care of all this concern. According to the legislation in place in the respective countries where they come from, the tools are often accompanied by promotional claims that have to inflate their abilities on the potential accessibility. Several managers and project managers tend to believe that these tools can do all the work for them, but in fact it is not. Whoever gives the responsibility for the goal of accessibility in the hands of the tools, or platforms, it uses is doomed to experience great disappointment the day he will undertake assessment tests to measure the actual level of accessibility project.
Of all the accessibility requirements contained in standards, testing of only a minority can be automated to the point where human intervention would be unnecessary. It is generally estimated at around 30% the number of requirements for which verification can be completely automated. For example, it is easy to programmatically check the presence of an attribute alt for the replacement text of an image, it is impossible to check automatically if the value of the text equivalent before he takes over all the Text appearing in the picture.
Underestimating the impact of technology platforms
In addition to the interventions required for each requirement to distribute in the production chain web, it is crucial that some strategists in the team of web production (usually responsible for decisions such as technical managers, project managers or analysts) , questioned the potential tools and technology choices considered. Indeed, the very best of web, with the most stringent processes for accessibility, may not achieve its compliance goals if he agreed tools make the task impossible.
In addition, several managers and project managers mistakenly assume that since they rely on high technology platforms acquired at high prices, accessibility issues will necessarily be supported automatically and successfully.
Accessibility in practice, many organizations are struggling with all kinds of technology platforms that meet the most basic accessibility collide with the technical limitations of existing tools. For example, seemingly simple changes that require easy correction to the HTML or XHTML are impossible to perform in practice because Web developers do not have access to the source code of their tools. In this context, it is not possible to expect to achieve the goals of standards compliance.
While the technology platforms in OSS generally greater potential accessibility due to the possibility of modifying the generated code to the same tools, we should not conclude that the tools provided owners can ensure compliance with accessibility requirements. Some tools are more flexible than others. The important thing is to be aware of this reality and ask the hard questions when it comes time to choose a platform over another.