Blog Article · Web Design

Website Accessibility: A Practical WCAG Checklist

KepezWeb Team Last updated: 7 min read Web Design
Website Accessibility: A Practical WCAG Checklist

Website accessibility helps visitors access content and complete tasks using different tools. This guide helps you apply WCAG-based checks for keyboard navigation, contrast, alt text, forms and readability to your business website.

A visitor may be unable to reach your menu using a keyboard, hear a form field's name or make out a price because of low contrast. These barriers can cause potential customers to abandon a quote request, appointment booking or purchase.

Website accessibility helps people with different abilities and browsing conditions complete tasks on your site. It is not just about visitors who use screen readers. A temporary injury, bright sunlight, a small screen or a slow connection can also affect access.

What does website accessibility offer your business?

WCAG, the Web Content Accessibility Guidelines, is an international framework. WCAG 2.2 gives designers, content teams and developers a shared set of checkpoints. Most business websites use Level AA as their initial target.

  • Perceivable: Visitors should be able to understand text, images and media through different senses.
  • Operable: Visitors should be able to complete every task using a mouse, keyboard or assistive technology.
  • Understandable: Headings, instructions and error messages should provide clear guidance.
  • Robust: Code should work consistently with browsers and assistive technologies.

These principles apply primarily to components rather than individual pages. Start by reviewing recurring elements such as menus, pop-ups, search tools, filters and forms. Assess legal requirements separately based on your contracts and sector.

A Level AA target alone is not enough to substantiate an accessibility statement. Keep test records for each page and component, and extend their coverage to include every new feature.

Define your audit scope around visitor journeys

Do not start by checking every page. Choose representative journeys based on what visitors want to accomplish. For a service business, quote forms, phone links and appointment booking matter most. For an online shop, focus on product search, filtering, the basket and checkout.

For example, when requesting a quote, a visitor opens a service page, reviews a package and submits a form. Headings, links, selection fields and error messages must work together throughout this journey. Checking the form alone is not enough.

Record the starting point, decision points and completion point for each journey. Group pages that use the same template. This helps you see how a fault in one component affects the entire site.

Do not limit your review to the homepage. Search results, empty baskets and error pages can also interrupt a task. Test cookie preferences as a separate scenario.

  • Page URL and component name.
  • The task the visitor wants to complete.
  • The device or assistive technology on which the barrier occurs.
  • The relevant WCAG criterion and priority for resolving the issue.
  • The person responsible, acceptance criteria and target date.

Add these items to your web design brief for new projects so that design and development teams work towards the same acceptance criteria.

Complete every task using a keyboard

People who do not use a mouse navigate the entire page with a keyboard. Keyboard testing is the quickest manual step in an accessibility audit. Refresh the page and complete the target task using only Tab, Shift+Tab, Enter, Space and Esc.

Custom components are a common source of problems here. Anything that looks like a button should offer the same action through the keyboard. Keyboard focus should not jump to an invisible or closed element.

Keep focus visible and in a logical order

Every focusable element should have a clear focus indicator. The focus order should match the reading order on screen. A cookie notice or fixed chat window should not obscure the focus ring.

  • Make the focus colour stand out from the background.
  • Compare the focus order with the visual order.
  • Verify that focus does not jump to invisible elements when the page loads.

Restore focus when pop-ups close

Dropdown menus, tabs and modal windows—dialogue boxes that appear on screen—need separate testing. Enter and Space should activate buttons. Esc should close the pop-up. While a modal is open, focus should remain inside it. When it closes, focus should return to the button that opened it.

Add a skip-to-main-content link as the page's first keyboard stop, and make it visible when it receives focus. Use the button element for controls that perform an action. Do not simply add a click event to a div, a generic container element.

Check colour contrast and readability

Colour should not be the only way to convey meaning. Do not identify an invalid field solely with a red border. Add error text, an icon or a field heading too. Apply the same approach to stock availability, discounts and required fields.

Measure contrast for each component

For Level AA, aim for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Also check for a 3:1 ratio on button edges, form field boundaries and graphical icons.

Check contrast separately in your design tool and on the live page. Transparent layers, image backgrounds and dark mode options change the final appearance. Do not rely solely on colour codes in the design file.

