Accessibility at Buzzy

How Buzzy supports accessible custom app runtimes, MCP interfaces and the Buzzy Workspace, including current testing and practical verification paths.

Buzzy is working to make both the applications created with Buzzy and Buzzy's own building interfaces accessible to as many people as possible. Our current engineering target for user-facing web interfaces is WCAG 2.2 Level AA.

Accessibility in Buzzy is a governed delivery process: start with accessible platform components, test the real user journeys, keep evidence for the exact release scope, and complete human assistive-technology review before making a conformance claim.

The results on this page describe the interfaces, applications, states and environments that have been tested. They do not certify every custom Buzzy app, mobile build, third-party integration or MCP client. Contact Buzzy when you need evidence for a particular product version, deployment or procurement scope.

The four Buzzy user interfaces

Buzzy has four main user-facing interaction paths, excluding REST and other programmatic APIs:

Interface	What it is	Accessibility path
Buzzy Custom App Runtime	The web or mobile interface of an application built with Buzzy	Accessibility-aware Buzzy runtime and native components, app-specific automated checks, and manual browser/device testing
Buzzy Custom MCP	Optional app-specific tools and selected Buzzy Functions exposed to an MCP client	A structured, conversational and potentially non-visual path governed by the app's tools, permissions and data model
Buzzy Workspace	Buzzy's browser-based builder and application-management interface	First-party web accessibility engineering, repeatable browser checks and manual assistive-technology review
Buzzy Builder MCP	Buzzy's MCP tools for building, inspecting, testing and managing applications through an agent	A structured builder path with accessibility inventory, preflight, browser audit, persisted evidence and release-gate tools

An organisation may use more than one path. For example, a team can build an app through Builder MCP, review it in the Workspace, publish it to the web and mobile runtimes, and optionally expose selected app functions through Custom MCP.

Buzzy Custom App Runtime

Web applications

Published Buzzy applications run in a browser at their deployed app URL. Buzzy's web runtime and native components provide an accessibility-aware foundation for common application behavior, including:

• semantic headings, landmarks, lists, tables, forms and controls

• accessible names, labels, descriptions, validation and status announcements

• keyboard operation, visible focus and dialog focus management

• responsive reflow, zoom and text-spacing support

• forced-colour/high-contrast and reduced-motion behavior

• non-visual alternatives for maps, charts and other interactive visualisations where configured

• authentication-aware experiences, including presenting a login path before protected actions

The final accessibility of a custom app also depends on its screen design, content, configuration, roles, data states, code widgets and third-party integrations. App owners should verify every important user journey rather than assume that use of an accessible component makes the whole app conformant.

Mobile applications

Buzzy supports two mobile delivery paths:

• Capacitor packages the Buzzy web runtime in an iOS or Android application container. It retains the web application's semantic foundation, while actual assistive-technology behavior also depends on the operating system, WebView, plugins and app configuration.

• React Native provides a native-client path for supported Buzzy deployments. Native semantics and behavior must be reviewed on the target iOS and Android versions.

Web-browser evidence does not by itself establish mobile accessibility. Before release, test the production mobile build with VoiceOver on iOS and TalkBack on Android, including navigation, forms, errors, dialogs, gestures, orientation, text scaling and any device-specific integrations.

Current runtime testing

Buzzy has completed scoped functional and automated accessibility work across representative Recipe, CRM, map and chart applications. The test approach includes real Playwright journeys, axe checks, keyboard/focus assertions, 320 CSS px reflow and disability-settings simulations, accessibility-tree inspection, screenshots and Lighthouse smoke checks.

These representative results establish an engineering baseline for the tested applications and states. They are not a guarantee for every generated app or later app version, and browser accessibility-tree inspection is not a substitute for a screen reader.

Buzzy Custom MCP

Custom MCP can be enabled for an existing Buzzy app from its MCP configuration in the Workspace. An authenticated MCP client can then use the app-specific tools Buzzy exposes, including governed datatable operations and selected Buzzy Functions.

Custom MCP can provide an alternative interaction path that does not depend on navigating the app's visual screens. Buzzy provides:

• structured tool names, descriptions, inputs and outputs

• OAuth-based user authentication

