Accessibility Statement · LessonSmith

Teaching is not a job you can do only with a mouse and perfect eyesight, and lesson planning should not be either. This page says what we have actually checked, what we have not, and what is known to be broken. It is written to be useful rather than reassuring, so it names problems we have not fixed yet.

1. The standard we aim at

We target Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. We are not claiming to meet it. Nobody outside this company has tested LessonSmith, so treat everything below as our own assessment of our own work.

2. The public site

These pages are the marketing pages, the pricing page, the legal pages, and sign-in and sign-up. As of the effective date above the following have been checked in a browser, not merely intended:

• A Skip to content link is the first thing the Tab key reaches on every page, and it moves keyboard focus into the main region rather than only scrolling to it.
• Every interactive element shows a visible focus outline, and tab order follows the order things appear on screen. Nothing uses a positive tabindex to jump the queue.
• Each page has one h1, headings descend in order without skipping a level, and the page is divided into header, navigation, main and footer regions a screen reader can jump between.
• Every link, button and form control has a name a screen reader can announce. Decorative icons are hidden from assistive technology instead of being read out as meaningless graphics.
• Text contrast has been measured, not eyeballed, on every page in this list. Inline links used to sit at 4.35:1 against the page background, just under the 4.5:1 minimum, on every legal page and on the curriculum and schools pages; they were darkened on 8 September 2026 until they cleared it.
• Data tables name their columns, so a screen reader reading a cell can tell you which column it is in.
• The site works in light and dark themes, and animation is dropped for anyone whose system asks to reduce motion.

3. The planning studio

The studio is the signed-in application where you build lesson plans, schemes of work and the term calendar. It is a large, older piece of software with hand-built calendars, dialogs and menus. This page used to say it had never been audited for accessibility, and promised a first audit by 10 August 2026. That audit ran on 8 September 2026, four weeks after the date we gave. It was done by us, not by anyone independent.

What it covered: every screen and every dialog — the generator, the term calendar, the scheme designer, the support-plan drafter, the library, the menus, the settings window, the calendar setup, the assistant and the bug reporter — driven in a real browser at desktop and phone widths, in light and dark, tested with axe-core against WCAG 2.2 A and AA and its best-practice rules, and then again by hand for the two things a tool cannot judge: whether every control has a name, and whether every decorative icon is hidden rather than read out.

What it found, and what changed the same day:

• Nothing was missing a name. All 102 controls we could reach across the five main screens, every form field, and every day button in the month grid already announced themselves.
• Nineteen decorative icons were not hidden, so a screen reader read them out as meaningless graphics next to the control they sit inside. They are hidden now.
• A tooltip element announced itself on every screen as a tooltip with no name. It is hidden from assistive technology now — the controls it describes already carry their own labels.
• Three pieces of text were under the 4.5:1 contrast minimum and were corrected: the date range on the term buttons, the field labels in the phone layout on every dark theme, and the name of the selected subject.
• The month grid is one stop on the Tab key rather than thirty-one, and arrow keys, Home and End move between the days it will let you plan on. We drove that by keyboard to confirm it, and each day announces its date, whether it is a teaching day, what is marked on it and whether it is selected.

What is still unverified is the part that matters most in an application this interactive: whether focus is handled correctly as its dialogs and menus open and close, and whether the reading order makes sense once a screen reader is actually driving it. An automated tool cannot answer either, and we have not sat down with a screen reader and worked through a full lesson plan. Until we have, treat the paragraphs above as "the obvious things are right", not as a pass.

Settings you can turn on

Two switches in the studio, under Settings → Accessibility. Both apply the moment you flip them, on every one of the app's themes, and both stay with your account rather than the device.

• Colour-blind safe colours. Where the app would use green for something that worked and red for something that did not, it uses blue and orange instead. Red and green are the pair most people with colour-vision deficiency cannot separate, and in this app that pair carries real meaning — a plan saved against a plan that failed, a finished scheme against a delete button. The two replacements stay distinguishable under both common forms of red-green colour blindness. Your theme's own colour is not changed; it never means good or bad.
• Extra contrast. Darker labels, stronger borders and a thicker focus outline, on whichever theme you use. It raises the contrast the app already enforces rather than replacing your theme with a high-contrast one.

Neither switch is behind a paid plan. If you need something these two do not cover, section 5 is how to tell us.

4. Known barriers

Listed because we know about them, not because they are acceptable:

• The studio, in the terms of section 3: dialog and menu focus handling and screen-reader reading order are still unverified. This is the biggest one, and it is the part of the product people spend their time in.
• Colour contrast in the studio is enforced in code rather than measured theme by theme. Every one of its themes has its text colours corrected against the surfaces they land on before they are painted, which is why the fixes in section 3 hold on all of them rather than only on the default. We have measured six themes directly. The other eighteen rest on that mechanism being right.
• Arrow keys in the month grid move between selectable days rather than up and down a column, so pressing Down does not always land you a week later. It is navigable; it is not what a keyboard user would predict.
• Three icons inside the sign-in and sign-up forms come from Clerk, the service that handles our accounts, and are not hidden from screen readers. They sit inside buttons that are named correctly, so they add noise rather than confusion, and we cannot change them without working around that service's own markup.
• There is no third-party audit and no VPAT. If your school or district needs one for procurement, tell us and we will say honestly where we are rather than produce a document we cannot stand behind.
• Lesson plans and schemes of work are drafts produced by an AI model. We do not check that the wording they generate meets any readability or accessibility standard for your students.

5. Reporting a barrier

Email support@lessonsmith.ai and describe what you were trying to do, what happened, and the browser or assistive technology you were using. A rough description is fine; you do not need to know the technical name for the problem.

We aim to reply within five working days. We cannot promise a fix by any particular date, and we would rather tell you that than promise one and miss it. If a barrier stops you finishing something, say so and we will look for a way to do it for you in the meantime.

6. If we do not resolve it

If our reply does not settle the matter, you can escalate under Kenya's Persons with Disabilities Act through the National Council for Persons with Disabilities, or through the equivalent body where you live. Nothing on this page limits any right you have under the law that applies to you.

Read together with the Terms of Use and the Support page.