Build for More People: A Weekend Accessibility Audit for Your First Website

Accessibility Is Part of the Product

Your first website may be a storefront, a portfolio, an application form, or the only place someone can learn what you offer. If a visitor cannot use a keyboard to reach the contact button, understand an error message, read low-contrast text, or follow a video without sound, the barrier is not outside your business. It is inside the experience you built.

That matters to more people than many founders realize. The Centers for Disease Control and Prevention reported in 2024 that more than one in four U.S. adults—over 70 million people—reported having a disability. Disability is also broader than a visible diagnosis. A person may have a permanent, temporary, or situational limitation involving vision, hearing, mobility, speech, memory, attention, or another part of daily life.

Accessibility is therefore not a favor added after “real” customers arrive. It is a way to respect people’s time, widen access to opportunity, and make the product more resilient for everyone. Clear labels help a screen-reader user and someone filling out a form on a stressful day. Captions help a Deaf viewer and a commuter who cannot play audio. A visible focus indicator helps a person who cannot use a mouse and a power user who prefers a keyboard.

This guide offers a practical weekend starter audit for a founder, student, job seeker, or small team with limited time and money. It will help you find important barriers and build a prioritized repair list. It is not a complete accessibility evaluation, a WCAG conformance claim, or legal advice. Requirements vary by context and jurisdiction, and a qualified accessibility or legal professional can help when the stakes or obligations exceed your expertise.

Start With Three Journeys, Not Every Page

Trying to “make the whole site accessible” in one weekend is too vague to guide useful work. Start with the three journeys people most need to complete:

Understand: Can a visitor tell who you serve, what you offer, and what it costs or requires?
Act: Can the visitor contact you, apply, buy, register, download, or request help?
Recover: If something goes wrong, can the visitor understand the problem, preserve their work, and continue?

For each journey, write down every page, dialog, form, confirmation, and error state a person encounters. Include the mobile version. If your site sends an email or opens a third-party scheduler or payment page, include that handoff too. A core journey is only as accessible as its hardest step.

Then create a simple issue log:

Journey and page	Barrier observed	Person or task affected	Priority	Owner	Retest result
Contact form	Error shown by color only	People who cannot distinguish the color may not know what to fix	P1	___	___

Describe what happened without diagnosing a person. “Focus disappears after opening the menu” is more useful than “bad for disabled users.” Specific evidence makes the repair easier to assign and verify.

Saturday Morning: Use the Site Without a Mouse

Put the mouse aside. Starting at the browser address bar, use Tab to move forward, Shift + Tab to move backward, Enter or Space to activate controls, arrow keys where appropriate, and Escape to close menus or dialogs.

Complete all three journeys and ask:

Can you see where keyboard focus is at every step?
Does focus move in an order that follows the page?
Can you reach and operate every link, button, menu, field, and dialog?
Can you move away from every component, or does the keyboard become trapped?
When a dialog opens, does focus move somewhere useful and return sensibly when it closes?
Does a sticky header, cookie banner, or chat widget cover the focused control?
Can someone skip repeated navigation and move to the main content when needed?

Record the first point where each journey becomes confusing or impossible. That is likely a high-priority issue. A visitor should not need perfect dexterity, a particular input device, or hidden knowledge of your interface to do business with you.

Saturday Afternoon: Make the Page Survive Magnification

Open each journey in a desktop browser and increase zoom to 200%, then 400%. Narrow the window until it resembles a phone. Do not judge whether the result looks as polished as the original. Ask whether the content and controls still work.

Look for:

text, buttons, or form fields clipped by fixed-height containers;
content that overlaps or disappears;
controls pushed off-screen with no practical way to reach them;
text that requires side-to-side scrolling to read a paragraph;
menus, dialogs, or notices that no longer fit the viewport; and
layouts that prevent a person from increasing text size.

Zoom and reflow problems often come from shared styles. Fixing one navigation, card, dialog, or form component may remove the same barrier from many pages. That makes accessibility work especially valuable for a small team: a focused repair can improve every future use of the component.

Next, inspect the page structure. Each page should have a descriptive title, one clear main heading, and headings that describe the sections beneath them. Link text should make sense in context; a list of identical “click here” links forces people to guess. Use real HTML buttons for actions, links for navigation, and properly associated labels for form controls rather than relying on visual styling alone.

You do not need to memorize every semantic element before improving anything. Begin by asking whether the code communicates the same relationships that the visual design suggests.

Sunday Morning: Review Forms, Color, Images, and Media

Forms are where opportunity often becomes action—and where a small barrier can stop the entire journey.

For every field and control, check that:

the label remains visible after someone starts typing;
required formats and instructions appear before they are needed;
an error explains what happened and how to fix it;
the error is not communicated by color alone;
entered information is preserved when an error occurs;
status or success messages are available to assistive technology; and
authentication does not depend only on remembering, transcribing, or solving something unnecessarily difficult.

Next, review the visual experience. Text and meaningful interface elements need sufficient contrast against their backgrounds. Color can reinforce meaning, but it should not carry meaning alone. Links inside a paragraph, selected states, errors, charts, and availability indicators need another cue such as an underline, icon, pattern, or plain-language label. Also check whether small targets or tightly packed controls require unusually precise movement.

