Skip to main content

Accessibility at Teachfloor

A customer-facing guide to the accessibility features built into the Teachfloor platform — mapped to the Web Content Accessibility Guidelines (WCAG) 2.2.

Written by Filippo Schiano di Pepe

Accessibility at Teachfloor

Last updated: May 2026 · Conformance target: WCAG 2.2 Level AA

At Teachfloor we believe great learning experiences should be available to everyone — regardless of ability, device, or assistive technology. This article describes the accessibility features built into the Teachfloor platform, how we map them to the Web Content Accessibility Guidelines (WCAG) 2.2, and where we are still improving.

TL;DR

  • We target WCAG 2.2 Level AA and currently meet most of its success criteria.

  • The platform is keyboard accessible, screen-reader friendly (NVDA, JAWS, VoiceOver), and supports closed captions and transcripts for video content.

  • Our UI is available in multiple languages with semantic HTML and proper form labeling.

  • We openly document known gaps and the improvements on our roadmap.

  • Feedback is welcome at [email protected].

1 How we structure accessibility

WCAG 2.2 organizes accessibility around four guiding principles, often called POUR:

Principle

What it means

Our status

👁️ Perceivable

Content can be perceived by all users

Mostly Met

⌨️ Operable

The interface can be operated by all users

Mostly Met

🧠 Understandable

Content and behavior are predictable and clear

Met

🛠️ Robust

Content works with current and future assistive tech

Mostly Met

Perceivable

Information and UI components are presented in ways users can perceive — across vision, hearing, and assistive tools.

  • Color contrast (AA). All text meets WCAG AA contrast ratios: 4.5:1 for normal text, 3:1 for large text.

  • Image alt text. Meaningful images (course covers, avatars, content uploads) carry descriptive alternative text for screen readers.

  • Video captions. Uploaded video content supports closed captions for deaf and hard-of-hearing learners.

  • Video transcripts. Transcripts are available for video content, enabling read-along, search, and offline study.

  • No autoplay. Audio and video never play automatically. Playback is always under explicit user control.

  • Semantic heading structure. Pages use a logical heading hierarchy so screen readers can navigate efficiently.

  • Screen reader landmarks. Navigation, main, and footer landmarks are exposed so assistive tech can jump between regions.

  • Color-independent information. Status, errors, and selections are conveyed with text and icons — never by color alone.

3 Operable

All functionality is available from a keyboard and works for users navigating without a mouse or with motor impairments.

  • Full keyboard navigation. Every interactive element is reachable via Tab, Enter, Space, and arrow keys.

  • Visible focus indicators. Buttons, links, and form fields display a clear focus outline during keyboard navigation.

  • No keyboard traps. Modals, dropdowns, and overlays can always be exited with Esc or Tab.

  • Logical tab order. Tab order follows the visual flow of the page so navigation feels natural.

  • Unique page titles. Every page has a descriptive, unique title to help orient users and assistive tech.

  • Descriptive link text. Links describe their destination in plain language — no opaque "click here".

  • No flashing content. No content flashes more than 3 times per second.

  • Touch targets ≥ 24 × 24 px. Interactive controls meet the WCAG 2.2 minimum touch target size (SC 2.5.8).

  • Drag-and-drop alternatives. Reordering content can also be done via click and keyboard (WCAG 2.2 SC 2.5.7).

  • Search & breadcrumb navigation. Global search and breadcrumbs help users locate themselves throughout the product.

4 Understandable

Content and operation behave in predictable, consistent ways — with clear guidance and helpful error handling.

  • Language attribute. Pages declare the correct language so assistive tech uses the right pronunciation.

  • Consistent navigation and labels. Menus, buttons, and component labels remain stable across the product.

  • Clear form errors. Errors are identified in text (not color alone) with suggestions on how to correct the input.

  • Required field marking. Required inputs are marked visually and exposed programmatically.

  • Confirmation on destructive actions. Delete and other irreversible actions require explicit confirmation or offer undo.

  • Accessible authentication. Login supports password managers, OAuth, and magic-link flows — no cognitive captcha barriers (WCAG 2.2 SC 3.3.8).

  • Persistent form data. Information already provided earlier in a flow is preserved and pre-filled where appropriate (WCAG 2.2 SC 3.3.7).

5 Robust

Content remains compatible with current and future browsers, devices, and assistive technologies.

  • Valid HTML5. Pages render against valid, well-formed HTML so assistive tech can parse them reliably.

  • ARIA attributes. Custom widgets use ARIA roles, labels, and states. Coverage is being expanded across the product.

  • Live region announcements. Dynamic states are announced to screen readers. Expansion in progress.

  • Screen reader support. Tested with NVDA (Windows), JAWS (Windows), and VoiceOver (macOS / iOS).

  • Browser support. Latest two versions of Chrome, Firefox, Safari, and Edge — across desktop and mobile.

6 Inclusion beyond WCAG

Some capabilities don't map to a specific WCAG success criterion but materially improve accessibility for a global audience.

  • Multi-language interface. The Teachfloor UI is available in multiple languages, supporting cognitive accessibility for non-English speakers.

  • Keyboard shortcuts. Selected areas of the product offer keyboard shortcuts for power users.

  • System theme compatibility. The interface works with browser-based high-contrast and dark-mode extensions.

  • Mobile-first responsive design. The platform adapts across desktop, tablet, and mobile.

7 Known limitations

We believe a credible accessibility program acknowledges what is not yet in place. The following items are tracked on our roadmap:

  • Text resize to 200% — not yet fully validated across all views

  • Reflow at 320 px viewport — not yet fully validated

  • Audio descriptions for video (transcripts available today, audio descriptions not yet)

  • "Skip to main content" link — not present on all pages

  • Session timeout warnings before expiration

  • Pause / stop controls for auto-updating content

  • Full ARIA coverage on every custom widget

  • Live region announcements for all dynamic states

8 What we're working on

  • Public Accessibility Statement — formalizing this article into an evergreen statement.

  • Independent audit — full review using Lighthouse, axe DevTools, and WAVE.

  • VPAT 2.5 / Accessibility Conformance Report (ACR) — for enterprise and government procurement.

  • Gap closure — scheduled accessibility sprints addressing the items above.

  • External validation — engaging a specialist accessibility consultancy.

9 Standards & references

Web Content Accessibility Guidelines (WCAG) 2.2 — published by the W3C: w3.org/TR/WCAG22

WCAG 2.2 success criteria specifically referenced in this article: SC 2.5.7 (Dragging Movements), SC 2.5.8 (Target Size Minimum), SC 3.3.7 (Redundant Entry), SC 3.3.8 (Accessible Authentication Minimum).

Reporting an accessibility issue

If you experience an accessibility barrier on Teachfloor, please contact us — we treat accessibility feedback as a product priority.

Did this answer your question?