Math help should work across more ways of reading and interacting

Our accessibility goal

The calculator and learning pages are designed for keyboard operation, readable contrast, meaningful focus states, responsive reflow, semantic headings, form labels, status announcements, and reduced-motion preferences. The target is practical access to the complete solving workflow, not only visual compliance on static pages.

WCAG is a shared technical standard developed through the W3C process. Referencing it here expresses the project’s direction; it does not mean an independent auditor has certified every success criterion.

Features currently implemented

• A keyboard-visible skip link and logical heading hierarchy.
• Native form controls, text labels, accessible button names, and visible focus indicators.
• Responsive layouts that reflow without intended horizontal page scrolling at tested mobile sizes.
• Light and dark themes with semantic color tokens and readable state labels.
• Reduced-motion handling for transitions and scroll behavior.
• Plain-language explanations alongside symbolic algebra and verification states.
• Expandable solution steps and FAQ controls that use native or semantic interaction patterns.

Mathematics notation and assistive technology

Mathematical notation is a known challenge across browser and screen-reader combinations. This release uses readable text, Unicode symbols, structured fractions, and explanatory sentences, but it does not yet provide MathML for every expression or guarantee ideal pronunciation in every assistive technology.

A future math-field upgrade should preserve a plain-text representation and keyboard input rather than replacing accessible controls with a visual-only editor.

Testing approach

Release checks inspect labels, duplicate IDs, heading count, keyboard-relevant controls, viewport overflow, mobile navigation, dark-mode behavior, and browser console errors. Automated checks cannot replace testing with disabled users and a representative range of screen readers, browsers, zoom levels, and input devices.

The project should record and prioritize barriers that prevent entering a problem, running the solver, understanding the result, opening navigation, or reading essential policies.

Accessibility feedback

A useful accessibility report includes the route, control, expected behavior, actual result, browser, operating system, input method, zoom level, and assistive technology. Do not include personal school or health information. Reports can be sent to freealgebraresolver@gmail.com; the Contact page explains response scope and the details that help reproduce a barrier.