Skip to main content
WCAG & BFSG Relevant Website Assessment

How to test website accessibility

Start by choosing the pages and user flows to test. Combine automated scans with manual checks, and record who will fix each barrier and how you will verify the fix.

Product Managers & Product Owners
Web Developers & QA Teams
Agencies & Web Design Providers
Compliance & Legal Officers

The free scan provides an initial snapshot of one URL. This guide helps you plan the full test scope and manual checks.

Scan one URL for free
Test scope

Which accessibility checker fits your test?

Use a contrast checker to compare two colors. A URL scan examines the reachable page in its loaded state. Open dialogs, trigger form errors and sign in to protected areas before scanning those states again.

Choose the method for the task. Add keyboard and screen-reader tests to automated findings.

MethodWhat it helps withWhat to check next
Contrast checker: two colorsThe contrast ratio between text and background colors, for example the colors in your design.Measure the colors used in components, light and dark themes, and after interactions.
Free URL scanMachine-evaluable errors in the reachable, loaded page state.Open menus and dialogs, submit forms and scan the resulting states again.
Audit across multiple statesCollect findings from the pages and interaction states reached during the test.Set up the test path and access. Manually test focus paths, screen-reader output and content the scanner cannot evaluate.

Use the color comparison for individual color pairs. Also check the colors and states used on your website; the contrast checker explains text, focus outlines and measurement limits.

See test paths in the Audit product
Diagnostic Criteria

What a website accessibility test should verify

To meet the legal compliance requirements of WCAG 2.1 AA and the BFSG, all interactive sections must be free of obstacles.

Structure and Semantics

Ensure heading hierarchies, document landmarks, and form field descriptions are constructed logically for screen readers.

Common Error: Example: A heading is bold visually, but coded as a plain paragraph in HTML, making it invisible to screen reader structures.
Keyboard Navigation

All interactive elements (menus, buttons, links) must be reachable, operational, and visually highlighted using the tab key.

Common Error: Example: An active link inside a dropdown menu has no focus outline style – keyboard users navigate blindly.
Forms & Error Handling

Input fields must have explicit labels, and validation errors must be programmatically linked to their corresponding inputs.

Common Error: Example: An error message turns red visually but is not announced to assistive technology.
Visual Contrast

Text elements, inline symbols, and active states (focus, hover) must have high enough contrast ratios relative to their background.

Common Error: Example: Placeholder text or muted button labels are set to light gray on white, making them unreadable for visually impaired users.
Responsive & Mobile Viewports

Touch targets must be sufficiently large, hamburger menus must not lock, and complex zoom scales must wrap appropriately.

Common Error: Example: The mobile drawer menu cannot be opened or navigated using keyboard tab commands.
Interactive States & Overlays

Modal dialogs and blocking consent layers move focus inside when opened, contain it and return it on close. Non-modal cookie banners must leave focus free, be reachable early by keyboard and must not completely obscure focused elements (WCAG 2.4.11).

Common Error: Example: A modal cookie dialog lets focus move to obscured background links.
Practical checklist

Website accessibility testing checklist

Run these checks on a typical user journey and record the results. They complement the scan and are not a complete conformance assessment.

  1. Keyboard and dialogs

    Test: Navigate with Tab and Shift+Tab. Open the main menu and a dialog, then close it with Escape.

    Expected result: Focus stays visible, every control is reachable and focus returns to the trigger after closing.

  2. Form errors

    Test: Submit an important form empty, then with invalid input. Check the error with a keyboard and screen reader.

    Expected result: The error is associated with its field and announced. Previously entered data remains available.

  3. Mobile views and magnification

    Test: Test the same journey in a narrow view and with enlarged text. Try the controls with touch.

    Expected result: Text and controls remain readable and usable. Essential content is not clipped or obscured.

  4. Content and screen readers

    Test: Check headings, link names and the meaning of important images. Complete the journey with a screen reader.

    Expected result: Structure, names and status messages convey content purpose and allow the task to be completed.

  5. Verify the fix

    Test: Record the URL, state, steps, expected and actual result. Repeat the test after remediation.

    Expected result: The barrier is no longer reproducible in the same situation. Related states still work.

Test Steps

How to Properly Test a Website

An accessible website cannot be guaranteed by a single tool at the push of a button. Every website should go through a structured, sequential testing process. The more dynamic and interactive your site is, the deeper the required testing scope.

1

Step 1: Quick Single-Page Scan

Best for initial evaluation. Highlights obvious coding violations on a single URL, but is insufficient for complete compliance claims.

2

Step 2: Template & Section Review

Evaluates main static layout components. Identifies global layout errors occurring in the header, footer, or core content blocks.

