Which website accessibility checks should a small business start with?

Start by checking whether a customer can complete your website’s main task without a mouse, with enlarged content and with understandable form instructions. Follow the whole journey, not just the homepage. This website accessibility checklist helps you find barriers, record useful evidence and agree fixes with your developer. A clean automated report is not approval of the website.

Choose one complete customer journey

Hypothetical worked example: a Pune packaging supplier wants customers to request quotations. Its journey runs from the homepage through a service page to a form and confirmation. The form asks for contact details, packaging type and quantity. All findings below are invented examples, not Softglimmer client results. The same method works for bookings, purchases and international English-language websites.

1. Select the task: define success, such as submitting a quotation request and receiving confirmation.
2. Map the route: include representative pages, shared navigation, cookie notices, chat widgets and mobile menus.
3. Include different states: test unopened and open controls, empty forms, validation errors and successful submission.
4. Record conditions: note the page URL, browser, device, viewport size and zoom level.
5. Create an issue log: record steps, expected result, observed barrier, screenshot, owner and retest outcome. Avoid recording real customer data.

Complete the journey with a keyboard

Put the mouse aside. Tab moves between controls; Shift+Tab moves backwards. Enter activates links, while buttons should work with Enter and Space. Arrow keys operate controls such as radio groups and some menus. Focus means the element currently receiving keyboard input. Watch for a visible indicator and a sensible order throughout. Keyboard operation is a WCAG requirement, with a limited exception for inherently path-dependent input. [3]

• Task: open navigation, select packaging, use any dialog and submit. Check that closing a dialog returns focus sensibly and that focus cannot escape behind a modal dialog.
• Barrier: options open only on hover, focus disappears, or a dialog traps the customer with no keyboard exit. Sticky headers and chat widgets must not entirely hide the focused control. [4]
• Next action: ask the developer to repair or simplify the control. Retest the complete action, including opening, selecting, closing and continuing; merely reaching the button is insufficient.

Check headings and persistent field labels

Read the heading outline independently of the design, using an accessibility inspection tool or developer assistance. A simple service page might use h1 for “Packaging services”, h2 for “Packaging options” and h3 for “Food packaging”. These are HTML heading ranks, not font sizes. Use meaningful nesting, but do not treat every skipped rank as an automatic failure. Returning from a subsection to a higher-level section is normal. [5]

• Task: understand the service from its headings and identify every form control. Include search fields, checkboxes and dropdowns.
• Barrier: section titles are bold paragraphs, or “Phone number” appears only as placeholder text that disappears during entry.
• Next action: the content editor improves heading wording; the developer fixes markup and label associations. Explicit HTML labels connect a label’s for value with the field’s id. Request inspection of each control’s accessible name—the name exposed to assistive technology. [6]

Prefer visible, persistent labels. Explain required fields and accepted formats before submission, including whether telephone numbers need a country code. Do not assume every visitor has an Indian number. Placeholder examples can supplement labels but cannot replace them. Retest after entering data: the label and relevant instructions should remain available, and assistive technology should identify the field correctly. [6]

Trigger errors and recover from them

• Task: submit an empty form, enter a malformed email address and omit a required selection. Locate and correct each error using the keyboard.
• Barrier: a red border is the only warning, “Invalid input” gives no correction, or submission clears otherwise valid entries.
• Next action: ask the editor for specific wording and the developer for associated, discoverable errors. For example: “Enter an email address in the format name@example.com.” Retest correction and successful submission without re-entering valid data. [1][7]

New messages also need screen-reader testing. A screen reader conveys interface information through speech or braille. Check whether errors and the final confirmation are communicated, not merely displayed. An error summary or focus on the first invalid field can help, but the implementation needs testing. If nobody on your team uses a screen reader confidently, seek experienced assistance rather than interpreting silence as success. [7]

Measure contrast across useful states

Use a contrast checker rather than judging colours by eye. WCAG minimum text contrast is 4.5:1 for ordinary text and 3:1 for large text: at least 18 point, or 14 point bold. Essential visual information identifying controls, states and meaningful graphics generally needs 3:1 against adjacent colours. Exceptions include logos and incidental text; inactive controls and unmodified browser controls have relevant exceptions too. [8][9]

• Task: read labels, helper text, errors and button text; identify controls and their relevant states.
• Barrier: pale quantity instructions or an unclear control boundary makes completion difficult. Check text over photographs and gradients at the least-contrasting area.
• Next action: ask the designer to adjust colour pairs and the developer to apply them across states. Preserve brand colours where possible, but prioritise readable functional content. Retest measured values and the journey.

Test enlargement and reflow separately

Text enlargement and reflow answer different questions. Text must enlarge to 200% without losing content or functionality, with exceptions for captions and images of text. Reflow means content rearranges into the available space. For vertically scrolling content, test an effective width of 320 CSS pixels without two-dimensional scrolling, except where a two-dimensional layout is necessary. A 1280-CSS-pixel viewport at 400% browser zoom provides that width. [10][11]

• Task: enlarge text to 200%, using text-only zoom where available, and repeat the enquiry. Separately test reflow at 320 CSS pixels. Browser zoom is also useful, but check that text actually enlarges.
• Barrier: fixed-height fields clip labels, buttons overlap, or the contact widget covers Submit. Test intermediate zoom levels too.
• Next action: ask the developer to allow wrapping, stacking and appropriate overlay placement. Retest menus, errors, dialogs and submission. Phone pinch-zoom is not a substitute; it often magnifies rather than rearranges content.

A genuinely two-dimensional comparison table may need a separate scrolling area. That exception does not justify sideways scrolling across the whole page. Also test an actual phone and each language version you publish: translated labels may wrap differently. These practical checks complement, rather than replace, the specified enlargement and reflow tests.

Use automated findings to support the fix-and-retest loop

Run an automated checker such as Lighthouse on representative pages, and use state-aware checks after opening menus or triggering errors. Investigate findings rather than chasing a score. Tools can detect some missing labels and contrast problems, but cannot prove that headings make sense, errors explain recovery or the journey works. Combine automated, manual and assistive-technology testing. [12]

Fix blocked navigation and submission first. Then assess severity, reach and frequency across remaining barriers. Contrast or poor structure can prevent access; neither is automatically cosmetic. Shared-template fixes may help many pages, while third-party widgets may need replacement. Record remaining scope honestly: “These checks passed on these pages and states”, not “The website is fully accessible”.

Next step: choose one journey, complete the issue log and agree owners plus a retest date. Arrange specialist evaluation for complex interactions, unresolved barriers or a formal conformance goal. Include experienced assistive-technology testing and disabled-user evaluation where feasible. Image alternatives, multimedia and other requirements remain outside this starter review. For wider release planning, see /insights/website-launch-checklist; for ongoing responsibilities, see /insights/website-support-handover. [1]

Common questions before you begin

This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.