Accessibility

We build Studio against the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. That is our target and the standard we hold new work to.

We are not claiming conformance with it. Studio has not been through an independent accessibility audit, and until it has, saying “we conform” would be a claim we cannot evidence. If your district needs a formal conformance report before staff can use a tool, please contact us and we will tell you honestly where we are.

• Keyboard access. Every control can be reached and operated from the keyboard, with a visible focus outline. Each page starts with a “skip to main content” link. Tables and other scrolling areas are themselves focusable, so their contents can be scrolled without a mouse.
• Screen readers. Pages use real landmarks and a single ordered heading structure. Things that happen without a page change — a resource finishing, feedback saving, an error — are announced rather than only shown.
• Contrast and colour. Text and interface colours are chosen against measured contrast ratios in both the light and dark themes, and colour is never the only way information is conveyed.
• High contrast and reduced motion. Studio respects your operating system’s high-contrast (forced colours) setting and its reduce-motion setting. If you have asked your device to stop animation, Studio stops.
• Zoom and reflow. Pages are built to reflow rather than to scroll sideways, so they work enlarged and on a small screen.

Automated accessibility checks run against every public page of Studio, in both the light and dark themes, every time we change the code. A change that introduces a detectable problem — a missing label, a broken control name, insufficient contrast, a damaged landmark or heading structure — does not ship.

We are deliberate about what that does and does not buy. Automated scanning catches roughly a third of real accessibility problems. It cannot tell you whether a focus order makes sense, whether an announcement is useful, or whether a page is actually usable with a screen reader. Those need a person, and that is the work described in the next section.

We would rather tell you this than have you find it.

• No independent audit has been carried out, and we do not publish a formal conformance report. The work described above has been built and tested by us, not verified by anyone else.
• The PDFs Studio generates are not tagged for screen readers — see section 5 for what to use instead.
• Some of the signed-in application has had less scrutiny than the public pages, because the automated checks run against pages that can be loaded without an account.

This is worth its own section, because it is the part of Studio most likely to reach a student with a print disability.

Every resource can be downloaded as a PDF or as a Word document. The PDF is laid out for printing and is not tagged, so a screen reader will read it poorly or not at all. If the document needs to be read by assistive technology, take the Word version. It carries real headings and real lists, and it can be edited, so you can change the font, the size and the spacing for the student in front of you.

Improving the generated PDFs is on our list. Until it is done, the Word file is the accessible route and we would rather say so plainly.

If something in Studio is unusable for you, tell us and we will treat it as a defect, not a request.

• Email support@teachervision.com. Tell us the page, what you were trying to do, and what assistive technology you use if that is relevant — it makes the problem far easier to reproduce.
• If you need a resource in a format Studio does not produce, ask us and we will help.
• Post: TeacherVision Studio, c/o Sandbox Networks, Inc., WeWork 24th Fl, 1 Lincoln St, Boston, MA 02111, USA. Phone: 1-800-498-3264.

See also the Privacy Policy, the Terms of Use and How Studio uses AI.

Back to TeacherVision Studio