Now review every image and media file in the three journeys:

Informative images need concise alternative text that communicates their purpose in context.
Decorative images should usually have empty alternative text so they do not add noise.
Linked images need alternative text that describes the action or destination.
Complex charts or diagrams need the important conclusion and data available in text.
Prerecorded video needs accurate captions; audio-only content needs a transcript or equivalent.

Do not begin every description with “image of.” Assistive technology already identifies the element as an image. Describe what the visitor needs to know or do. The same photo may need different alternative text on a team page than on a product page because its purpose has changed.

Finally, read the site as a person who is tired, distracted, new to the topic, or using a second language. Replace unexplained jargon. Break long instructions into steps. Put essential details before a person commits. Keep navigation and help in predictable locations. If motion starts automatically, provide a way to pause it when the movement is not essential.

Plain language does not make an idea less intelligent. It makes the next move easier to find.

Use Automated Tools as a Flashlight, Not a Certificate

Run a reputable automated accessibility checker on the pages in your three journeys. It can quickly flag some missing labels, contrast problems, structural errors, and invalid attributes. Save the results in your issue log, remove duplicates, and verify each issue in the actual interface.

Then keep testing manually.

The World Wide Web Consortium is explicit: no tool alone can determine whether a site meets accessibility guidelines. Many checks require human judgment, and a clean automated report does not prove that a website is accessible. The U.S. Department of Justice similarly warns that automated checkers and accessibility overlays must be paired with manual review.

Be cautious of a product that promises instant compliance by adding one line of code. A tool may assist with a narrow task, but it cannot reliably repair unclear content, a broken journey, misleading interaction, or every underlying code problem. Spend scarce money only after you understand the barrier, the proposed fix, and how a person will verify that the fix works.

Include People With Disabilities—Respectfully and Fairly

If you can, invite people with disabilities to evaluate an early version or a core journey. The goal is not to ask one person to approve the entire site. It is to learn where real people encounter friction while using their own strategies and assistive technology.

W3C recommends involving users throughout design and development while also evaluating against accessibility standards. Both matter. A standards review can identify barriers one participant did not encounter; user evaluation can reveal context and usability problems a checklist missed.

Approach this research as professional expertise:

compensate participants fairly whenever possible;
explain the task, what will be recorded, and how findings will be used;
ask about access needs for the session, not private medical details you do not need;
let the participant choose the technology and pace that work for them;
do not treat one person as a representative of every disability; and
report the barrier in the product, not a “failure” by the participant.

If recruiting participants is not yet possible, do not delay every repair. Fix the barriers you can verify now, seek guidance from disabled creators and accessibility professionals, and budget for broader evaluation as the product grows.

Turn Findings Into a Repair Plan

At the end of the weekend, sort each confirmed issue by its effect on the journey:

P0 — Blocks the task: A person cannot understand the offer, complete the action, or recover. Examples include an unreachable submit button, an unlabeled payment field, or a dialog that traps keyboard focus.
P1 — Creates serious friction or misunderstanding: The task may be possible, but the person must work around missing instructions, weak contrast, unclear errors, or inconsistent behavior.
P2 — Improves quality and consistency: The issue should be fixed, but it does not currently stop a core journey.

Severity is about impact, not how easy the repair looks. A one-line code change can remove a P0 barrier. A larger visual cleanup may still be P2.

Choose the smallest responsible release:

Fix every P0 issue you control.
Fix shared components before isolated instances.
Assign an owner and date to each remaining P1 issue.
Retest the original journey with the same browser, keyboard steps, zoom, and assistive technology used to find the problem.
Document what changed and what still needs expert or user evaluation.

Do not close an issue because the code changed. Close it when the person’s task works.

Your Weekend Accessibility Scorecard

By Sunday evening, aim to have:

selected three essential user journeys;
completed every journey with a keyboard only;
reviewed focus visibility and order;
tested zoom, reflow, and a narrow viewport;
checked page titles, headings, link purpose, and form labels;
reviewed errors, instructions, and status messages;
checked contrast and information communicated through color;
reviewed alternative text, captions, and transcripts;
run an automated scan and manually verified its findings;
created a P0, P1, and P2 repair backlog;
fixed or contained blockers you control; and
recorded where professional review or user research is still needed.

That is not the end of accessibility work. It is a credible beginning and a process you can repeat before every meaningful release.

Build the Doorway Into the Plan

Founders with limited capital are often told to move fast and add quality later. But when “later” means rebuilding a product after real people have already been excluded, the shortcut can cost more than thoughtful foundations.

You do not need a large team to begin. You need a willingness to test beyond your own habits, listen without defensiveness, fix the barriers with the greatest impact, and keep the work visible in the product backlog.

An accessible experience tells people: you were considered before you arrived. That is good design, responsible engineering, and a practical expression of the belief that opportunity should not depend on having the “right” body, device, or way of processing information.

Choose one journey. Put away the mouse. Find the first barrier. Make the next move possible.

Give back. Never give in.