> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testwithlabrador.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Create and Configure an Accessibility Audit Project

> Set up a new Labrador accessibility audit project, choose a WCAG testing methodology, and add custom fields to match your workflow.

A **project** in Labrador is the container for a complete accessibility audit. It holds every page and component and user journey you test, all WCAG criterion results, every logged issue, and any exported reports you generate. Before you start testing, you create a project and choose a testing methodology, that choice shapes the export formats available to you throughout the engagement.

## Create a Project

<Steps>
  <Step title="Log in and open the Projects dashboard">
    Sign in at [testwithlabrador.com](https://www.testwithlabrador.com) and navigate to the **Projects** dashboard. All your existing projects are listed here, along with your remaining project capacity for the current month.
  </Step>

  <Step title="Click + Create Project">
    Select the **+ Create Project** button in the top-right corner of the dashboard to open the project creation form.
  </Step>

  <Step title="Enter a title and description">
    Type a clear **Project Title**, for example, the client name and site being tested. Add a brief description to help you and your teammates identify the project at a glance.
  </Step>

  <Step title="Select a Testing Methodology">
    Choose one of the two available methodologies from the dropdown:

    * **WCAG 2.2 AA Testing**, for standard accessibility audits
    * **VPAT® 2.5 – WCAG 2.2**, for formal conformance reporting with VPAT DOCX output
  </Step>

  <Step title="Click Create Project">
    Click **Create Project** to save your new project and open its dashboard. You can start adding pages and components immediately.
  </Step>
</Steps>

<Warning>
  The testing methodology cannot be changed after the project is created. If you need a `.docx` VPAT output to deliver to a client, select **VPAT® 2.5 – WCAG 2.2** before clicking Create Project, you cannot switch methodologies later.
</Warning>

## Choosing a Methodology

Both methodologies test against the same WCAG 2.2 criteria at Levels A and AA. The difference lies in the report formats each makes available.

<CardGroup cols={2}>
  <Card title="WCAG 2.2 AA Testing" icon="clipboard-check">
    The standard choice for most accessibility audits. Use this methodology when your deliverable is a practical audit report rather than a formal conformance statement.

    **Available exports:** HTML report, CSV, Jira CSV
  </Card>

  <Card title="VPAT® 2.5 – WCAG 2.2" icon="file-contract">
    A stricter workflow for teams that want to record results in VPAT terminology (Supports, Partially Supports, Does Not Support, and so on) across multiple pages and push those results into a VPAT WCAG Edition template automatically.

    Most testers find it easier to run their normal rounds of testing first and author the VPAT document by hand at the end. Only pick this methodology if your process is already built around VPAT-native reporting.

    **Available exports:** HTML report, CSV, Jira CSV, and VPAT DOCX
  </Card>
</CardGroup>

<Info>
  If you are unsure, pick **WCAG 2.2 AA Testing**. It fits almost every engagement, including most cases where a VPAT is the eventual deliverable, you can complete your testing here and then write the VPAT yourself against the results. Reach for **VPAT® 2.5 – WCAG 2.2** only when you specifically want to record findings in VPAT conformance terms as you test and generate the VPAT DOCX directly from the tool.
</Info>

## Adding Custom Fields

Custom fields let you capture additional metadata on every issue you log, for example, the browser and version where the issue was found, the component library version, or an internal ticket reference. You define the fields at the project level, and they appear on every issue form within that project.

<Steps>
  <Step title="Expand the Custom Fields section">
    In the project view, scroll to the **Custom Fields** section and expand it.
  </Step>

  <Step title="Add a new field">
    Click **+ Add Field**. Enter a **Field Name** that clearly describes the data you want to capture, then choose a **Type**, options include Single Line Text, Number, and Dropdown. If the field must be completed before an issue can be submitted, check the **Required** box.
  </Step>

  <Step title="Save the field">
    Click **Add Field**. The field will appear on every new issue form in this project immediately.
  </Step>
</Steps>

<Tip>
  If you run recurring audits with the same metadata requirements, click **Load Template** in the Custom Fields section to apply a saved set of custom fields instead of recreating them manually for each new project. This is particularly useful when you use the same reporting format across multiple client engagements.
</Tip>

## Project Capacity

The number of projects you can create per month depends on your Labrador subscription plan. Review your available capacity before starting a new engagement.

| Plan       | Project capacity         |
| ---------- | ------------------------ |
| Free       | 1 total project slot     |
| Core       | 3 new projects per month |
| Plus       | 6 new projects per month |
| Enterprise | Unlimited projects       |

<Note>
  On the Free plan, you have a single project slot. Deleting a project frees that slot for a new one. The included demo project does not count against your limit. See [Plans and Pricing](/plans-and-pricing) for a full feature comparison across plans.
</Note>