Website Accessibility Checklist for Small Business Owners
Website accessibility means helping people use your content and complete tasks through different devices, abilities and ways of interacting. Start by checking navigation, keyboard controls, headings, readable text, image descriptions, forms and media. Test real customer journeys and record barriers that need fixing. This checklist is a practical starting review, not proof of legal compliance or a complete accessibility evaluation. More detailed assessment may be needed for the website and its users.
Start with the tasks customers need to complete
Accessibility review is most useful when connected to real tasks. A customer may need to compare services, read package details, send an enquiry or book an appointment. Write a small set of those journeys and identify the pages and controls involved. This gives the team a practical starting scope instead of treating accessibility as a cosmetic setting added after the design.
Consider different ways people interact. Some visitors use a keyboard, a screen reader, magnification or voice input. Others may have a temporary injury, poor lighting or difficulty processing dense information. You do not need to assume every visitor has the same experience. The aim is to make the essential content and actions usable through more than one narrow pattern of interaction.
For example, a hypothetical training provider could prioritise finding a course, reading its requirements and sending an application. If the course information exists only in an image, the menu works only on hover or the application form has unclear errors, those are concrete barriers to investigate. Record the problem in terms of the blocked task, then assign the appropriate content, design or development work.
Check page titles, headings and content order
A page should have a descriptive title and a clear main subject. Supporting headings should organise the information into useful sections. A visitor scanning headings should be able to understand where the service scope, pricing guidance and contact route are located. Avoid using a heading solely because its default visual size looks convenient; the underlying structure should still make sense.
Review the reading order as well as the visual arrangement. A two-column design may look logical while presenting content in an unexpected sequence to someone using assistive technology. Ask the developer how the main page regions and headings are represented. The W3C page structure tutorial explains why clear structure supports navigation and orientation.
Use meaningful link text. Several links labelled “click here” provide little context when read separately. “View website packages” or “Read the maintenance checklist” tells the visitor what to expect. Keep related information together and avoid forcing a reader to reconstruct a sentence from scattered decorative fragments. Our website copywriting guide can help improve clarity while preserving useful detail.
Operate menus and controls without a mouse
Try the main customer journey using the keyboard. Move through links and controls, open the navigation, select a service and reach the enquiry action. You should be able to see where focus is and operate the relevant controls without guessing. If focus disappears into a hidden area or becomes trapped in a component, record the exact step and page.
Check dropdown menus carefully. A submenu should not depend exclusively on a mouse hovering over a small area. The open state and the relationship between the trigger and menu need to be understandable. W3C’s menus tutorial provides guidance on structure and operation. A familiar visual appearance does not by itself establish that the menu works through different input methods.
Include dialogs, galleries and sticky elements in the review. A modal should have an obvious close control and a sensible focus path. A fixed contact bar should not cover the button currently in use. Test the complete interaction rather than declaring a component accessible because its first button can be reached. The business owner can identify the failure while the implementation details are handled by the responsible developer.
Review readability, contrast and zoom behaviour
Read the body text on a phone and a larger screen. Check the size, spacing and contrast against the actual background. Text over a photograph may be readable in one crop and unclear in another. Pale labels and thin fonts can be difficult to use even when they look elegant in a presentation. Test the final design with the real content rather than approving only a colour palette.
Increase the browser zoom and check whether information remains available. Navigation, buttons and text should not overlap or disappear in a way that blocks the task. Long tables and fixed-width sections deserve particular attention. A layout may need a different presentation at narrower widths rather than forcing the reader to move horizontally through ordinary content.
Do not use colour alone to communicate meaning. An error should include understandable wording, not only a red outline. A selected category should have a clear state beyond a subtle shade change. Use appropriate contrast checking and detailed guidance when evaluating the design. The W3C Easy Checks resource is a starting point, with an explicit reminder that a quick review does not cover every barrier.
Give images the right text alternative
Decide what each image does in its specific context. A product photograph may show information a customer needs. A diagram may explain a process. A decorative background may add atmosphere without adding information. The text alternative should reflect that purpose rather than describing every visual detail or repeating the same keyword across all images.
For an informative image, describe the information needed to understand the page. For a complex chart or diagram, a short alternative alone may not convey the full meaning, so include the important explanation in nearby text. A graphic containing package details should not be the only place those details exist. The W3C images tutorial offers examples based on image purpose.
Review images used as links or buttons as well. The accessible description should communicate the action or destination where appropriate. A logo linking home needs a useful name, while a portfolio thumbnail should identify the example it opens. Avoid using filenames as descriptions. Keep the review connected to the reader’s task: what information would be missing, or what action would be unclear, if the person could not see this image?
Make forms understandable before and after an error
Every form control needs a clear label and a purpose the visitor can understand. Placeholder text can provide an example, but it should not be the only label because it disappears during entry. Explain required information and any special format before the person submits. Group related choices in a way that preserves their relationship.
Test an incomplete or invalid submission. The response should explain what needs attention, identify the relevant field and preserve information that does not need changing. “Something went wrong” gives little help. A useful message tells the customer how to continue. The W3C forms tutorial covers labels, instructions, validation and notifications in more detail.
Review the amount of information requested. A simple consultation enquiry should not demand unrelated details. If the form prepares a message in another app rather than sending it, explain that handoff clearly. After a successful submission, say what happened and what comes next. These are content and operational decisions as well as technical ones, so the team receiving enquiries should participate in the review.
Check video, audio, motion and interruptions
A video should not be the only way to understand an essential service or instruction. Provide an appropriate text explanation and review caption and transcript needs for the media being used. Check that the player controls can be found and operated. Automatic audio and movement can interfere with a visitor’s ability to read or use the page, especially when several elements compete for attention.
Review motion according to its purpose. A short transition can clarify a state change, while constant decorative animation may add little information. Ask whether the experience respects reduced-motion preferences and whether essential content remains available when animation is reduced. Do not hide the main offer behind an interaction that a visitor must discover or wait through before contacting the business.
Also examine popups and timed messages. A newsletter invitation, cookie notice or promotion should not make the main task impossible to complete. Check close controls, focus behaviour and the layout on small screens. The practical question is whether the component helps the customer or interrupts access to information they need. Our mobile website checklist helps review these interactions in a limited screen area.
Combine tools, manual checks and an issue log
Automated tools can identify some problems, but they cannot judge every interaction or the usefulness of every description. Use them alongside manual task testing and, where practical, feedback from people who use different access methods. A clean tool report is not a complete accessibility evaluation, and a badge should not be treated as a substitute for checking the actual site.
Create an issue log with the page, task, observed barrier, owner and status. Prioritise problems that prevent important actions or access to essential information. Fix the cause, then repeat the affected journey. Keep enough detail that another person can reproduce the issue without guessing what the original reviewer meant. This makes review work more useful than a long list of vague concerns.
Accessibility also needs maintenance. New images, videos, forms and page layouts can introduce barriers after the initial build. Include relevant checks in the publishing process and the maintenance routine. BrandNerds can help review content and customer journeys through our website services. Describe the tasks your visitors need to complete and the problems already observed so the work can be scoped around practical improvements without unsupported compliance promises.
Common questions
Does passing this checklist prove my website is accessible?
No. It is a starting review of common barriers, not a complete evaluation or legal compliance statement. A more detailed assessment may need specialist knowledge, representative pages and interactions, and input from people using assistive technologies.
Can an accessibility plugin fix the whole website?
A tool may help with particular tasks, but it cannot replace clear content, correct structure and working interactions. Review what it actually changes and test the customer journeys. Do not assume that installing a widget resolves every accessibility problem.
What should a small business fix first?
Start with barriers that block essential information or actions, such as an unusable menu, an unlabelled form or a contact control that cannot be operated. Record the issue, assign an owner and retest after the fix, then continue through the remaining priorities.
