What are Be Inclusive Projects?

The only difference between pricing tiers for Be Inclusive is the number of Projects you have access to when you subscribe. While you can easily change your subscription over time should you find that you need more or less projects, it’s still a good idea to consider how many you may need as you get started.

This article goes into some detail on what a project entails, and some recommendations that may help you select a tier that’s best suited to your needs.

What does a Project entail?

All digital accessibility evaluations in Be Inclusive are organized into Projects, Projects are intended to encompass one distinct site, app, or other digital workflow you want to evaluate.

A Project is where you define the overall scope of your evaluation, explore the target website or app to understand its purpose and functionality, and select a representative sample that you will then evaluate during your audit.

New Project page with sections detailing the three steps it entails. Defining the overall scope, exploring the website or app to understand its purpose, and selecting a representative sample for evaluation. — The introductory page when creating a new Be Inclusive Project, introducing the three step process following the WCAG-EM methodology.

This might sound familiar if you’ve used the WCAG-EM Methodology in the past. A Be Inclusive project encompasses the first three of the five total steps of WCAG-EM, as illustrated in the chart below.

Diagram about the iterations between the steps in the WCAG-EM methodology. Explanation in the accompanying caption. — The workflow diagram above depicts five sequential steps: 1. Define the evaluation scope; 2. Explore the target website; 3. Select a representative sample; 4. Audit the selected sample and 5. Report the findings. Each step has an arrow to the next step, and arrows back to all prior steps. This illustrates how evaluators proceed from one step to the next, and may return to any preceding step in the process as new information is revealed to them during the evaluation process.

Audits

Each Project can have one or more Audits associated, an audit is where you’ll spend the majority of your time tracking observations and – when complete – will be where you go for a shareable audit report. The audit and the report are steps four and five of the WCAG-EM Methodology mentioned above.

Projects and Audits are organized this way for the following reasons:

Recurring Audits – Multiple audits organized under one Project means you only have to perform the first three steps once, you can jump right into evaluating in subsequent follow up audits.
Progress Tracking – Performing an audit on the same representative samples helps you keep track of remediation progress over time.
Observation Duplication – It can be fairly common to have similar observations in recurring audits. As you fill out observation details, Be Inclusive will look out for similar observations from past audits of that project and offer to duplicate it into your current one. This saves you some additional effort and leads to more uniform observations over time.

Project Scope Recommendations

The scope of a project can be as broad or as narrow as you and your stakeholders need, from a whole website down to a specific user flow, in many cases you may need to perform some site exploration first before you can define the scope with enough detail as to avoid any ambiguity.

Questions to consider

How thorough do we need to be?
What are the key areas that need to be prioritized?
Are there areas of the site that are controlled by a separate team?
Is there a separate logged-in user state?

Recommendations

Use separate projects for:

sections of a site that are controlled by different teams, this way the results documents are more actionable by those individual teams
sections of a site that use different sets of technology, for example a blog subdomain
the native mobile application, even if it technically shares some of the same underlying codebase as the website
sections that are exceptionally complex or mission critical. For example the logged in state of a Software as a Service offering, or the shopping cart experience of an eCommerce site.

Wrapping up

I hope this helps define what Be Inclusive projects are, how they can be organized, and gives you a better sense for how many your organization may need. If you have further questions please do use the link below to reach out and let me know!

Last updated: Apr 15th 2023