Website Accessibility Review: What Your Brief Should Include

Website Accessibility Review: What Your Brief Should Include

A website may look polished, load quickly, and work well for many visitors while still creating barriers for people with disabilities. A user might be unable to navigate a menu with a keyboard, understand an image without alternative text, read low-contrast content, or complete a form using a screen reader.

These issues can make essential information and services difficult or impossible to access. They can also affect the overall usability of a website, including how confidently people navigate pages, complete forms, and finish important tasks.

A website accessibility review helps identify these barriers and determine what needs to change. However, the quality of the review depends partly on how clearly the work is defined before it begins.

A well-prepared website accessibility review brief explains which pages and user journeys need to be assessed, which accessibility standards matter, how testing should be conducted, and what deliverables the business expects.

This guide explains what to include in that brief, how to prioritize accessibility findings, and how to work with a specialist to turn review results into practical improvements.

What Is a Website Accessibility Review?

A website accessibility review evaluates whether people with different abilities can access information, navigate interfaces, understand content, and complete tasks on a website.

The review may examine visual presentation, keyboard interaction, screen reader compatibility, form behavior, content structure, multimedia, and other parts of the user experience.

Depending on the project's needs, an accessibility review can include:

• Automated accessibility scans to identify certain common technical issues.
• Manual testing of keyboard navigation and interactive components.
• Screen reader testing of navigation, forms, headings, and dynamic content.
• Visual checks for color contrast, text resizing, and focus indicators.
• Review of page structure, link labels, image alternatives, and form instructions.
• Testing of important user journeys, such as registration, checkout, or booking.
• Documentation of findings and recommendations for remediation.

An accessibility review is not simply a check for visible design problems. It considers whether people can operate and understand the experience using different interaction methods and assistive technologies.

Why Your Accessibility Brief Matters

Without a clear brief, an accessibility project can become too broad, too narrow, or focused on the wrong problems. A reviewer might assess a few homepage elements while overlooking the registration flow, account dashboard, checkout process, or other important functionality.

Unclear expectations can also create confusion about which standards apply, how findings should be classified, and whether the final report should include only identified issues or also practical guidance for fixing them.

A good brief helps the business and the accessibility specialist agree on:

• The purpose and boundaries of the review.
• The pages, templates, components, and workflows to be assessed.
• The accessibility standards and evaluation criteria.
• The devices, browsers, and assistive technologies relevant to the audience.
• The evidence and severity information required for each finding.
• The expected report, recommendations, and follow-up support.

This preparation makes it easier to compare proposals, estimate the effort involved, and ensure the review addresses real user needs.

1. Define the Business Objective

Start by explaining why the accessibility review is needed. The objective will influence the scope, testing approach, and expected deliverables.

Common reasons include:

• Evaluating the accessibility of a new website before launch.
• Identifying barriers on an existing website.
• Reviewing a redesign before it replaces the current experience.
• Improving accessibility across an online store or customer portal.
• Investigating user feedback about navigation, forms, or content access.
• Preparing for an internal accessibility improvement program.
• Assessing the website against applicable legal or contractual requirements.

Make the objective specific. Instead of writing, "We want our website to be accessible," a stronger statement might be:

We want an independent accessibility review of our public website and account registration journey to identify barriers, assess the selected WCAG criteria, and provide prioritized recommendations that our development team can implement.

This description identifies the intended outcome without assuming that every part of the website needs the same level of investigation.

2. Identify the Website Pages and User Journeys

One of the most important parts of an accessibility brief is defining exactly what will be reviewed.

Listing only the homepage is rarely enough for a website with multiple templates, interactive elements, and user workflows. Accessibility problems may appear in shared navigation, search results, form errors, modal dialogs, account settings, or payment steps.

Identify the relevant pages and workflows, such as:

• Homepage and main navigation.
• Service, product, and category pages.
• Search results and filtering interfaces.
• Registration, login, and password recovery.
• Contact forms, quote requests, and booking forms.
• Shopping cart, checkout, and payment steps.
• Customer dashboards and account settings.
• Blog articles, downloadable resources, and embedded media.

For large websites, agree on a representative sample of page templates and interactive components. Include unique or high-risk workflows separately rather than assuming that testing one page automatically covers every variation.

Also clarify whether the review includes mobile layouts, third-party integrations, embedded content, authenticated areas, and downloadable documents.

3. Specify the Accessibility Standard and Requirements

The brief should state which accessibility standard or requirements the review should use. A common reference is the Web Content Accessibility Guidelines (WCAG), developed by the World Wide Web Consortium (W3C).

WCAG organizes accessibility guidance around four principles. Website content should be:

• Perceivable: Users must be able to perceive the information being presented.
• Operable: Users must be able to navigate and interact with the interface.
• Understandable: Information and interface behavior should be understandable.
• Robust: Content should work reliably with browsers and assistive technologies.

Where appropriate, specify the intended WCAG version and conformance level, such as WCAG 2.2 Level AA. The correct target depends on the project, the organization's requirements, and any applicable regulations or contractual commitments.

