A practical accessibility review for a studio website
Check keyboard navigation, focus, form labels, contrast and image alternatives. Record reproducible problems before asking for an accessibility review.
Try one complete visitor task, such as finding a service and sending an inquiry. Record where the page prevents you from continuing. These checks can reveal problems; they cannot establish accessibility conformance.
Start with the keyboard
Put the pointer aside. Use Tab and Shift+Tab to move through the page, and the controls' normal keyboard commands to operate them. Follow the menu, a project link and the inquiry route. Check that you can tell which control has focus at every step.
- Does the order follow the page in a way you can understand?
- Can you open and close menus without losing your place?
- Can you reach every field, button and relevant link?
- Does anything trap the keyboard or hide the focused item behind a fixed header?
- Can you skip repeated navigation and reach the main content?
If a browser setting affects keyboard navigation, record it with the result. The W3C easy checks are a starting guide, with explicit limits on what a quick review can tell you.
Keep the question visible while someone answers
Check that every field has a visible label and that the label is associated with its control. A placeholder that disappears while typing does not replace a label. W3C's form guidance explains the relationship.
In a test copy, leave a required field empty and try an invalid email address. The error should identify what needs attention and how to correct it. Check that earlier answers remain available. Then correct the form and complete a labelled test inquiry.
Ask the builder how errors, waiting and success are announced to someone using assistive technology. A colour change or a spinner alone does not tell that person what happened. Include a screen-reader check in a fuller review.
Measure what the eye cannot settle
Check text over every relevant background, including image crops, hover states and errors. Use a contrast checker instead of judging the colour pair by eye. WCAG's minimum contrast criterion sets a 4.5:1 ratio for ordinary text and 3:1 for qualifying large text, with specified exceptions. Ask the reviewer to identify which text qualifies and which criterion is being checked.
Increase text size and browser zoom. Check whether navigation, captions and forms remain readable and usable. On a narrow screen, look for text hidden inside fixed-height panels and buttons that cover the field you are editing.
Repeat the inquiry task with the phone's keyboard open, in portrait and landscape where available. Read comparison tables one row at a time: can you still tell which question each answer belongs to? Check the longest heading and any pasted website address. Record the device, browser and settings you actually tested; “works everywhere” is not a test record.
Review each image's purpose. An informative photograph needs a useful text alternative; a decorative image can use an empty one. A linked image needs an understandable destination or action. W3C's image tutorial explains the cases. Keep service descriptions and credits as page text.
Make the problem reproducible
Page and device: where the problem occurred.
Task and steps: how to reproduce it.
Expected result: what the visitor needed to do.
Actual result: what stopped or confused them.
Owner and retest: who will fix it and how you will check again.
Keep the first report specific: “Tab moves behind the open menu and I cannot close it” is actionable. After a fix, repeat the full task, including the next page. Automated tools and this checklist are parts of a review; neither replaces evaluation across the site's content and interactions.