The arrival of the February 11, 2005 law on equal rights and opportunities […] for disabled people triggered a minor revolution in the web world. A small one, because the legislator did indeed provide for a law, but no controls, no means of sanctioning offenders. Despite this, it’s clear that government departments are taking the issue seriously. Teams have therefore had to adapt to these new project constraints, most of which have in fact proved productive in terms of knowledge and rigor. Because, to build an accessible site, it’s important to understand why and how things are done. Understanding how others perceive the web, and understanding how the tools available to us work to produce content that can be used by everyone. Accessibility is actually at the confluence of many quality issues: ergonomics, aesthetics, code and content efficiency.
There are two accessibility guidelines in France, both based on the work of the WAI (Web Accessibility Inititative), WCAG2 (Web Content Accessibility Guidelines).
The Web Content Accessibility Guidelines (WCAG) 2.0 present a wide range of recommendations for making web content more accessible. Following these rules will make content accessible to a wider variety of people with disabilities, including the blind and visually impaired, the deaf and hard of hearing, people with learning disabilities, cognitive limitations, motor limitations, speech limitations, photosensitivity and people with a combination of these functional limitations. Following these rules will also often make web content easier to use for users in general.
(source W3C)
WCAG is the W3C’s international standard for Web content accessibility. Currently in v2.0, this standard is officially recognized by the European Commission, which recommends its adoption by all member countries of the community. The French government has been referring to it since 1999.
The first repository, Accessiweb (currently in “HTML5/ARIA” version), was written on the initiative of the Braillenet association and comprises 13 themes, each composed of a series of criteria. Each Accessiweb criterion corresponds to one or more WCAG 2.0 success criteria, one or more WCAG 2.0 techniques and one or more RGAA tests (Référentiel Général d’Accessibilité pour les Administrations, see below). Validation of an Accessiweb criterion validates the associated RGAA criterion(s).
The second standard, RGAA (currently in v3), is designed to define the technical accessibility of online services provided by the French government, local authorities and their public establishments, for the three channels of the Web, television and telephony.
The RGAA stems from the accessibility obligation imposed by article 47 of the February 11, 2005 law for “equal rights and opportunities, participation and citizenship for disabled people”, whose application decree was published in the Journal Officiel on May 16, 2009. It was approved for the Web channel in October 2009.
Which reference system for which type of project?
So much for the historical side. So, with these two standards, the question of choice arises. Even if, in the end, the accessibility of a site does not depend on the standard used to design or audit it (since these normative documents are merely technical translations of the WCAG), the type of report and certification offered to the client may depend on this choice.
At Digiwin, the choice of repository depends on the type of project:
- Public” client (administration, local authority, etc.), imposed choice : RGAA
- Private” customer: Accessiweb if certification requested, otherwise customer’s choice
Impact of accessibility on projects
For a web project, the level of accessibility required can range from A (or Bronze, in Accessiweb 2.2) – for private clients – to AA (Silver in the old Accessiweb standard), the minimum legal level for public authorities.
The difference between A and AA is slight, so we might as well push for AA if the project doesn’t include video.
Managing an accessible project requires specific skills. The presence of an Accessiweb expert or a person trained in accessible design techniques is relatively unavoidable. That’s why Digiwin has had two Accessiweb experts certified since 2008. Their in-house work consists of training teams and raising awareness among all those involved, from sales teams to designers.
All this represents a cost. Compared to a “standard” project, you’ll have to add time for code review, site auditing before going live, sometimes complex specific corrections and adjustments (especially with CMS, JS modules and other frameworks, which are rarely accessible), support and awareness-raising for the contributing teams (customer), and project follow-up in its long-term lifecycle. On a technical level, front-end integration is more delicate and requires a rigorous integrator, especially for sites using JS functionalities, asynchronous loading and media components.
Accessibility phases and stakeholder roles
Accessibility is a cross-functional issue throughout the project. Several phases and many profiles are impacted:
- Project initiation: technical sales representative, architect > Qualification of needs and feasibility.
- Design: architect, project manager, ergonomist/designer/graphic designer > SFG, SFD, storyboarding, layout.
- Development: developer, integrator > Templates, HTML/CSS/JS integration, technical acceptance.
- Operation: contributor, project manager, developer, designer > Corrections, upgrades, contributions.
At each of these phases, the accessibility expert accompanies the public concerned and reports any difficulties encountered or likely to be encountered to the CP. At Digiwin, the expert is also an ergonomist and integrator, which means he can be directly involved upstream and downstream of the project.
In the pre-sales phase, accessibility principles should be addressed by proposing simple solutions. The idea of creating two sites is to be avoided (temptation to propose a simplified “accessible” site as an alternative to the showcase site), the maintenance and design effort of a double publication being greater than that of a single accessible design.
Graphic choices need to be closely monitored by the expert, as they may prevent validation and require rework after integration, resulting in costly loss of time and re-validation issues with the customer.
Throughout the project, the CP is the guarantor of accessibility: he or she must involve the expert whenever necessary, and if possible at an early stage, to avoid costly corrections. With the experience of accessible projects acquired over the last ten years, most project managers have acquired reflexes that enable them to anticipate difficulties and propose solutions that have already been tried and tested.
What about the future?
Rapidly evolving technologies pose a major challenge to our teams, who need to keep abreast of the latest developments. The role of certified experts is to keep abreast of developments, and to participate as much as possible in GTA (Groupe de Travail sur l’Accessibilité) discussions and seminars organized by the Braillenet association. This watch is made more complex today with the loss of momentum of Accessiweb and the GTA mailing list. Nevertheless, Accessiweb has set up a certification follow-up process based on additional training courses. These enable experts to revalidate their skills and keep up to date with digital accessibility techniques.
At Digiwin, the challenge of accessibility has meant raising the technical level of our integration and development teams. That’s why, even on projects that don’t mention any particular accessibility requirements in their specifications, design now benefits from the contributions made by our employees’ increased skills.
