Website Accessibility Basics Every Business Should Fix First

Four critical accessibility fixes appear in nearly every violation report: missing alt text on images, unlabeled form inputs, skipped heading levels, and a missing language attribute. Automated scans catch these structural errors reliably, but determining whether the fix actually works requires manual verification that no scanner can provide.

Why alt text is the first thing automated tools flag

WCAG 2.2 SC 1.1.1 (Level A) requires alt text on every non-decorative image, sufficient to convey the same information (alttext.ai). Missing or inadequate alt text represents the single most common WCAG violation, appearing on 58% of home pages according to the WebAIM Million (testparty.ai).

The rule is straightforward to check in markup. If an <img> tag lacks an alt attribute, the scan flags it instantly. Decorative images need empty alt (alt="") , not missing alt. That distinction matters. An image that exists purely for layout or visual interest should have alt="" to tell screen readers to skip it. An image that communicates information, like a product photo or a chart, needs descriptive text.

What automated tools cannot do is judge quality. A scanner sees alt="image123.jpg" and moves on, because the attribute exists. Automated testing often can't determine if alternative text for an image is equivalent or if incorrect alternative text is a small or large barrier for someone with a disability (blog.pope.tech). The barrier is invisible to code inspection alone.

Do form labels exist, and are they actually connected?

Labels should be associated with their controls so that when the input is focused, the label is announced by screen readers (accessibility.huit.harvard.edu). The HTML is specific. A <label> element needs a for attribute that matches the id of the input it describes, like this: <label for="email">Email address</label> <input id="email" type="text" />.

Placeholder text alone doesn't satisfy WCAG labeling requirements (ivyforms.com). A field with placeholder="Enter email" but no associated label will pass a visual inspection and fail an accessibility scan, because the placeholder disappears once the user starts typing, and screen readers do not treat placeholders as persistent labels.

An automated scan verifies that the association exists. It finds inputs missing a label entirely, or labels with a for attribute that points to nothing. What it cannot verify is whether the label makes sense. A field labeled "Box 3" passes the structural test but communicates nothing useful to someone filling out the form.

Basic HTML labels are widely supported, so they're the best option for identifying form controls (boia.org). ARIA attributes like aria-label exist for complex cases where a visible label is impractical, but they add fragility. ARIA labels should supplement, not replace, proper HTML markup for maximum screen reader compatibility.

Heading order establishes structure, not just font size

The most important heading has the rank 1 (h1), the least important heading rank 6 (h6). Headings with an equal or higher rank start a new section, headings with a lower rank start new subsections that are part of the higher ranked section (w3.org).

Skipping heading ranks can be confusing and should be avoided where possible: Make sure that an h2 is not followed directly by an h4, for example. A page that jumps from h2 to h4 leaves screen reader users wondering if they missed a section. The outline breaks, and navigation becomes a guessing game.

Most violations come from treating headings as font controls. A designer wants larger text, reaches for h3 because it looks right, and skips h2. The visual result works. The structural result does not. Use the H1, H2, H6 tags as indicators of section headings and subheadings within a document, not just as formatting elements. Screen readers in particular may just scan a page for appropriate H1, H2 and H3 elements.

An automated scan identifies heading tags present in the markup and flags any sequence that skips a level. It cannot determine whether the heading text makes sense in context, whether the heading describes the content that follows it, or whether splitting a long section under multiple h3 tags improves usability. That requires reading the page as a human would.

What is the language attribute, and why does it matter?

WCAG 2.1 Success Criterion 3.1.1 requires that "the default human language of each web page can be programmatically determined." The attribute belongs on the opening <html> tag and looks like this: <html lang="en"> for English.

When a website's language is not specified, the screen reader will use the default language as set by the user. By setting the language of a web page, you ensure content is pronounced correctly. A screen reader configured for French will mispronounce English text unless the markup declares the language explicitly.

The fix is trivial to implement and trivial to check. A scanner looks for the lang attribute, verifies it exists, and checks whether the value is a valid BCP 47 language tag. You might assume that <html lang="en-uk" > refers to English as spoken in the United Kingdom, but the correct attribute is <html lang="en-gb">.

WCAG Success Criterion 3.1.1 (Language of Page) states that the language of the page must be clear to the computer. This is a level 'A' requirement, which means it's mandatory for basic accessibility. Missing the lang attribute is one of the easiest issues to fix and one of the most common oversights in new site builds.

What can and cannot be checked from markup alone

Research consistently shows automated tools catch only 30-40% of accessibility issues. The remaining 60-70% require human judgment because they involve semantic accuracy. A scanner identifies structure. It finds missing attributes, broken associations, invalid values, and skipped sequences. It cannot interpret meaning, judge relevance, or evaluate user experience.

Alt text is present or absent. The scanner sees both. Alt text is accurate or useless. The scanner sees neither. A form label is associated with the correct input or missing. The scanner finds the connection. A label reads "Field 12" instead of "Phone number". The scanner passes it.

While they reliably catch structural accessibility defects, they tend to miss contextual violations. They may also catch false positives that should be verified through manual testing. A heading structure can follow every sequencing rule and still fail to describe the content. A page can declare lang="en" while publishing primarily in Spanish.

Automated tools provide speed, consistency, and scale. They surface issues across thousands of pages in minutes, flag regressions before deployment, and document progress over time. The free AI-visibility check (/check) includes accessibility scoring alongside visibility metrics, giving you a baseline to work from.

What automation does not provide is confirmation that the fix solved the problem. That confirmation requires testing with the tools your users rely on: keyboard navigation, screen readers, browser zoom. The scanner tells you where to look. Manual review tells you whether what you built actually works. Running both is not redundant. It is the only path to compliance that holds up under real use.

For agencies managing accessibility across multiple clients, ActiScore's pricing (/pricing) includes white-labeled reporting from the Starter plan at $79 per month. The accessibility score measures eight categories, including the structural checks automation handles well and the context-sensitive issues the guide (/guide) covers in depth. Fixing the basics is table stakes. Understanding where automation ends and judgment begins is what separates a passing scan from a site people with disabilities can actually use.