Accessibility

YDABlocks teaches a four-block model of how a machine reaches an answer: Blue reads, Green looks around, Yellow thinks, Red answers. A product whose entire subject is colour-coded roles has an obvious problem to solve, and we would rather state plainly how we solve it than leave a buyer to guess.

The commitment underneath everything below is one sentence: colour never carries meaning on its own. Every role is also a word, a position in a fixed order, and — if you want it — a shape and a sound. A learner who sees no colour at all can still use the product as designed.

1. Standard we work to

We target the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. We test with keyboard navigation and screen readers, and we treat an accessibility defect as a defect rather than an enhancement request.

We do not claim a completed third-party audit. Where something is partial, this page says so, because a statement that only lists strengths is not useful to the person who has to rely on it.

2. Colour vision

Three palettes ship, switchable at any time, and the choice is remembered on the device:

• Default — the standard four colours.
• Colourblind-safe— the Okabe–Ito set, chosen because it stays distinguishable across deuteranopia, protanopia and tritanopia rather than only the most common one.
• Monochrome — true greyscale, for total colourblindness (achromatopsia), where hue carries no information at all and only brightness and pattern do.

Any block can also be set to any colour individually. The role never moves when you do it: Green is still "Look Around" even if you make it purple.

A pattern overlay can be turned on independently, adding a distinct texture to every block on top of whatever colour it has — so the four roles remain separable in greyscale, in print, and for anyone who simply finds shape easier to track than hue.

3. Reading and text

• Four text sizes, applied throughout the interface rather than to body copy alone.
• An alternative reading typeface for learners who find the standard face harder to decode.
• Extra letter and line spacing as a separate switch, since spacing and size help different readers.
• A high-contrast mode.
• On phones and tablets the operating system's own text-size setting is honoured directly. We deliberately do not override it — a second in-app slider that fights the device setting helps nobody.

4. Sound

Each block has its own tone — a low tone for Blue, mid for Green, high for Yellow, and a resolving chord for Red — so the sequence of a pipeline can be followed by ear. Sound is an addition, never the only channel, and it can be switched off entirely.

5. Motion

The system-level "reduce motion" preference is detected and respected on first load, and can be overridden by hand for anyone whose need differs from their device setting.

6. Language and direction

The interface supports right-to-left as well as left-to-right layout, and the four block labels can be renamed. Renaming matters more than it sounds: a classroom teaching in another language, or using its own vocabulary for these ideas, can align the product with the words the learners already have.

7. Structure, keyboard and assistive technology

• A skip link to the main content is the first focusable element on every page.
• Interactive controls are reachable and operable by keyboard.
• Headings are used for structure rather than for sizing.
• Controls carry accessible names, and images that convey nothing are hidden from assistive technology.

8. Known limits

We would rather write these down than have you discover them:

• The mobile apps carry the palettes, patterns, sound and per-block renaming, but high-contrast mode and extra text spacing are web-only so far. They are not shipped as toggles on mobile that do nothing.
• The interactive Builder is a drag-and-arrange surface. It is usable without a mouse, but it is the part of the product we are still improving most actively for assistive technology.
• No formal third-party audit or VPAT has been completed yet.

9. Telling us something is wrong

If any part of YDABlocks is not usable for you or for a learner in your care, we want to hear about it specifically — the page, the device, and the assistive technology involved. Write to privacy@ydablocks.com, or use our contact page. Accessibility reports are treated as defect reports and prioritised as such.

Procurement teams needing this in a particular format for a district review should contact us; we will complete your accessibility questionnaire directly.