Inclusive Product Advisory Board​

Disability advocates, assistive technology users, and accessibility professionals provide real-world input that helps shape accessiBe products before they reach customers.

Explore accessLabs Icon

Why we created the Board

Accessibility decisions should be informed by the people who understand digital barriers firsthand.

The Inclusive Product Advisory Board brings together disability advocates, assistive technology users, and accessibility professionals to review product experiences, challenge assumptions, and provide feedback while decisions are still being made.

Members meet quarterly as a group and continue working with accessiBe teams between sessions, helping inform product language, UX decisions, accessibility profiles, research, and release readiness.

Who participates in the Board

Board members include disability community leaders, advocates, accessibility professionals, and people who use assistive technologies in their daily lives.

Members have included people connected to organizations such as The Viscardi Center, United Spinal Association, Parkinson’s Foundation, Hidden Disabilities, Blinded Veterans Association, and Turnstone.

Board sessions are moderated by Josh Basile, accessiBe’s Community Relations Manager, disability rights advocate, lawyer, and C4-5 quadriplegic.

How the Board contributes

Board members help accessiBe evaluate product and content decisions from a real-world accessibility perspective.

 

They test product experiences, review accessibility profile language, score flows for clarity and usefulness, flag language that may feel inaccurate or limiting, and contribute to research and storytelling initiatives.

The goal is not to treat advisory feedback as a final approval stamp. It is to bring lived experience into the product process early enough to influence what gets built, changed, or clarified.

feedback loop

What changed because of Board feedback

During the Board’s first year, member feedback helped shape updates to accessWidget, especially around how accessibility settings are named, explained, and presented.

Examples include:

  • Person-first and function-first language
  • Clearer profile naming, such as “Low
  • Vision” instead of “Vision Impaired”
  • More useful descriptions focused on what a setting helps users do
  • More accurate claims, replacing absolute language like “eliminates” with “helps mitigate”

These updates reflect a larger shift: accessibility language should be accurate, respectful, and useful to the people who rely on it.

How this connects
to accessLabs

The Inclusive Product Advisory Board is one part of accessiBe’s broader approach to product feedback and validation.

Alongside the Board, accessLabs is a testing hub where blind usability analysts test releases using real assistive technologies. Their work helps surface issues automated testing alone may not detect.

Together, the Board and accessLabs help accessiBe evaluate accessibility from multiple angles: lived experience, usability testing, product language, and release quality.

 

Frequently asked questions

How does advisory board input reach the product team?

Board members review product experiences, score accessibility profiles, and flag issues directly with accessiBe teams. Feedback is reviewed by product, UX, content, and accessibility stakeholders, then used to guide updates where appropriate.

The 2025–2026 accessWidget language updates are one example.

The Board is an ongoing group that reviews product direction, language, and priorities before features ship. accessServices’ user testing is a discrete engagement in which assistive technology users complete real tasks on a specific site or app and document usability issues. Both bring people with disabilities into the process – the Board shapes what accessiBe builds, while user testing evaluates what a customer has already built.

Membership is made up of invited disability advocates, accessibility professionals, and assistive-technology users. Customers who want to flag language or usability concerns in their own accessibility profile can do so through standard support channels, and recurring themes can inform what the Board reviews in future sessions.

No. Statements and VPATs are produced through accessServices as formal documentation of a site’s accessibility status. The Board’s role is upstream of that, informing product and language decisions rather than producing compliance documents.

Many teams benefit from both. Automation helps you move quickly, and developer tools ensure accessibility is built into your long-term workflow. accessFlow integrates with CI/CD pipelines so developers can test and fix issues before release.