Identify our Audience

[kengdoj]

I think we need something like what's on https://www.w3.org/WAI/standards-guidelines/act/#who-act-is-for

Who ACT is for The primary audience of Accessibility Conformance Testing (ACT) is developers of accessibility evaluation methodologies and testing tools. They write, share, and implement ACT Rules into their products and services.

A secondary audience is accessibility experts. They often assist in setting an organization’s accessibility policy, and it is important for them to know what ACT Rules do, and how they relate to their own requirements.

Who ACT is not for: Users of accessibility tools (web developers, content authors, QA testers, etc.) are not expected to read ACT. These audiences will use products and services that implement ACT Rules.

[kengdoj]

@cliffbert - can you add what you drafted for a presentation about this?

[cliffbert]

As you might expect, the primary audience of the ICT Baseline would be developers of accessibility evaluation methodologies and testing tools: anyone whose primary responsibility is to write, share, and implement accessibility testing into their products and services.

Again, since the Baseline offers a common frame of reference for interpreting the Section 508 standards and WCAG and translating them into standard, repeatable tests, it has been adopted by various organizations, including DHS’s Trusted Tester and some of the largest testing tool vendors.

Understanding the ICT Baseline would also be helpful to anyone who is tasked with modifying or updating existing test processes or evaluating other test processes for possible adoption.

The Baseline could help SMEs in setting an organization’s accessibility policy, how it relates to their own requirements, and if there are differences that relate to their own testing tools and methodologies. Its audience, therefore, also includes accessibility experts such as Section 508 PMs and coordinators.

Similarly, vendors who do business with government agencies who have adopted the ICT Baseline or Trusted Tester, want to be able to show alignment, whether it’s coverage by an automated testing tool or test processes.

Web developers and content authors who want to implement more shift-left testing based on a common framework will also find some benefit from understanding the requirements of the ICT Baseline, whether it’s developing content design templates or accessible component libraries.

But you might still benefit from knowing about the ICT Baseline, without having to be intimately familiar with its contents; depending on your role, you may only need to know what it is and whether it may have an impact on your project or product.

For example, if you’re in charge of a project, and if parts of your organization or agency have adopted either the ICT Baseline or Trusted Tester, you may want to see if your project is already aligned, required to align, or if it would be beneficial for information sharing or code sharing.

Users of accessibility testing tools and test processes are not necessarily expected to read or digest the ICT Baseline. But knowing about it may put them in a position to ask their team whether their testing efforts and tools should consider Baseline alignment, for sharing of test results with customers who do use it.

CORs, COs, Requiring Officials, and IT PMs are similarly not expected to be familiar with the details of the ICT Baseline. Nevertheless, solicitation language may include requirements for contractors to use a specific test process (e.g., Trusted Tester) for accessibility conformance validation.

For procurement professionals, there would be an advantage in Baseline-aligned tools and processes to validate conformance for federal contracts.

Lastly, government agencies who adopt the Baseline can share testing results with the knowledge that they follow a common understanding.