Built to be usable.

1. Our commitment

Noduly is designed to be usable by as many learners as possible — including people who navigate by keyboard, use a screen reader or magnifier, prefer reduced motion, need higher contrast, or rely on browser-level zoom and text resizing. We treat accessibility as part of the product, not a polish-later concern.

2. Standards we aim for

We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA across the home page and every module. WCAG 2.1 AA is the standard most commonly referenced by educational and government accessibility requirements, and it covers contrast, keyboard access, structure, alternatives for non-text content, and many other criteria.

We're aware of WCAG 2.2 and adopt its additional success criteria where practical. We do not currently claim full conformance — see the limitations below.

3. What we've built

Specific accessibility features currently live across the site:

• Semantic structure — pages use proper landmark elements (header, nav, main, article, footer) and a single h1 per page with a logical heading hierarchy underneath.
• Keyboard navigation — every interactive control (links, buttons, form fields, menu triggers, theme toggle) is reachable and operable from the keyboard alone. Modal-style menus close on Esc.
• Visible focus — a high-contrast indigo focus outline appears on any element you tab to, with no outline: none overrides.
• Reduced motion — animations, transitions, and smooth-scroll behavior are minimized when your operating system has "Reduce motion" enabled.
• Light and dark themes — both themes use color tokens chosen to meet contrast guidelines for body and UI text. Your choice persists across visits.
• Touch-target size — interactive controls in the navigation, menu, and footer are sized to at least 44 by 44 CSS pixels.
• Alt text and labels — informative images carry descriptive alt text; decorative imagery is marked as such; icon-only buttons include accessible names via aria-label.
• ARIA where it helps — disclosure widgets expose aria-expanded and aria-controls; the empty search-results state is announced via a polite live region; decorative SVGs are hidden from assistive tech.
• Resizing and zoom — layouts use relative units and remain usable at 200% browser zoom and at increased default font sizes. The viewport meta tag does not restrict user scaling.
• No motion-triggered surprises — there is no autoplaying audio, no auto-scrolling carousel, and no pop-up that interrupts you on load.

4. Known limitations

Honesty matters more than a checklist. Areas we know need more work:

• Module-specific audits. Each interactive module (the Periodic Table, World Countries, and modules that follow) has its own custom UI. We test keyboard navigation and basic screen-reader compatibility on each, but we have not yet completed a full WCAG audit on every module.
• Complex visualizations. Some modules use color, position, or animation to convey information. Where we can, we provide a text-equivalent or table view; where we can't yet, that's a known gap we're working through.
• Drag-and-drop and chart interactions. Some planned modules will rely on drag-and-drop or pointer-driven canvases. We will provide keyboard equivalents, but the experience may differ between input methods.
• Third-party content. Web fonts and any embedded third-party media follow their providers' accessibility characteristics, which we don't fully control.

If you hit one of these — or anything else — please report it. We'd rather know.

5. Browser and assistive-tech compatibility

Noduly is tested on current versions of major browsers (Chrome, Edge, Firefox, Safari) on desktop and mobile. We aim to support recent versions of mainstream screen readers (NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android) and the built-in OS features for zoom, high contrast, and reduced motion.

If you use older or specialized software and something doesn't work, let us know — we may be able to fix it without dropping support for what you use.

6. Reporting a barrier

The fastest way to tell us about an accessibility problem is by email: nodulydesk@gmail.com. Helpful details:

• The page or module URL.
• What you were trying to do, and what happened instead.
• The browser, operating system, and any assistive technology you were using (with version numbers if you have them).
• A screenshot or short screen recording, if that's easier than describing.

We aim to acknowledge accessibility reports within a few days and to fix critical barriers in the next reasonable update cycle.

7. What's next

Ongoing accessibility work on our list:

• Per-module accessibility statements as each new module ships.
• Skip-links on long pages.
• Continuing automated and manual audit coverage as the site grows.
• Documenting alternative-input patterns (keyboard-only, voice, switch) for any module that uses pointer-driven controls.

This page will be updated as that work lands. The "Last updated" date at the top reflects the most recent revision.