GENbyAIShop

Accessibility

Technology should adapt to people.

Design for different abilities, environments and devices.

A design position, not a compliance badge

We consider accessibility while designing, then check the result.

If text cannot be read or a control cannot be reached, the interface is the barrier. See our approach.

Glare, motion, a small screen or an older device can also create barriers.

Design inputs

The differences we design around

Six areas shape our design choices.

How each difference changes what we build

Vision
Contrast, type size, zoom, screen reader output. So colour pairs are measured rather than eyeballed, type scales with both browser zoom and the site's own text-size control, and the markup carries the structure a screen reader needs in order to move around.
Hearing
Nothing important conveyed by sound alone. So nothing here depends on audio, and no state is signalled by a sound with no visible equivalent.
Mobility
Full keyboard operation, generous targets. So anything that can be clicked is a real link or button that the keyboard can reach and operate, with a focus outline you can see.
Dexterity
No precision gestures, no timed interactions. So there is no drag-only control, no hover-only menu, and nothing that closes or expires while you are still getting to it.
Cognition
Short blocks, plain language, predictable layout. So pages keep the same shape, links say where they go, blocks stay short, and limitations are written in the same plain words as features.
Environment
Glare, small screens, and the hardware you own. So layouts reflow into a narrow window, low-contrast and e-ink screens are treated as normal rather than edge cases, and we design for the hardware you already own.

This website

Conformance statement

This site is built to target WCAG 2.2 Level AA. Testing is incomplete, so we do not claim full conformance.

What has been verified

  • Contrast. Every text colour token was computed against the exact ground it sits on, in both the default and the increased-contrast setting. The tightest margin measured is 5.15:1 against a 4.5:1 requirement; control borders are checked against the separate 3:1 threshold for non-text contrast.
  • Structure. Semantic landmarks on every route — a skip link, one main region, a header and a footer — with exactly one h1 per page and no skipped heading levels.
  • Names. No empty links or buttons, and no duplicate element ids, across every page the build emits.
  • Keyboard. Everything interactive is a real link or button rather than a clickable div, and every one of them has a visible focus indicator that meets the 3:1 threshold against its ground.
  • Motion. There is no autoplay motion, no carousel and no scroll-driven effect; the system reduced-motion setting is respected, and can be overridden in either direction below.
  • Zoom. Never disabled. The viewport declaration sets no maximum scale and does not block pinch zoom.
  • Colour. Nothing is signalled by colour alone. Warnings, required fields and status all carry a text label as well.

What has not been verified

These checks remain open.

  • No screen reader test has been run. The markup is written for one and the semantics were reviewed by reading the emitted HTML. Nobody has sat down with VoiceOver, NVDA or JAWS and listened to it.
  • No reflow test at 400% zoom. WCAG 2.2 asks for content to reflow to a 320 CSS pixel width without horizontal scrolling. The stylesheet is written to do that; it has not been measured in a browser.
  • No automated audit runs in CI. There is no axe check, or equivalent, wired into the build. Everything above was done by hand and by arithmetic, which means it catches what we thought to look for.
  • Focus order has not been walked end to end. Focus is visible and every control is reachable in the markup; nobody has tabbed through a whole page and confirmed the order matches the visual one.
  • The contrast figures are arithmetic, not pixels. They compare colour tokens against flat grounds. Text positioned near the hero artwork is placed clear of it by design, but no rendered pixel under a glyph was sampled.

Adjust this site

Preferences you can set here

Change text size, motion, contrast and focus visibility across the site.

If the defaults block you, please tell us.

Browser zoom still works. Motion follows your system setting unless you override it here.

Display preferences

Saved in this browser only. Nothing is sent to us.

Text size

Scales every text size on the site. Browser zoom keeps working as well.

Motion

We follow your system setting unless you choose otherwise here.

Contrast

Raises contrast above the site's default colour tokens.

Focus visibility

Thickens the outline shown on the element your keyboard is on.

In the products

Accessibility is answered per product

Each product has different features and limits.

BOOX Mirror

  • E-ink is reflective rather than backlit, which some people find easier for long reading and in bright or glare-heavy rooms.
  • The extended desktop is a normal macOS display, so system text size, Zoom, Increase Contrast and Reduce Motion all apply to whatever you move onto it.
  • VoiceOver continues to read the window as a normal macOS window; the display target does not change how it is announced.
  • Control Mac from BOOX requires the macOS Accessibility permission. Without it, the tablet view stays read-only — everything else still works.
  • A physical Bluetooth or USB keyboard attached to the tablet is supported. The BOOX on-screen keyboard is not forwarded to the Mac.

Requirements and limitations on the BOOX Mirror page

Spec Kit hardening

Spec Kit hardening has not shipped. Accessibility has not been reviewed yet.

Feedback

Found a barrier? Tell us.

If something on this site or in one of our products got in your way, email [email protected]. A description of what happened is more useful to us than a standards reference — you do not need to name a WCAG criterion, or know that there is one.

What helps us reproduce it

  • The page address, or the product and the version you are running.
  • What you were trying to do.
  • What happened instead.
  • The browser and operating system, and any assistive technology you were using, if you know them.
  • Whether it stopped you completely or only made the task harder. Both are worth reporting; the first one jumps the queue.

A person reads every one of these and you will get a reply. We have not set a response-time target, so we are not going to quote one — when a report leads to a change, the change is described in the relevant product’s notes or in the statement above.

Email [email protected]Other ways to get help