Website Accessibility Basics Every Business Should Fix

Most websites exclude people without anyone realizing it. A missing label here, a low-contrast button there, and suddenly a chunk of your potential customers can’t actually use what you built.

Website Accessibility Basics: What You’re Actually Fixing

Accessibility isn’t one thing. It’s a collection of practices that make your site usable for people who navigate with a keyboard instead of a mouse, people who use screen readers, people with low vision, and people who are just on a cheap phone in bright sunlight. The fixes range from five-minute tweaks to structural changes, and you don’t need to tackle everything at once.

This post covers seven specific areas worth auditing. None of it is legal advice. What it is, though, is practical. These are the same issues that come up over and over when we’re auditing sites before a redesign at Web Lift Up.

Keyboard Navigation: Can Someone Use Your Site Without a Mouse?

Try this right now. Open your website, put the mouse aside, and press Tab. You should be able to move through every link, button, and form field in a logical order. If you get stuck, or if pressing Tab makes nothing obvious happen, that’s a problem.

Keyboard navigation matters for people who have motor impairments, but it also matters for power users who just prefer the keyboard. If your site is built on a JavaScript-heavy framework with custom interactive components, this is where things tend to break first. Dropdown menus, modal dialogs, and custom carousels are the usual culprits.

The fix usually involves making sure interactive elements are actual HTML buttons and links (not just styled divs), and that Tab order follows a sensible reading flow from top to bottom.

Focus States: Let People Know Where They Are

This one is closely connected to keyboard navigation. When you Tab through a page, there should be a visible indicator showing which element is currently focused. In a lot of redesigns, the default browser focus outline gets removed with a line like outline: none in the CSS because designers find it ugly. The problem is that nothing replaces it, so keyboard users are left guessing where they are on the page.

You don’t need to use the default browser ring. You can style focus states to match your brand. A colored border, a background highlight, an underline with offset — all of these work. What doesn’t work is no indicator at all.

If you’re auditing your site, Tab through every interactive element and confirm you can always see clearly where focus is sitting. If it disappears at any point, that’s the CSS file you need to open.

Color Contrast: The Fix That Also Helps Everyone

Low contrast between text and background is one of the most common accessibility failures, and it’s also just bad design. Gray text on a white background might look clean in a Figma mockup, but in practice it’s hard to read for anyone, not just people with low vision.

The Web Content Accessibility Guidelines recommend a contrast ratio of at least 4.5:1 for normal body text and 3:1 for large text (roughly 18px bold or 24px regular). You can check any color combination using free tools like the WebAIM Contrast Checker. Just paste in your background and text hex codes and see the number.

Buttons are a particularly common failure point. A light blue button with white text, or a yellow button with white text, often fails even though it looks fine at a glance. Run your primary call-to-action buttons through a contrast checker before you assume they’re fine.

Alt Text for Images: Not Just for Screen Readers

Alt text is the description attached to an image in HTML. Screen readers read it aloud to users who can’t see the image. Search engines also read it, which is why alt text for images matters for SEO as much as it does for accessibility.

The rule is straightforward: if the image conveys information, describe that information in the alt text. If the image is purely decorative (a background texture, a divider graphic), use an empty alt attribute (alt="") so screen readers skip it entirely.

A few specifics that trip people up. Don’t start alt text with “image of” or “picture of” — screen readers already announce that it’s an image. For a photo of your restaurant’s dining room with candles and wood tables, the alt text might be “Candlelit dining room with wood tables at Rosetta Kitchen.” For a product shot, describe what the product is and any relevant details visible in the photo.

Form Labels: Every Field Needs One

Forms are where a lot of sites quietly break for screen reader users. A common pattern is using placeholder text inside an input field instead of an actual label. It looks cleaner visually, but placeholder text disappears the moment someone starts typing, and it isn’t reliably announced by screen readers as a field label.

Every form field needs a <label> element that’s programmatically connected to the input using a for attribute that matches the input’s id. If you don’t want a visible label for aesthetic reasons, you can visually hide it with CSS while keeping it accessible. But the label has to exist in the HTML.

While you’re auditing forms, check error messages too. If a required field is left blank and you show a red border, that change alone isn’t perceivable by screen reader users. The error message needs to appear as text, and ideally it should be associated with the specific field that has the problem.

A Real Example: Indiana Photo Booth

When we redesigned Indiana Photo Booth, a photo booth rental company in Indianapolis, the old site had several of these issues stacked on top of each other. Low-contrast text on a dark background, images with no alt text, and a contact form where the fields were labeled only by placeholder text that vanished on click.

After the rebuild, every image got descriptive alt text (useful for both screen reader users and Google Image Search), the form got proper labels and visible error states, and the color palette was adjusted so all body text met the 4.5:1 contrast threshold. None of those changes required a dramatic visual overhaul. The site still looked like itself. It just worked better for more people.

This is the pattern we see consistently. Accessibility improvements usually don’t require throwing out the design. They require doing the foundational work correctly the first time.

Motion and Readable Content: Two More Worth Checking

If your site uses animations, scroll effects, or auto-playing video, check whether you’re respecting the prefers-reduced-motion media query. Some people experience nausea, dizziness, or seizure risk from motion on screens. The CSS for this is simple: wrap your animation declarations in a media query so they only run if the user hasn’t indicated they want reduced motion in their OS settings.

On the content side, readable text is part of accessible web design. That means body copy at a minimum of 16px, line spacing of at least 1.5 times the font size, and paragraphs that aren’t 800 pixels wide on a desktop monitor. Wide text columns are harder to track across. Keeping your content column between 600 and 750 pixels wide makes reading easier across the board.

Heading structure is part of this too. Your page should have one H1, followed by H2s for major sections, and H3s for sub-sections. Screen readers let users jump between headings to navigate a page, so a page with five H1s and no H2s isn’t navigable the same way.

Where to Go From Here

You don’t need to fix everything today. A reasonable starting point is to run your site through the free WAVE accessibility tool, look at what it flags, and start with the high-contrast and missing-alt-text items since those tend to be the quickest wins.

If you’re dealing with a site that has deeper structural problems — the kind where keyboard navigation is broken because the whole thing was built on non-semantic HTML, or where the form fields were never properly labeled — patching individual issues gets tedious fast. That’s the situation where a full redesign often makes more sense than ongoing repairs.

At Web Lift Up, the redesign process costs $499 flat with a working demo built before you pay anything. The build includes proper semantic HTML structure, accessible form labels, alt text best practices, and a clean codebase you own outright. If your current site is fighting you on accessibility, take a look at how the process works and get in touch at [email protected].