Who Is Responsible When It Is Not Accessible

Three parties, one page

A typical business page is the work of several hands.

A supplier built the templates. A theme or page builder somebody else wrote provides the structure. Two or three plugins contribute a form, a slider, and a cookie notice. Your own staff wrote the content and uploaded the images.

When somebody cannot complete the form, all four are candidates, and the instinct is to establish which one is at fault before anything happens.

That instinct is usually the reason nothing happens for six weeks.

The distinction that clarifies it

There are two different questions and they have different answers.

Who is answerable to the person who could not use the site, and to any obligation that applies to the organisation. That is the site owner, essentially always, because it is your site and your name on it.

Who bears the cost of fixing it, as between you and your supplier. That depends entirely on what was agreed and on when the problem was introduced.

Conflating those two produces an owner arguing with a supplier while a customer waits, which is the worst available outcome for everybody including the supplier.

Fix it, then settle the cost. In that order.

Where the line usually falls

• Templates and structure: the supplier built it.
• Third-party components: the supplier chose it.
• Design and colour: whoever approved it, jointly.
• Content added after handover: the owner.
• Images uploaded by staff: the owner.
• Documents published later: the owner.

The second is contested more than it should be. A supplier who selected a booking widget that cannot be used with a keyboard made a professional choice, and selection is part of what was bought.

Content is where sites decay

The uncomfortable half for site owners, and the one that causes most of the regression.

A site delivered in good condition degrades because images are uploaded without descriptions, headings are chosen for their size, text is put inside graphics, and documents are added as scans.

None of that is the supplier's doing, and no agreement can prevent it.

Which means a handover that includes twenty minutes of training and a one-page guide is worth more than a clause, and its absence is the most common reason a site that passed at launch fails two years later.

If you are the owner and nobody trained your team, that is worth raising with the supplier. If you are the supplier and you did not offer it, that is worth adding.

A worked example

A customer emailed a firm to say the enquiry form could not be completed with a keyboard.

The internal response was to establish whose fault it was. The site had been built two years earlier, the form came from a plugin, and the plugin had been updated since.

Three weeks passed, the supplier and the office disagreed politely, and the form remained unusable.

The customer did not wait and bought elsewhere.

The eventual fix, once somebody stopped investigating, was to replace the form plugin, which took ninety minutes.

The apportionment discussion that followed took a further two weeks and concluded that the cost was small enough not to matter, which had been true from the start.

What to put in an agreement

Deciding this in advance removes the argument entirely.

Name the standard and level the supplier is delivering to, and which templates it covers.

State that component selection is the supplier's responsibility, with an obligation to propose alternatives where one cannot meet the standard.

Set a period after handover during which failures in the delivered templates are corrected at the supplier's cost, in the same way as any other defect.

State plainly that content published by the owner after handover is the owner's responsibility, and pair that with a training obligation so it is fair.

None of this is exotic. It is the same structure any competent build agreement already uses for functional defects.

When the problem is in somebody else's code

The genuinely awkward case, and it deserves an honest answer rather than a clause.

A theme, a plugin, or an embedded booking system may have a failure you cannot fix, because you do not control the code.

Reporting it upstream is worth doing and is not a solution on your timescale, since a fix may take months or never arrive.

The practical options are to replace the component, to work around it, or to provide an alternative route: a phone number for bookings, a downloadable form, or a person who will complete it with somebody.

An alternative route is not equivalent and it is far better than nothing, and offering it while the component is replaced is a reasonable position to take publicly.

Respond to the person first

The part that gets forgotten while responsibility is being established.

Somebody who takes the time to tell you they could not use your site has done you a favour that almost nobody does.

Reply quickly, thank them, do not explain the internal complexity, and offer to help them complete whatever they were trying to do, by phone or directly.

Then tell them when it is fixed.

Handled that way, a complaint frequently becomes a customer. Handled as an investigation, it becomes a story they tell other people.

The counter-case

There is a version of owner responsibility that is unfair and worth naming.

A small business that bought a site in good faith, was told it met a standard, and was never trained is not sensibly described as responsible for a failure baked into the templates.

Suppliers who deliver inaccessible work and then point at the client's content are avoiding a professional obligation, and clients are entitled to push back on that.

Equally, an owner who was trained, given a guide, and has spent two years uploading unlabelled images cannot reasonably send the bill to whoever built the site in 2019.

The honest test is who introduced the specific problem, which is usually answerable in about ten minutes of looking, and only worth answering after it has been fixed.

What to do

1. Fix it first, before deciding whose it is.
2. Reply to the person and offer another route now.
3. Establish when the problem was introduced.
4. Check the agreement for the standard and the period.
5. Replace components you cannot fix.
6. Train whoever adds content, if nobody has.
7. Settle the cost afterwards, proportionately.

Step one resolves most of these before the question of responsibility becomes worth asking.

Getting the agreement right beforehand is covered in buying a website that meets a standard.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.