Clients want assurances when they are paying to create an accessible web site. Here are some considerations on how to formally engage with them without losing sight of final users.
Since I've started working with web accessibility in 2013, I've rarely met it as an explicit demand from clients, either from public or private bodies. For long, accessibility seemed a hard to grasp concept, tricky to be ordered and even worst to be verified.
Requests for an accessible web site were limited to a simple paragraph in the call for proposal and, as clients weren't sure of what to require, the engagement with accessibility was absent in the final formal agreement. This lack of familiarity with accessibility and the absence of a framework on which clients could rely on affected the possibilities to state more concrete and objective goals.
Fortunately, this situation has been changing in the last few years, thanks to governmental laws and policies prompting actions on digital accessibility and even applying fees if otherwise, but also by offering guidelines on how to state the demand, and to verify if the request is properly respected.
From marginal demands to formal contractual engagements, we finally have more grounds to “buy” or “sell” web accessibility, which implies that clients now desire to be sure we will respect the engagement by contractually stating ways to verify and certificate the work done.
While contractual engagements are essential to reassure our clients of our commitment to accessibility, sometimes the demands may not be realistic nor efficient, and they may not properly guarantee a good level of accessibility.
In this light, which would be the ideal engagement?
Note: I come in no way from commercial or juridical background, so please do not expect to find here a recipe on how to write a contract on web accessibility; instead, I expose some clues on how to deal with it with our clients.
A Web Site is a Living Media
The reality that makes the web so exciting to develop is also the reality that complicates its debugging and maintenance: as an universal media able to run in any user agent, the web evolves in various environments, and its success counts on the delicate combination of different browsers, browsers' versions, operational systems and screen readers; consequently, there may be rich combinations leading to a possible exponential number of problems.
Add to this reality the fact that a web site is constantly changing and evolving, and we have a touchy media that cannot be evaluated other than in a limited time-framed “snapshot”.
This evidence, obviously, also applies when we are trying to measure the level of conformity of a web site's accessibility.
If development is properly done from the beginning, taking into account what is needed to build an accessible web site — which is not the subject here —, one can avoid a snow ball effect, when each new evolution or change adds more and more problems, until the site becomes an indigestible tag soup. Nonetheless, each new change or evolution to our web sites may imply in regressions, with possible new bugs and accessibility problems that must be addressed constantly, especially if we add to the equation the way development teams equally change and evolve.
Besides addressing problems arising from changes, we must also be able to deal with the evolution of the environment in which our web site evolves — new versions of everything! — and that can also be tricky and time-consuming.
This sensitive context must be taken into account when answering to our clients' requirements in terms of accessibility: if our contractual commitment to accessibility imposes scoring 100% of the success criteria of the WAI/CAG recommendations, how do we choose the exact time when this must be true?
Let's say that the client states that, for each foreseen major release, a new audit will be done and penalties will follow if we don't score 100%; that clearly means that accessibility must always be part of our continuous testing plan, but unlike general development bugs, only a limited part of accessibility can be considered in a continuous integration approach. Indeed, most of the accessibility recommendations must be tested by a human reviewer due to the level of subjectivity it imposes.
As a living media, tests must be constant and users' feedback must be obtained and acted upon frequently.
Accessibility is not a matter of percentage
Accessibility cannot be approached as a measurable task. Confusing the percentage of positive success criteria with the real level of accessibility of a web site is an error and can lead to misinterpretations. Percentage is random, and it is used only due to a lack of a more objective way to certify the level of accessibility of a web site, besides the fact that some public and private bodies rely on it.
Let's take a look at just two success criteria: the presence of textual alternative to images and the enough contrast between text and background colors. Now, let's say our web site complies to all success criteria except these two. Hooray! We can say our site is “98% compliant”! Well, yes, but it is in no way accessible: the user cannot access a portion of the content of the site (given by images), and users with low vision will simply be unable to read portions of the content — if not all of it. This is simply a web site that is in no way accessible because it literally blocks the access to the content, which is the most basic thing we should avoid.
Accessibility is a continuum. It is based on the user experience. It cannot simply be defined as a pass/fail or accessible/inaccessible.
– Jared Smith, Associate Director of WebAIM
It is not the percentage of the valid success criteria that will tell us how accessible our web site is; far from that. accessibility is about people, in all their diverse desires and needs and habits. To limit the way we evaluate it to a simple recommendation percentage is shallow and devoid of sense.
The case of conformity polices
Obviously, formal engagements with the client will also have to take country polices into account. It turns out that some conformity polices are somehow based on percentages as well. For example, in France, the new regulations state that a web site may claim partial accessibility if “at least 50% of the RGAA (Référentiel général d'amélioration de l'accessibilité, the Accessibility Reference Guide in France) success criteria are respected”; as we've seen, this notion of partial accessibility is meaningless, but it is the pragmatic way they've chosen to rely on.
Both France and the UK — countries I've worked with — are not clear about penalties in case of not respecting accessibility, but both demand web sites to publish “an accessibility statement that explains how accessible your website or mobile app is” ( Accessibility Requirements for Public Sector Websites and Apps), and demand a clear planning of the actions that are or will be overtaken to apply accessibility to the web site.
These impositions are realistic and, let's say it, sophisticated; they are not reinforcing the penalty side, instead they promote awareness and guidance on how to act. Also, they treat accessibility success criteria as they should be: as a guidance, not as a measure to be used in case of forfeit.
The strategy underlined here, as I understand it, is to give the users the “ownership” of accessibility, and to empower them with the possibility to react and eventually sue web sites that are not living by the published statements.
The accessibility statement becomes our public engagement with the legislation and with our users.
Accessibility Audits and Objectivity
Another point that can be tricky in engaging in percentages of success criteria is the eventual arbitrariness and subjectivity of audits. Different auditors may present different opinions in validating or not a success criterion, when two audits of the same web site may present almost 50 percent difference between them.
As I've said before, many recommendations imply a certain level of subjectivity, leaving us to the mercy of the auditor, and this level of subjectivity may always surprise us and lead to long discussions and litigation.
As our clients rely on external audits to validate or not our accessibility efforts, we must consider this possible level of subjectivity with caution when signing formal engagements.
As we have seen, to engage in a formal contract that imposes penalties based on the percentage of success criteria is not efficient, can be tricky if audits' reviews are not well defined, and it does not assure user satisfaction. But avoiding the “percentage approach” does not mean that we cannot be pragmatic and precise in terms of commitment — it means we have to be realistic.
I'd like to believe we can be pragmatic and factual when engaging in formal contracts and that we can truly assure the quality of our web sites in terms of accessibility by really considering the user needs.
The engagement with our clients and their users must be to a real, more noble goal.
The success criteria of the accessibility guidelines should be seen exactly for what they are: guidelines; and while we still have to respect every applicable criterion — a tacit respect when we know what we're doing when we design and develop for the web —, we won't use a percentage of success as the proof of our commitment to accessibility or as a goal to achieve it. Instead, the engagement with our clients and their users will be with the real, more noble goal: to create an truly inclusive and accessible site, giving access to the totality of the content and interactions, in spite the physical and/or material constraints a user may present.
But then, how do we assure our clients that we are respecting our engagements, that we are delivering what we've promised we would? One good choice would be to rely more on the legislation approach: empower the users and give them the final word by means of tests and feedbacks. This is also a good way to avoid the subjectivities of accessibility audits.
Of course, internal and external audits should always be foreseen, but their perspective should shift from punishment to enlightenment:
- it must be the reference to create and update the accessibility statement;
- it should help to identify unknown problems to be acted upon.
Let's see what a realistic engagement that reassures our clients, that respects governmental polices and that truly assures user satisfaction should include:
- One complete audit on production launch that will give the bases to the accessibility statement;
- A precise schedule based on major releases.
Litigation points may exist in audits (remember subjectivity), but they must be dealt with during user tests.
- User tests:
- After production launch;
- A precise schedule based on major releases.
Of course, user tests must include users presenting physical and material constraints.
- Users' feedback:
- The design and promotion of a user feedback interface that will allow to regularly gather information on how people are using our web site and the problems they are facing.
This may be the most powerful tool to show our commitment and the quality of the work we are providing.
Fixes and improvements based on user feedback can be part of a general maintenance program as they are usually simple, assuming that we are maintaining a web site designed and developed with accessibility in mind from the ground up; assuming that designers, managers, editors and developers have been trained for accessibility and will have means to keep monitoring their work. If accessibility is not taken into account since the beginning, any engagement will be jeopardized and efforts to amend the web site's accessibility will be considerable; yes, we will surely lose money here.
Giving the users the ownership of the web site's accessibility and empowering them with tests and feedbacks is the most effective and realistic way to assure our clients: the users's satisfaction is the best certification we can display.