Accessibility statement
This statement describes how the pages and the in-browser workspace are built for people who use a keyboard, a screen reader, a magnifier or reduced-motion settings, and it lists what is not yet right. It describes implementation and intent, not a completed conformance audit.
Last updated:
The site targets WCAG 2.1 level AA: semantic HTML with a correct heading order, a skip link to the main content, a visible focus ring on every interactive element, ARIA live regions for indexing and generation progress, support for reduced-motion preferences, and body text aimed at a contrast ratio of at least 4.5:1. No external accessibility audit has been carried out, so this page reports what the code does and where it falls short rather than claiming certification.
What this statement covers
It covers the static pages served from this domain and the workspace that runs inside the browser tab, as shipped in v0.1 on 2026-09-17. It does not cover third-party advertising served by Google AdSense, whose markup and behaviour we do not control, nor the model files downloaded from a public model host.
Structure and semantics
- One h1 per page, followed by h2 sections and h3 subsections in order, so a screen reader can jump between headings without meeting a skipped level.
- A skip link, worded “跳到主要内容” in the Chinese pages and “Skip to content” in the English ones, moves focus directly to the main element.
- Navigation regions carry labels: the header navigation is labelled Main, breadcrumbs are labelled Breadcrumb, the language switcher is grouped and labelled Language, and the table of contents on long pages is labelled “On this page”.
- The advertising slot is marked as a complementary region and labelled Advertisement in English and 广告 in Chinese, which is also the visible label on the slot.
- Lists, tables and multi-step instructions use real list, table and step markup rather than styled paragraphs, so the count of items and the relationship between a table cell and its column header are available to assistive technology.
- Headings on long pages carry a hidden anchor link with tabindex -1 and aria-hidden, so the anchor does not add a tab stop or a duplicate announcement.
- A lang attribute is set on the html element for each language, and the Chinese pages are served with Simplified Chinese as that language.
Keyboard use
Every action in the workspace is reachable with the keyboard alone, including adding files: the drop zone contains a button that opens the system file picker, so drag and drop is a shortcut rather than the only route in.
| Key | Behaviour |
|---|---|
| Tab, Shift+Tab | Move focus forward and back through links, buttons, form controls and the question box |
| Enter | Send the question when the question box has focus; activate a focused button, link or summary |
| Shift+Enter | Insert a line break in the question box instead of sending |
| Space | Activate a focused button or toggle a checkbox or switch |
| Arrow keys | Move within native select lists and radio groups, and move the caret inside text fields |
| Page scroll keys, Home, End | Behave as the browser normally does; the question box does not capture them |
The workspace panels are labelled regions, so a screen reader can move between the documents panel, the chat panel, the settings panel and the local-processing panel by region rather than by counting elements.
Focus visibility
Focus is never removed. Interactive elements show a 2.5px outline offset by 3px from the element, defined once for the whole site with :focus-visible, so it appears for keyboard users and does not flash for mouse users. The question box has its own visible focus outline. The skip link is invisible until it receives focus, at which point it is displayed near the top of the page and is the first tab stop.
Motion, colour and contrast
- Animations and transitions are turned off when the operating system requests reduced motion: one rule in the global stylesheet disables all animations and transitions and stops smooth scrolling, and the workspace stylesheet stops the typing indicator in the chat panel.
- Body text is aimed at a contrast ratio of 4.5:1 or better against its background, and no information is conveyed by colour alone: the strictness control is a group of two named options, “Documents only” and “Allow inference”, each with its consequence spelled out in words, and indexing progress is announced as a stage name and a count rather than only as a filled bar.
- In the document list each file carries a three-letter type label (PDF, DOC, TXT) plus its page count and its chunk count as text, and a document that is switched off is marked “excluded” in words rather than by a colour change alone.
- The article layout is fluid down to phone widths, and a wide table scrolls inside its own container, an element with horizontal overflow, rather than widening the page.
Progress and status announcements
Indexing and model download report progress to assistive technology through live regions marked polite, so the announcement waits for a pause instead of interrupting. The progress text names the stage as it happens: reading the file, splitting it into chunks, embedding, indexed. Where a count exists it reports items done out of the total, and a model download reports megabytes loaded against the total. Errors appear in a region announced as an alert, with a labelled dismiss control. The confirmation shown before the optional generation model is downloaded is a dialog marked as modal, containing the size and two buttons, one to confirm and one to cancel.
What is not good enough yet
Four known gaps, written down rather than left for you to discover:
- The download confirmation dialog does not trap focus or close on Escape. Tab can leave the dialog behind, and the way out is to tab to the cancel button and press Enter or Space. Focus trapping is the next item on this list that we intend to fix.
- On phones, the Docs, Chat and Settings switcher is three plain buttons inside a labelled navigation region. It does not implement the tablist pattern: a screen reader hears three buttons and cannot tell which panel is currently shown from the markup alone, and the left and right arrow keys do not move between them.
- The workspace illustration on the home page is a marked image with a short text label rather than a description of the interface. A screen reader user gets the label, not the layout, the field positions or the order of the panels.
- Testing so far is manual and browser-based, on desktop Chrome and Edge with a keyboard only. No audit by an external accessibility specialist has been completed, and mobile screen readers have not been covered, so the honest summary is that the intentions above are implemented in code and partially verified, not verified end to end.
Reporting an accessibility problem
Write to guweiicy@gmail.com and describe the page or the panel, the assistive technology and version you are using, and what happened instead of what you expected. A keyboard trap that makes a control unreachable is treated as a bug rather than a suggestion, and it is fixed before any cosmetic work. If you use a screen reader and something is announced twice or not at all, the exact wording you heard is the most useful thing you can send.
How this page changes
The list of known gaps above is the part of this page that is expected to change. When one of them is fixed, it is deleted from that list and described in the changelog on the same day; when a new gap is found, it is added there rather than quietly dropped.