• the app's existing row, field and Private Data permissions

• control over the datatables, operations and functions exposed as tools

• the option to wrap governed application logic in a Buzzy Function and expose that function through MCP

MCP is a machine-to-machine protocol, not a visual user interface. The accessibility of ChatGPT, Claude or another MCP client is provided by that client and its platform. If an MCP client renders a Buzzy widget, that rendered widget is a user interface and should be tested separately. Buzzy does not describe an MCP client as WCAG conformant on the client's behalf.

Buzzy Workspace

The Buzzy Workspace is available through Buzzy's browser interface. It covers application creation and management, login and password recovery, dashboards, global navigation, editor panels, dialogs, tests, publishing and administration surfaces.

The current first-party Workspace automated baseline covers:

• login, failed login and password recovery

• dashboard and global navigation

• keyboard-based app creation, opening and reopening

• 17 primary editor destinations

• representative copy and destructive dialogs

• global-admin Templates, Cookbooks, Toolkit and Widgets routes

• representative populated editor states, including first-screen creation and version history

• 320 CSS px reflow, forced colours, reduced motion and WCAG text-spacing simulations

In the recorded Chromium/macOS scope, the accumulated Workspace suite completed 14 of 14 Playwright tests and 40 of 40 first-party evidence rows, with no serious or critical axe violations. Twenty-eight axe incomplete checks remain recorded for human disposition: 25 indeterminate contrast checks and three dialog focus-guard checks. Keyboard focus containment, Escape behavior and trigger-focus restoration passed for the representative dialogs.

This is a strong automated baseline for the tested Workspace scope, not a complete conformance statement. VoiceOver/Safari, NVDA/Chrome or Firefox, real zoom, platform high contrast and accountable human review remain part of the release-evidence path. Optional third-party interfaces are assessed separately when enabled.

Buzzy Builder MCP

Builder MCP lets an MCP-capable agent such as Codex or Claude Code build, inspect, test and manage a Buzzy application through structured tools. Connect from Account Settings → Developer → MCP Access, using OAuth where supported or a bearer token when an approved client requires it.

Builder MCP is another way to operate Buzzy; it does not replace the accessibility of the visual Workspace. The accessibility of the agent application's own interface is the responsibility of that client. Buzzy's Builder MCP tools help the agent create and verify accessible Buzzy outputs.

Accessibility tools available to builders

Builder MCP tool	What it provides	What it does not prove
get_native_widget_accessibility_matrix	Inventories the native widgets and functional categories present in an app, with applicable WCAG criteria, required checks, complexity, effort and risk	It is a planning matrix, not a test result
audit_app_accessibility_structure	Runs a deterministic preflight over persisted screens and returns stable findings for issues such as missing form ownership, missing action names, heading structure, image alternatives and code-widget review	It does not run the app in a browser or screen reader
run_app_accessibility_audit	Runs and persists an isolated-browser audit of route-backed states using axe, code-widget frame checks, keyboard traversal, 320 CSS px reflow, forced colours, reduced motion, accessibility-tree inspection and screenshots	It cannot judge every human, content, screen-reader or mobile requirement
get_app_accessibility_run	Retrieves one persisted run with its state snapshot, findings and evidence	It only describes that recorded run and scope
list_app_accessibility_runs	Lists prior persisted runs so repeated results can be compared	It does not imply that a newer app version still passes
get_app_accessibility_release_gate	Evaluates explicitly selected run IDs, required screen coverage, structural findings, manual-evidence status and accountable review; returns pass, fail, blocked or manual_evidence_required	It does not expand the selected scope or turn automation into certification

Recommended Builder MCP verification flow

1. Finish and review the app's data model, screen inventory and authentication posture.

2. Call get_native_widget_accessibility_matrix and keep only the categories marked as present.

3. Call audit_app_accessibility_structure, repair deterministic failures by finding code, and rerun the preflight.

4. Run the real functional journey first using generated or saved Playwright tests. Reach dialogs and child contexts through visible actions rather than direct URLs.

5. Call run_app_accessibility_audit with explicit route-backed states where the default inventory is not sufficient.

6. Retrieve the persisted evidence with get_app_accessibility_run or compare runs with list_app_accessibility_runs.

