Skip to content

Accessibility Statement

What this site does, and honestly, what it hasn't done yet.

Last updated:

This page is written in plain English and reflects how SkillAIVibe actually works today. It is kept up to date as the site changes. If anything is unclear, contact us.

Our aim

SkillAIVibe should be usable if you navigate by keyboard, read with a screen reader, need larger text, or prefer reduced motion. This is a text-first educational site. Written lessons do not require video playback, and DSA visualizers advance automatically only after you select Play. You can pause them or move through one step at a time.

What the site currently does

  • Keyboard navigation. The site uses standard links, buttons and labeled search inputs, with visible focus styles. These controls are intended to work by keyboard. We have not verified every interaction with every assistive technology.
  • Skip link. A "Skip to content" link is the first thing focused on every page, and it jumps to the main content region, so keyboard and screen reader users can bypass the navigation.
  • Semantic structure. Pages use real headings in order, real lists, navigation and footer landmarks, and one main content region. Each page has exactly one level-one heading that names what the page is, so assistive technology can navigate by structure rather than guesswork.
  • Page language. The site declares English as its language, which is what tells a screen reader how to pronounce the text.
  • Labeled controls. Search inputs have real labels, and icon-only controls (like the menu toggle and search icon) carry text alternatives rather than relying on the icon alone. Toggle buttons report whether they are on or off, so a lesson marked complete is announced as such.
  • Link text that makes sense alone. Links are written to describe where they go, so a list of links read out of context is still meaningful. Breadcrumb trails on deeper pages show where you are.
  • Reduced motion. The small hover animations on cards and buttons, and the smooth scrolling behavior, are switched off automatically when your system is set to reduce motion. Running-code indicators also stop pulsing. Visualizer playback is optional and starts only when you select Play.
  • Color and contrast. The palette was chosen for readable contrast in both themes, with body text set against plain backgrounds rather than gradients or images. Color is never the only way information is conveyed — anything marked by color also carries a word or a symbol.
  • Light and dark themes. Your first visit uses your system color scheme. The theme button lets you choose light or dark, and that choice is saved locally for later visits.
  • Responsive text. Layouts use relative units and reflow rather than breaking when you zoom in or use a small screen, and text can be enlarged by browser zoom without content being cut off.
  • Text-first lessons. Written explanations and code examples remain readable as text. Decorative icons are hidden from assistive technology where they add no information; interactive DSA visualizers also include written descriptions of each step.
  • Reading and interactive features. Article and tutorial text, definitions and exercise instructions are rendered as ordinary page content without an account. Running code, local search, interview practice and interactive solution reveals need JavaScript. Saving and progress marks also use JavaScript and browser storage. These requirements are separate from reading the written learning material in the Learn to Code section.
  • The code editor does not trap you. Inside the editor, Tab indents code the way programmers expect, so it cannot also move focus. Pressing Escape and then Tab leaves the editor, and that instruction is printed under every editor rather than left for you to discover. The Run and Reset buttons come before the editor in tab order, the output panel is labelled and reachable by keyboard, and the result of a run is announced to screen readers as well as drawn.
  • No time limits and nothing that flashes. No page expires, times out, or moves you along before you are ready, and there is no flashing or strobing content anywhere on the site. You can take as long as you like on a lesson.
  • Navigation and analytics preferences. The mobile menu opens when you select its button and reports whether it is open. When optional Google Analytics is configured, an analytics preference panel appears until you make a choice. Both Accept and Reject are keyboard-accessible, and rejecting analytics leaves learning features available. This non-modal panel does not move focus automatically. After choosing, you can reopen it using Analytics settings.

What we use as a reference

When we decide what "accessible enough" means for a change, the reference point is the Web Content Accessibility Guidelines — the same guidelines most accessibility law around the world is built on. They are what we read to answer questions like how a control should be labeled or whether contrast is sufficient.

Using them as a guide is not the same as conforming to them, and we are not claiming conformance at any level. There is a real difference between a site written with the guidelines open and a site that has been tested against them properly, and this one is the first kind. The section below says where that shows.

Where we fall short

We would rather list these than claim a level of compliance we have not earned:

  • This site has not been formally audited against WCAG 2.1 or 2.2 by an accessibility professional, and we do not claim a conformance level. Our checks have been self-conducted.
  • Color contrast has been chosen carefully but not verified exhaustively across every element and both themes.
  • We have not tested with the full range of screen readers and assistive technologies in real-world use, and we have not tested with voice control software or switch devices at all.
  • Some pages carry long lists of links, and the prompt templates are shown in a preformatted block, which some screen readers announce line by line in a way that can be awkward to follow.
  • The code editor is a third-party component (CodeMirror). It works with screen readers, but editing code by ear is inherently harder than reading prose, and we have not tested every screen reader with it. Every exercise's starter code and solution are also shown as ordinary text on the page.

Saying "we aim to comply with WCAG" and leaving it there is common and close to meaningless. The list above is what we actually know.

Settings on your side that this site respects

Some of the most effective adjustments are ones you make in your own browser or operating system rather than on a site. These all work here, and none of them require a setting from us:

  • Zoom and larger text. Zoom in as far as you find comfortable. The layout reflows into a single column instead of forcing you to scroll sideways, and text is set in relative units, so a larger default font size in your browser is honored rather than overridden.
  • Reduced motion. Turn on your system's reduce motion setting and the small hover movements and smooth scrolling stop. Nothing else on the site relies on animation to make sense.
  • Dark or light. Your system color scheme supplies the initial theme when no saved choice exists. Use the theme button to change a previously saved preference.
  • Reader modes and text extraction. Because pages are ordinary text with proper headings, browser reader modes, read-aloud features, and save-for-later tools handle them well. A lesson can be read outside the site without losing its structure.
  • Custom stylesheets and high contrast. Nothing on the site depends on a background image or a gradient to be legible, so a high-contrast mode or your own stylesheet has a fair chance of working properly.

Tell us if something breaks

If any part of this site is hard or impossible to use with your setup, please tell us through the Contact page or at contact@skillaivibe.com, and describe what happened and what you were using — the page address, your browser, and your assistive technology if you use one. Specific reports are genuinely more useful than general ones, and accessibility bugs get treated as real bugs rather than nice-to-haves.

One person reads that inbox, so a reply may take a few days. We will tell you what we found and what we changed, and if something cannot be fixed quickly we will say so rather than leave you waiting.

If a page is inaccessible to you and you need its content, say so — we will send it to you in a readable format while we fix the underlying problem.

How this statement is kept current

This page describes the site as it is today, not a plan. When the site changes in a way that affects any statement above, this page is updated and the date at the top moves with it. If we ever do have a professional audit, the result will be published here whether it is flattering or not.

Third-party sites

Our AI Tools Directory links to external products we do not control. We cannot make any promises about the accessibility of those sites once you leave ours, and their own accessibility statements, where they have one, are the place to look.