Understandable structure
Landmarks, headings, labels, status announcements, and visible focus help people navigate the site in different ways.
ACCESSIBILITYAccess should be
Access should be
part of the product.
Reviewed July 23, 2026. Boardesa AI is being built toward WCAG 2.2 Level AA practices. This page describes the support that exists in the current public preview, the limits we know about, and how to report a barrier.
Keyboard paths: supportedReduced motion: supportedCertification claim: none
Flexible presentation
The interface reflows on small screens, respects reduced-motion and increased-contrast preferences, and avoids meaning that depends on colour alone.
Practical reporting
Accessibility reports have a dedicated contact route and can be prepared locally without submitting a website form.
1. Our accessibility commitment
Boardesa AI is intended for students, school pupils, teachers, tutors, parents, and education teams. Access needs vary across that audience, so accessibility cannot be treated as a final visual check. It has to influence navigation, wording, interaction, error recovery, motion, contrast, and the way future AI features explain their state.
The current goal is to follow WCAG 2.2 Level AA practices where they apply to this preview. This is a product target, not a claim of independent certification or complete conformance. We will describe verified support and known limits rather than use a badge that overstates the present product.
2. Support in the current preview
Landmarks and headings
Pages use one main region, a consistent heading hierarchy, named navigation regions, and a skip link that moves directly to primary content.
Named controls
Buttons, fields, dialogs, menus, tabs, and dynamic messages have programmatic names and state relationships.
Responsive layouts
Content is designed to reflow without horizontal page scrolling at common mobile widths and high browser zoom.
Reduced motion
Operating-system reduced-motion preferences disable or shorten decorative movement and smooth scrolling.
- Skip and landmark navigationMove past repeated navigation and identify the main content region.
- Visible keyboard focusInteractive elements receive a high-contrast focus indicator that is not communicated by colour alone.
- Touch and pointer targetsPrimary controls use generous targets; compact inline links remain separated from surrounding actions.
- Live status feedbackCopy, validation, connection, session, and local-demo changes are announced without moving focus unnecessarily.
- Local demo transparencyThe workspace clearly states that responses are samples and no prompt is sent to a live AI provider.
3. Keyboard and focus behaviour
Core pages can be read and operated with a keyboard. Menus expose expanded and collapsed state, modal dialogs keep focus inside while open, and focus returns to the control that opened them. Product laboratory tabs support Arrow keys, Home, End, Enter, and Space through the standard tab pattern.
The AI workspace uses ordinary buttons and form controls rather than pointer-only gestures. Composer instructions distinguish Enter from Shift+Enter, context controls expose pressed state, and menu items remain reachable without hover. The site search can be opened with Control/Command+K or the visible Find control.
4. Visual access, contrast, zoom, and motion
Text and interactive states are designed for readable contrast on both light and dark surfaces. Supporting labels are not intentionally hidden through very small type. Layouts use responsive widths, wrapping, and flexible grids so browser zoom and mobile reflow do not create page-level horizontal scrolling.
Colour is paired with text, shape, position, or state attributes. Focus does not rely only on a colour change. Users who request more contrast through their operating system receive stronger borders and muted-text contrast. Users who request reduced motion receive a calmer experience without decorative reveal or smooth-scroll dependencies.
5. Screen readers and other assistive technology
Boardesa uses semantic HTML before custom roles. Form fields are connected to labels; dynamic updates use status or log regions; disclosure controls expose expanded state and controlled content; decorative graphics are hidden from the accessibility tree; meaningful images require text alternatives.
Screen readers and browsers interpret web standards differently. The current preview is designed around modern combinations, but we do not claim that every feature has been tested with every assistive-technology and browser pair. A report that includes the page, browser, operating system, and assistive technology is especially useful.
6. Known limits
Live AI, file upload, equations from images, accounts, and billing are not active. Their future accessibility cannot be inferred from the present placeholder interface. Before release, those workflows need keyboard, error, progress, timeout, document-structure, math-notation, and assistive-technology testing.
Some graphical product previews are decorative summaries of information that is also present in nearby HTML. They are not intended to replace the written explanation. Third-party email applications opened from the contact page are controlled by their own accessibility support.
Complex mathematical notation is presently shown as text samples rather than a complete accessible math-rendering system. A future solver should provide navigable structure, plain-language alternatives, and copyable notation before it is described as fully accessible.
7. Compatibility target
The practical target is the current and previous major versions of modern Chromium, Firefox, and Safari-based browsers, with responsive support across desktop, tablet, and mobile. Quality checks include keyboard-only use, reduced-motion mode, increased contrast where supported, 200% zoom, narrow reflow, and common screen-reader semantics.
Older browsers may receive the readable HTML experience without every enhancement. The product should fail safely: content remains understandable, controls communicate when an interactive bundle is unavailable, and no essential explanation depends only on animation.
8. Report an accessibility barrier
Use the dedicated accessibility route on the contact page. A useful report includes the affected URL, the task you were trying to complete, what happened, what you expected, device and browser, and assistive technology when relevant. A screenshot is optional. Do not include private student records, passwords, identity documents, payment details, or other unnecessary sensitive information.
Best reporting route
Open Contact → Accessibility issue. The local message builder prepares an email in your browser; it does not submit the report to a Boardesa website database.
9. Testing and review process
Accessibility checks are included in product QA rather than postponed until launch. Current checks cover landmark structure, heading order, names and labels, focus visibility, keyboard paths, target sizing, reflow, reduced motion, dynamic announcements, duplicate identifiers, and contrast on key surfaces.
Automated checks can find only part of the problem. Future releases should also include manual keyboard review, screen-reader walkthroughs, zoom and reflow testing, user feedback, and targeted testing for math, document upload, long AI responses, payment, and account recovery. This page will be updated when active product behaviour or known limits materially change.
ACCESSIBILITY REPORT
Tell us where the path breaks.
Name the page, task, environment, and exact barrier. A focused, non-sensitive example helps us reproduce and prioritize the issue.
Report an accessibility issueGRACEFUL DEGRADATION
Reading and recovery paths survive when scripts do not.
JavaScript powers Boardesa's local demonstrations, storage controls, diagnostics, filters, and install experience. When it is unavailable, the site exposes a visible limited-mode notice, a compact navigation route, readable public content, direct email links, and honest feature boundaries instead of leaving silent controls that cannot work.
Core public information
Tool descriptions, policies, trust pages, pricing status, help text, security reporting guidance, and direct links remain readable.
Local interactive features
Workspace samples, session recovery, diagnostics, filtering, copy actions, consent controls, PWA install prompts, and generated email previews require scripts.
Dead controls are removed
Script-dependent buttons and panels are hidden or replaced with a clear fallback route so keyboard and touch users are not led into an action that cannot complete.
PRINT AND PDF OUTPUT
Readable copies without an upload workflow.
Internal content pages expose a Print / PDF action when JavaScript is available, while the browser’s own print command remains usable directly. Interactive controls, navigation, cookie UI, and decorative scenes are removed from the printed copy; FAQ details are expanded temporarily and restored afterward.
Structured local session sheet
The Session menu can prepare a print-only learning artifact with requests, routes, checkpoints, evidence, next moves, reflection status, and any unsent draft. The print dialog is local to the browser.
Clean reading layout
Policies, guides, tool pages, tables, and help content use a high-contrast print layout with page-break protection and expanded details.
No automatic transfer
Printing or saving as PDF does not upload the page or workspace session to Boardesa. The selected printer or PDF destination remains controlled by the browser and operating system.