Do not assume that the same legal obligations apply to every business or country. If legal compliance is part of the project, identify the relevant jurisdiction and ask a qualified professional to clarify the applicable requirements.

The brief should also state whether the reviewer is expected to evaluate selected WCAG success criteria, assess broader usability concerns, or perform another clearly defined type of review.

4. Define the Testing Methods

Automated accessibility tools are useful for identifying some problems, but they cannot detect every accessibility barrier. A credible review combines appropriate automated checks with manual evaluation.

Specify the testing methods that matter for your website.

Automated testing

Automated tools can help detect certain issues, such as missing accessible names, some contrast failures, invalid markup patterns, and other detectable rule violations. They are useful for covering repeated components and checking changes over time.

However, a tool may not determine whether alternative text is meaningful, whether instructions are understandable, or whether an entire workflow is usable with a screen reader.

Manual keyboard testing

Ask the reviewer to navigate important workflows using a keyboard without relying on a mouse. The review should examine focus order, visible focus indicators, keyboard access to controls, and whether users can enter and exit interactive components without becoming trapped.

Assistive technology testing

Where relevant, specify testing with screen readers and other assistive technologies used by your audience. The reviewer should examine whether page structure, form labels, error messages, dialogs, and dynamic updates are communicated appropriately.

Visual and content review

Include checks for text contrast, resizing, layout behavior, heading structure, link purpose, image alternatives, captions, and understandable instructions. The exact checks should match the chosen standard and the content on the website.

Ask the specialist to explain which methods will be used, which limitations apply, and how automated findings will be verified manually.

5. Document Technical and Business Context

Accessibility issues often depend on how a website is built and how its components behave. Sharing relevant technical context helps the reviewer plan realistic tests.

Include information such as:

• The content management system or application framework.
• Relevant frontend technologies and shared UI components.
• Supported browsers and devices.
• Important third-party tools, such as payment or booking services.
• Whether the site includes dynamic content, dialogs, filters, or complex forms.
• Whether testing access is available for authenticated pages.
• Existing accessibility documentation, known defects, or previous audit reports.
• Relevant release dates, technical restrictions, and maintenance windows.

Do not include passwords or sensitive production data in a project brief. Arrange access through the organization's approved secure process, and use test accounts or suitable test data wherever possible.

Clarify whether the reviewer is expected to inspect source code, use a staging environment, test production pages, or coordinate with the internal development team.

6. Define the Expected Deliverables

A review is most useful when the results help the team take action. The brief should state what the specialist needs to deliver and how the findings will be documented.

Typical deliverables include:

• Executive summary: A concise overview of the main accessibility risks and recommended priorities.
• Detailed findings report: Documented issues with page or component references and supporting evidence.
• Applicable criteria: References to the relevant WCAG success criteria or other agreed requirements.
• Reproduction steps: Instructions for locating and verifying each reported issue.
• Impact and priority: An explanation of who may be affected and how urgently the issue should be addressed.
• Remediation guidance: Practical recommendations that help designers and developers understand possible fixes.
• Testing limitations: Details of pages, devices, assistive technologies, or conditions that were not evaluated.
• Follow-up plan: Optional retesting or validation after fixes have been implemented.

Ask for findings that are specific enough to reproduce and verify. A general recommendation such as "improve accessibility" is much less actionable than an issue that identifies the affected control, explains the barrier, and describes a suitable direction for remediation.

7. Explain How Findings Should Be Prioritized

Not every issue has the same impact or requires the same amount of work. Your brief should explain how findings should be organized to help the team decide what to fix first.

Useful factors include:

• User impact: Does the issue prevent someone from accessing information or completing an important task?
• Scope: Does the issue affect one element, a page template, or a shared component across the website?
• Task importance: Does it affect registration, payment, account access, or another essential journey?
• Conformance: Which agreed accessibility criteria or requirements are not met?
• Remediation effort: Is the issue a small content correction or a broader component redesign?
• Dependencies: Does the fix require changes to a third-party service, design system, or technical architecture?

Priority labels such as critical, high, medium, and low can make reports easier to use, provided their meanings are agreed upon. They should not replace an explanation of user impact or imply a formal legal severity rating unless a defined framework is being used.

For example, an inaccessible primary navigation component may affect many pages, while a missing alternative text description may affect one particular image. Both deserve attention, but the remediation approach and effort may differ.

8. Include Accessibility Ownership and Team Responsibilities

Accessibility work often involves more than the person conducting the review. Designers, developers, content editors, product managers, and business owners may all be responsible for resolving different types of findings.

Clarify who will:

• Approve the scope and accessibility requirements.
• Provide access to pages, systems, and relevant documentation.
• Answer questions about intended interface behavior.
• Review and prioritize findings.
• Implement design, code, or content changes.
• Verify fixes and approve the final outcome.

If remediation is included in the project, distinguish it from the audit itself. An assessment may identify problems and recommend solutions without implementing them. If you need code changes, design revisions, or retesting, list those services explicitly.

