Accessible by Default: What WCAG Compliance Actually Requires From Your Frontend

Web accessibility is sometimes treated as irrelevant (“we’re a small business, this doesn’t apply to us”) or intimidating (“we could get sued”). Neither reaction is particularly useful. Web accessibility best practices help you build websites that more people can use, including people with visual, auditory, motor, and cognitive disabilities.

This guide explains what the Web Content Accessibility Guidelines (WCAG) cover, common frontend accessibility issues, and practical checks you can apply during development instead of trying to retrofit accessibility later.

Note: This article provides practical technical information, not legal advice. Accessibility obligations vary by jurisdiction and context. Consult a qualified legal professional if you need advice about your specific obligations.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) are internationally recognized guidelines for making web content more accessible to people with disabilities. WCAG is organized around four principles, often remembered as POUR:

• Perceivable: Users must be able to perceive the information presented, including through alternatives such as text descriptions or captions where appropriate.

• Operable: Users must be able to navigate and operate interactive elements, including with a keyboard or assistive technology.

• Understandable: Content, instructions, forms, and navigation should be clear and predictable.

• Robust: Content should work with current and evolving browsers and assistive technologies.

For the current technical requirements, refer to the official WCAG 2.2 guidelines. Meeting a checklist alone does not guarantee conformance; the applicable criteria and evaluation scope matter.

Common frontend accessibility issues

Common accessibility issues include the following:

1. Missing or unhelpful image alternative text

Informative images need text alternatives that convey their relevant meaning. Text such as image1.jpg usually does not help someone using a screen reader. For purely decorative images, use an empty alt="" so assistive technology can skip them.

<!-- Informative image -->
<img src="/team.jpg" alt="The product team collaborating around a table">

<!-- Decorative image -->
<img src="/decorative-divider.svg" alt="">

Choose alt text based on the image's purpose in context rather than describing every visual detail.

2. Insufficient text color contrast

Light gray text on a white background can be difficult for many people to read. Under WCAG 2.2 Level AA, the usual minimum contrast ratio is 4.5:1 for normal text and 3:1 for large text, subject to defined exceptions.

Use a tool such as the WebAIM Contrast Checker to check foreground and background color combinations. Do not rely on color alone to communicate errors, status, or other important information.

3. Form fields without persistent labels

Placeholder text should not be the only label for an input. It disappears as users type and may not provide a sufficiently clear, persistent description.

<label for="email">Email address</label>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  required
>

Make sure labels identify each field and that validation errors are clearly communicated and associated with the relevant input.

4. Keyboard navigation problems

Menus, dialogs, dropdowns, and other interactive components should be usable without a mouse. Test the page using the keyboard alone:

• Use Tab and Shift+Tab to move between interactive elements.

• Use Enter or Space where appropriate to activate controls.

• Confirm that dialogs and menus can be opened and closed by keyboard.

• Ensure focus is not trapped unexpectedly and that users can move away from components.

• Check that focus moves sensibly when a dialog opens and closes.

Use native HTML controls where possible; they generally provide useful keyboard behavior by default.

5. Missing or invisible focus indicators

Keyboard users need to see which element currently has focus. Avoid removing the browser's default outline unless you replace it with a clearly visible alternative.

:focus-visible {
  outline: 3px solid #165DFF;
  outline-offset: 3px;
}

Check that focus indicators remain visible against the component and surrounding background in every theme and state.

Before and after: an accessible contact form

Before: A contact form uses placeholder text as its only label, has low-contrast text, and uses a generic div with a click handler as its submit control.

After: Each field has a persistent, programmatically associated <label>, text meets the relevant contrast requirements, and the form uses a real <button type="submit">. The control can be reached and activated by keyboard, with a visible focus indicator.

<form action="/contact" method="post">
  <label for="contact-email">Email address</label>
  <input
    id="contact-email"
    name="email"
    type="email"
    autocomplete="email"
    required
  >

  <button type="submit">Send message</button>
</form>

The visual difference can be small, but semantic HTML and clear labels make the form easier to use with different input methods and assistive technologies.

Practical website accessibility checklist

Use this checklist as a starting point before launch:

• Informative images have meaningful alternative text; decorative images use alt="".

• Text and interface elements have sufficient contrast for the applicable WCAG criteria.

• Every form field has a visible, programmatically associated label.

• Form errors are explained in text and associated with the relevant fields.

• The page can be navigated using a keyboard alone.

• Keyboard focus is visible and is not unexpectedly trapped.

• Links and buttons use semantic HTML elements for their intended purpose.

• Headings follow a logical hierarchy, with heading levels chosen for document structure rather than visual size.

• Interactive components expose accessible names, roles, states, and values as appropriate.

• The page is tested at different viewport sizes and with relevant assistive technologies.

• Automated checks are supplemented with manual testing; automated tools cannot identify every accessibility issue.

Why accessibility should be built in from the start

Many accessibility improvements are straightforward when included in normal development habits. Choosing a semantic <button> instead of a clickable <div>, associating a label with a form field, and preserving visible focus styles can prevent avoidable problems before they reach production.

Retrofitting accessibility into a completed site can require reviewing components, interactions, content, and design decisions across many pages. Treating accessibility as part of design, development, and quality assurance helps teams find issues earlier.

For a broader pre-launch review, read the pre-launch website audit checklist. If you need help building accessible interfaces, learn more about frontend development services.

Further resources

• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C

• WebAIM Contrast Checker

This article is for practical educational purposes and is not legal advice. Accessibility requirements depend on the relevant jurisdiction, organization, and context.