Increase browser zoom to 200%. Check that text does not overlap and that horizontal scrolling is not required. Do not rely solely on colour differences for links within text. Add an underline or another visual cue.

Break up text with headings and write short paragraphs. Support line spacing of at least 1.5 times the font size. Do not squeeze text into fixed-height boxes.

Use alt text to convey an image's purpose

Screen readers use alt text to convey an image's function or information. Alt text does not describe every pixel. It communicates what visitors need to understand from the image.

Choose an approach based on the image type

  • Informative image: Briefly describe the subject and context.
  • Functional icon: Name the action the icon triggers.
  • Decorative image: Use empty alt text so screen readers do not announce unnecessary information.
  • Chart or diagram: Explain the main finding in the text. Present the data as a list if needed.

If an image contains text, provide that same text on the page. Do not replace alt text with a filename or a string of keywords. When uploading informative images, do not leave the alt text field empty.

Let content editors specify an image's purpose. The system should preserve empty alt text when an image is marked as decorative. For product images, include distinguishing details such as colour, model or package contents. Do not repeat the same information for every image.

Test form labels and error handling

Contact, quote and payment forms directly affect business results. Every input field should have a clear label. Placeholder text alone is not a substitute: it disappears when the user starts typing.

Give fields clear names

  • Associate fields such as name, email and phone with a label element.
  • Group radio buttons and checkboxes within a fieldset element.
  • Use a legend element to describe the group of options.
  • Indicate required fields with text as well as an asterisk.
  • Set the autocomplete attribute for name, address and phone fields.

Explain the error and how to fix it

When users submit a form, clearly identify which field has a problem. Do not rely solely on red colouring or an exclamation mark. Display an error summary above the form and move focus to it. Preserve entered information except passwords.

Links to the Turkish Personal Data Protection Law (KVKK) notice, pre-contractual information and contracts should also open using the keyboard. Each link's name should identify the document it opens.

For e-commerce websites with address, delivery and card payment steps, review time limits too. Visitors should be able to request more time or see a time-limit warning before starting.

Pre-launch website accessibility checklist

Automated scanning tools identify some code issues, but they cannot assess focus order or the context of text on their own. For every release, combine automated scans with manual review and realistic task scenarios.

  • Check the page language, heading order and skip-to-main-content link.
  • Write each link so its purpose is clear even without the surrounding text.
  • Test the Tab order, focus visibility and Esc behaviour.
  • Measure contrast ratios for text, components and colours that indicate a state.
  • Review image alt text.
  • Review video captions and transcripts for audio content.
  • Submit the form with both invalid and valid information. Listen to error and success messages using a screen reader.
  • Test the main journey on a mobile screen, at high zoom and with at least one screen reader.

Assign an owner, priority and resolution date to every issue you find. Address barriers in areas such as the main menu or checkout first. Include alt text and heading rules in your publishing guide for teams that add content.

Build checks into your workflow

Do not leave accessibility until launch day. Approve colour and component-state examples in the design file. During development, review semantic HTML—markup that conveys meaning—and keyboard behaviour. After launch, keep regular records of user feedback.

This approach brings content, design and development decisions together around a shared goal in corporate web design projects.

Frequently Asked Questions

What is WCAG?

WCAG provides criteria for making web content accessible. For new projects, document the WCAG 2.2 criteria and Level AA target at the outset. The team should include this target in design, development and pre-launch testing.

Is WCAG Level AA enough for a business website?

Level AA is a practical starting point for most business websites. However, public bodies, financial services and projects governed by contracts may have additional requirements. Review the relevant legislation and contract terms with your legal team.

Is an automated accessibility scan enough?

No. Tools can identify missing labels and some contrast issues. Use human testing to assess keyboard order, the quality of descriptions and error handling. A realistic task scenario reveals problems that tools cannot detect.

Can I make an existing website accessible without redesigning it from scratch?

First, identify the most frequently used templates and conversion journeys. By fixing shared components, your team can improve many pages at once. Then work through content and media assets in stages.

Conclusion and Next Steps

For a new website or redesign, include accessibility decisions in the design and development plan from the outset. Share your page flow through our quote request form to help us define the project scope.

Share this article