> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/accessibility.md). # Accessibility at Buzzy 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. {% hint style="info" %} 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. {% endhint %} ## 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](https://www.w3.org/WAI/WCAG22/quickref/). ## 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 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