3

Step 3: Deep State Audit (incl. Flows)

Covers dynamic overlays, account login environments, shopping carts, and mobile states. Highly recommended for transactional portals.

4

Step 4: Combined Audit (Auto + Manual)

Combine automated checks with manual evaluations, such as screen reader navigation. Document findings and corrections; the result does not replace a legal assessment.

5

Step 5: Documentation & score history

Consolidate findings in a report. Recheck the same pages and user flows after releases. Score history and alerts in Audit help you compare changes and investigate regressions.

Test Surfaces

What website pages and states must be tested

Accessibility is determined in the interactive states of your website, not just on the first page load.

Homepage / Landing PageCategory Pages & Product FiltersProduct Detail PagesForms & Interactive FieldsLogin & Registration FormsCustomer Dashboard & Account SettingsSearch Results & Autocomplete ProposalsCookie Consent BannersModal Dialogs & PopupsValidation Error AnnouncementsEmpty StatesCheckout & Booking FunnelsMobile Navigation Patterns

Test cookie banners with keyboard and focus

Test Boundaries

What automated checkers can and cannot accomplish

Rule-based scans find technical errors. Also test whether you can complete the task with a keyboard and screen reader.

Well suited for automation

  • Technical syntax and HTML errors
  • Missing alt attributes on images that need a text alternative
  • Computable text contrast in the tested state
  • Missing labels on form fields
  • Invalid ARIA roles and attributes

Requires manual expert evaluation

  • The actual quality of alt text descriptions (e.g. 'Photo 43' vs details)
  • Logical flow sequence of keyboard tabs across dynamic inputs
  • Readability level of language texts and terms
  • True interaction experience of assistive tools like screen readers
  • Exemption cases and disproportionate burden checks (Section 17 BFSG)
  • Readability of canvas charts and their text alternatives
  • Reachability and operation of embedded payment and chat widgets

Record which pages, states and embedded content were tested. Add manual findings to the report and repeat the affected tests after fixing them.

Ownership

Who owns which accessibility checks

Successful accessibility is a team effort. Every department contributes a critical part in practice.

Design & Product

Responsible for color palettes, contrast ratios, logical user flows, keyboard focus visual outlines, and screen reader design concept alternatives.

Content & Editorial

Responsible for meaningful image alt descriptions, semantic heading structures, accessible PDF document downloads, and plain language text.

Engineering & QA

Responsible for semantic HTML tags, WAI-ARIA roles, full keyboard support, focus trap preventions, and automated CI/CD pipeline checks.

Compliance & Leadership

Prepares and updates the accessibility statement, records follow-up checks and release decisions, and trains the teams.

The navable Solution

Run your planned tests with navable Audit

Audit runs automated checks across page states and manages findings. Add your manual tests and re-test affected journeys after each fix.

Audit product: features and workflow
Next Steps

Which next step is right for your website?

Clarify BFSG applicability

Use the questionnaire for an initial estimate of scope.

Start BFSG Check

Quick Single-Page Scan

Start with a short audit for a snapshot of one of your pages with our free audit in the tool section.

Start Audit

Accessibility statement

Create an editable statement draft and review it before publication.

Learn more

Discover the platform

Compare Audit plans and choose the test scope for your project.

Get started now

Frequently Asked Questions about Website Testing

A free URL scan helps you find initial technical errors in the loaded state. A complete test needs representative pages, interactive states and additional manual checks. A scan without findings does not confirm conformity.

All pages necessary to perform primary user tasks. For e-commerce, this includes the home page, search forms, list views, cart panels, checkout pathways, and user profiles. For SaaS, this covers dashboard interfaces and configuration views.

It depends on the test setup. A public URL scan cannot reach protected content without authentication. Set up an authenticated test path and check which pages and states were actually reached.

WCAG 2.1 AA gives you criteria for testing technical barriers on your website. The BFSG and EN 301 549 describe the legal and technical framework. A scan shows errors, but cannot tell you whether the BFSG applies to your business or whether you meet all legal requirements. Start with the BFSG Check and seek specialist advice where needed.

Automated scans detect machine-evaluable contrast, HTML structure and attribute issues. Text clarity, meaningful keyboard paths and screen reader use require additional manual testing. Document both methods and review your draft accessibility statement before publication.
References

Standards and Official References

Use these official resources and guidelines to deepen your compliance knowledge.

WCAG 2.1 Quick Reference (W3C) (opens in a new tab)WCAG Evaluation Methodology (WCAG-EM) (opens in a new tab)German Federal Office for Accessibility (BFSG) (opens in a new tab)MDN Web Docs Accessibility Guide (opens in a new tab)