Clear responsibilities prevent the review from ending with a report that no one has been assigned to act on.

9. Set the Timeline, Budget, and Success Criteria

Provide a realistic timeline and budget range when available. The level of effort depends on factors such as the number of templates, the complexity of interactive components, the accessibility standard, and the testing depth required.

For planning purposes, agree on milestones such as:

1. Scope confirmation and access setup.
2. Initial automated and manual assessment.
3. Review of findings and clarification questions.
4. Delivery of the final report and remediation priorities.
5. Optional implementation support and retesting.

Define success in terms of the project's intended outcome. Depending on the engagement, success might mean receiving a complete, reproducible findings report, resolving agreed high-priority issues, or validating fixes against the selected criteria.

A report alone does not establish that a website is fully accessible. Likewise, passing automated checks does not prove that every user can complete every task. Be precise about what the review covers and what conclusions can reasonably be drawn from its results.

Website Accessibility Review Brief Template

Use this template as a starting point when preparing a brief for an accessibility specialist.

Project overview

1. Project name: Website or application name.
2. Business objective: Why is the review needed?
3. Target audience: Who uses the website and what tasks do they need to complete?
4. Project contact: Who will answer questions and approve decisions?

Scope and standards

1. Pages and workflows: List URLs, page templates, and critical journeys.
2. Platforms: Identify desktop, mobile, tablet, and supported browsers.
3. Accessibility target: Specify the agreed WCAG version, conformance level, or other requirements.
4. Testing methods: Identify automated testing, manual keyboard review, assistive technology testing, and other required methods.
5. Technical context: Describe the technology stack, dynamic components, and third-party integrations.

Deliverables and execution

1. Required outputs: Findings report, evidence, reproduction steps, and remediation guidance.
2. Prioritization: Define how impact, conformance, urgency, and effort will be recorded.
3. Responsibilities: Clarify who reviews findings, implements fixes, and verifies results.
4. Timeline and budget: Include deadlines, milestones, and any budget constraints.
5. Retesting: State whether post-fix validation is included.
6. Success criteria: Define the outcomes expected from the engagement.

The template can be adapted to the project's size. A small marketing website may require a relatively short brief, while a large application with authenticated workflows and complex interactions may need a more detailed scope.

How to Choose the Right Accessibility Specialist

Once your brief is ready, look for a specialist whose experience matches the complexity of the website and the type of review you need.

When evaluating candidates, ask:

• What accessibility standards and testing methods do you use?
• How do you combine automated checks with manual evaluation?
• Which assistive technologies and browsers can you test with?
• Can you provide a sample of a findings report with identifying information removed?
• How do you document evidence, user impact, and remediation recommendations?
• Can you support developers or designers during remediation?
• Does your proposed scope include retesting after fixes?

Look for clear communication and practical reasoning, not just a list of tools or certificates. The specialist should be able to explain the limitations of their approach and distinguish automated test results from issues that require human evaluation.

Through WorkFry, businesses can explore professional services and connect project requirements with relevant expertise. A well-defined brief can help you communicate the scope clearly, compare proposals, and identify a specialist suited to your accessibility goals.

Conclusion: A Clear Brief Leads to a More Useful Accessibility Review

A website accessibility review is most effective when the business defines the objective, scope, applicable standards, testing methods, deliverables, and responsibilities before the work begins.

These details help the reviewer investigate the right pages and user journeys, document actionable findings, and explain which improvements should be prioritized. They also help the business understand the limits of the assessment and plan the work that follows.

Before hiring an accessibility specialist, make sure your brief answers three questions: What needs to be reviewed? How will accessibility be evaluated? What deliverables will help us make improvements?

With those answers in place, your organization can approach accessibility as an ongoing part of website quality and user experience rather than a one-time technical checklist.

Frequently Asked Questions

What should a website accessibility review brief include?

It should include the project objective, target audience, pages and workflows in scope, applicable accessibility standards, testing methods, technical context, expected deliverables, priorities, timeline, responsibilities, and success criteria.

What is the WCAG standard?

The Web Content Accessibility Guidelines (WCAG) are internationally recognized guidelines for making web content more accessible to people with disabilities. They organize recommendations around perceivable, operable, understandable, and robust experiences.

Can automated tools complete a website accessibility review?

Automated tools can identify some accessibility issues, but they cannot reliably evaluate every aspect of usability, content meaning, keyboard interaction, or assistive technology behavior. A thorough review typically combines automated tools with manual testing.

How long does a website accessibility review take?

The timeline depends on the website's size, the number of unique page templates and workflows, the testing depth, and the required deliverables. A focused review of a small website generally requires less effort than an assessment of a complex web application.

Does an accessibility review guarantee legal compliance?

Not necessarily. A review evaluates a defined scope against specified criteria, and its conclusions are limited by the pages, technologies, and methods assessed. Legal obligations vary by jurisdiction and situation, so organizations should obtain appropriate legal advice when compliance is a requirement.