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.
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.
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?
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.
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
Have any feedback about this knowledge base article? Let us know!