7. Complete the manual checks below and keep references to the results with the release evidence.

8. Call get_app_accessibility_release_gate with the exact run IDs and every screen ID required by the release scope.

9. Publish only the narrow claim returned for that evidence scope. A result of manual_evidence_required means the automated evidence is ready but human verification or approval is still missing.

How to test manually

Automated tools find many common failures, but they cannot determine whether an experience is understandable and usable for a person with a disability. Test the real task from beginning to end, including anonymous, authenticated, empty, loading, validation-error, success and destructive-confirmation states.

Keyboard-only

Put the mouse or trackpad aside and complete each journey with the keyboard:

• use Tab and Shift+Tab to check that focus follows a logical order and remains visible

• use Enter and Space to activate controls as expected

• verify that every action is reachable and no region traps focus

• open dialogs, check that focus enters and remains in the dialog, then close it and confirm focus returns to the invoking control

• verify that skip links, menus, disclosures, tables, maps, charts and custom widgets have an operable keyboard path

Screen readers

Use at least one combination relevant to the release. For higher-risk or customer-facing releases, include both major desktop platforms:

• VoiceOver with Safari on macOS

• NVDA with Firefox or Chrome on Windows

• VoiceOver on iOS for Capacitor or React Native iOS builds

• TalkBack on Android for Capacitor or React Native Android builds

Check headings and landmarks, control name/role/state, field labels and instructions, errors, live status updates, table relationships, dialog announcements, focus movement and non-visual access to maps, charts and custom widgets. Listen to the experience rather than only inspecting the browser accessibility tree.

Zoom, reflow and text spacing

• test real browser zoom at 200% and 400%

• test a narrow 320 CSS px viewport without losing content or actions

• increase text spacing to at least 1.5 times font-size line height, 2 times font-size paragraph spacing, 0.12 times font-size letter spacing and 0.16 times font-size word spacing

• check that content does not overlap, clip, disappear or require two-dimensional scrolling except where the content itself genuinely requires it

• on mobile, test the operating system's larger text and display settings

Colour, contrast and motion

• use Windows Contrast Themes or the relevant platform high-contrast settings

• verify that focus, selected state, errors and meaning do not depend on colour alone

• check text and control contrast in the actual rendered state, including content over images or charts

• enable reduced motion and confirm that essential information and controls remain available without unnecessary animation

Record the result

Keep a simple evidence matrix containing:

• app and version

• route, screen, role and state

• expected and actual result

• browser, operating system, viewport and assistive technology/version

• PASS, FAIL, BLOCKED or NOT TESTED

• applicable WCAG criteria

• screenshot, trace, audit or manual note reference

• defect, fix and rerun date

Do not include passwords, tokens, session identifiers or private customer data in screenshots or reports.

For criterion-level guidance, see the W3C WCAG 2.2 Quick Reference.

Shared responsibility

Party	Responsibility
Buzzy	Platform semantics, accessible native-component foundations, Workspace engineering, Builder MCP verification tools and documented testing paths
App owner	App content, workflows, roles, permissions, custom code, code widgets, external integrations, app-specific testing and release decisions
MCP client provider	Accessibility of the MCP client's own interface and any client-rendered widget container
Mobile publisher	Testing the final signed build on supported devices, operating-system versions and assistive technologies

Standards, evidence and claims

Buzzy's current engineering target is WCAG 2.2 Level AA for user-facing web behavior. Where a customer needs EN 301 549, AS EN 301 549, an Accessibility Conformance Report or another procurement artifact, the applicable product version, deployment, user journeys, exclusions and evidence package must be agreed and reviewed explicitly.

An automated pass is evidence for the tested scope; it is not by itself proof that an app or the Buzzy product is WCAG conformant. A conformance statement should name the product and version, tested scope, methods, browser and assistive-technology matrix, known limitations, evidence date and accountable reviewer.

Feedback and accessibility requests

Contact [e-mail] to report an accessibility problem or discuss evidence for a customer deployment. Include the interface or app, page or task, browser/device, assistive technology and a description of what prevented completion. Do not send passwords, authentication tokens or sensitive customer data.

Statement last reviewed: 30 July 2026

Current engineering target: WCAG 2.2 Level AA