Planning
Accessible, responsive websites: what to ask for
Two promises sit behind almost every website quote: it works on a phone, and it works for people with different abilities. Here is how to check both without being an expert.
“Responsive” and “accessible” appear in almost every website proposal, and they are rarely explained. They are different things that happen to overlap, and you can test a good deal of both without technical knowledge.
What each word means
Responsive means the layout adapts to the screen. The same page rearranges itself for a phone, a tablet and a desktop: columns stack, text stays readable without zooming, buttons are big enough to tap. It is about the shape of the screen.
Accessible means the site can be used by people with different abilities and different ways of using a computer: someone who cannot see the screen and uses a screen reader, someone who cannot use a mouse, someone with low vision, someone with a temporary injury, someone using a phone in bright sun. It is about the person.
A site can be responsive and still inaccessible, for example a phone layout with low-contrast text and buttons you cannot reach without a mouse.
The standard behind it: WCAG
The W3C, the body that sets web standards, publishes the Web Content Accessibility Guidelines (WCAG). The current version is WCAG 2.2, published in October 2023 and updated in December 2024. It has 13 guidelines under four principles: content must be perceivable, operable, understandable and robust. Each guideline has testable criteria sorted into three levels, A, AA and AAA. W3C recommends using the latest version, and says content that meets 2.2 also meets the earlier 2.0 and 2.1.
The W3C page does not itself set out any legal requirement. Whether a law applies to your business depends on where you are and who you serve, and this note does not give legal advice.
Checks you can run yourself
These are practical checks, not a formal test, and they will not find everything.
- Use the keyboard only. Press Tab repeatedly. You should be able to reach every link, button and form field, in a sensible order, and always see which one is selected.
- Look at it on a real phone. Can you read the text and tap the buttons without zooming? Does anything jump as the page loads? (web.dev explains how images and embeds without reserved space cause that jump.)
- Check the text is readable. Pale grey on white, or text laid over a busy photograph, is hard for many people to read, in daylight especially.
- Look at the images. Images that carry meaning, such as a product photograph, need a short description for people who cannot see them. Purely decorative images should not clutter a screen reader.
- Read the headings. A page should have one main heading and a logical outline beneath it. That helps screen reader users and search engines alike.
- Try the form. Every field should have a visible label, and errors should say what went wrong in words.
Questions to ask a developer
- Which version and level of WCAG do you build to? (A reasonable answer names one, usually AA, and says what it means in practice.)
- How is it tested: keyboard, a screen reader, real phones, and when in the project?
- What happens when I edit the site later? Can I keep it accessible without help?
- Is there a statement of what the site does and does not support?
What the packages say
All three Website Craft Room packages list responsive layouts for desktop, tablet and phone, and accessible, semantic, crawlable HTML as ordinary build quality. They do not include a formal accessibility audit or a certificate of conformance. If your business needs one, say so when you ask for a quote, because it is separate work.