Notes from the studio desk

Choosing a web developer is harder than it should be. Portfolios all look polished, proposals all promise results, and it's difficult to compare a freelancer, a studio and an agency on equal terms. These are the questions we'd ask if we were in your position.

Who will actually do the work?

Ask to meet, even briefly, the person who will plan and build your site. If the work is subcontracted, that isn't necessarily a problem, but you should know about it and know who is responsible if things go wrong.

Who will own what?

Your domain name, hosting account, analytics and content management system should be registered to your organisation. Get this in writing. Many of the worst website stories begin with a domain held in a former supplier's account.

How do they handle content?

Ask who writes the words and when. If content is expected "at the end", the design will be built around placeholders and your real pages will feel forced into it. Good developers either help with content or plan it early.

What about accessibility?

Ask which standard they build to and how they test. "We use an accessibility plugin" isn't a good answer. Look for manual testing with keyboards and screen readers, and a commitment to WCAG 2.2 AA.

What happens after launch?

Find out what support costs, how quickly they respond and what happens if you part company. A clear, fair exit is a sign of a supplier who expects to keep you because you're happy, not because you're stuck.

Finally, ask for a written scope that lists pages, features and responsibilities. It protects both of you, and it's the most reliable way to compare proposals like for like.

The Web Content Accessibility Guidelines are the internationally recognised standard for accessible websites. Version 2.2 was published by the W3C in October 2023. It builds on version 2.1 rather than replacing it, so a site that met 2.1 AA is a good starting point but may need some additional work.

What's new at level A and AA

Focus not obscured. When someone moves through a page with the keyboard, the focused item mustn't be completely hidden behind sticky headers, cookie banners or chat widgets.

Dragging movements. Anything that needs dragging, such as a slider or a reorderable list, must also work with a simple click or tap.

Target size. Buttons and links should be at least 24 by 24 CSS pixels, or have enough space around them that they're easy to hit.

Consistent help. If you offer help, such as a phone number, a contact link or a chat, it should appear in the same place across pages.

Redundant entry. Don't ask people to type the same information twice in one process. Pre-fill it or let them select it.

Accessible authentication. Logging in shouldn't depend on a memory or puzzle test, such as transcribing distorted characters, unless an alternative is offered. Allowing password managers and copy and paste is the usual fix.

Why it matters in the UK

Public sector bodies have specific accessibility obligations, and the Equality Act 2010 expects service providers to make reasonable adjustments for disabled people, which can include their websites. Legal obligations aside, the same improvements make sites easier for everyone: people on small screens, people in a hurry and people whose hands are full.

If you're not sure where to start, test your key pages with the keyboard alone. Can you see where you are at all times, and can you finish the main task? That ten-minute check often shows exactly what to fix first.

Websites rarely fail dramatically. More often they decline slowly: a plugin falls behind, a form stops sending, the opening hours are wrong over a bank holiday. None of it is hard to prevent if someone owns a simple routine.

Monthly

Apply software updates, ideally after testing them on a copy of the site. Check that backups have actually run and that you know how to restore one. Send a test message through every form and confirm it arrives.

Quarterly

Read your key pages as a newcomer would. Are the services, prices, team members and contact details still right? Run a broken-link check, look at page speed on a phone and go through your main journey using only the keyboard.

Annually

Review your privacy notice and cookie set-up against how the site actually works. Confirm renewal dates for your domain and security certificate, and check who has administrator access. Remove anyone who has left.

Write it down

The most valuable maintenance document is a single page listing where everything lives: domain registrar, hosting, content management system, analytics, email sending and the people with access. Keep it somewhere safe and shared. When something goes wrong, it saves hours.

If that routine sounds like more than you have time for, a care plan exists to take it off your hands. Even so, keeping that one-page document up to date yourself is always worth doing.