Accessibility at TestsAndTools
TestsAndTools is committed to making its website, online tools, calculators, tests, generators, templates, and guides usable by as many people as reasonably possible, including people who use assistive technologies or alternative input methods.
Access is part of product quality
Designed for different ways of using the web
People may navigate by keyboard, switch device, voice input, touch, screen reader, zoom, magnification, captions, high-contrast settings, or other assistive technology. We aim to support these needs through clear structure, understandable controls, responsive layouts, and meaningful feedback.
Accessibility is an ongoing process
TestsAndTools contains a growing mix of page templates, interactive tools, generated results, third-party services, and legacy content. We treat accessibility as continuous work rather than a one-time checklist.
Our accessibility target
We aim to align the TestsAndTools website with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. This statement describes our target, current approach, and improvement process. It is not a certification or a claim that every page and feature currently conforms to every WCAG 2.2 Level AA success criterion.
Perceivable
Information and controls should be available in forms users can perceive, including meaningful text alternatives and sufficient visual clarity.
Operable
Important functionality should be usable without a mouse, with visible focus, reasonable target sizes, and no unnecessary interaction traps.
Understandable
Labels, instructions, navigation, errors, and results should be consistent, predictable, and written in understandable language.
Robust
Semantic markup, names, roles, states, and values should support current browsers and assistive technologies as reliably as practical.
How accessibility is considered in design and development
Semantic structure
We aim to use meaningful headings, landmarks, lists, buttons, links, labels, and form relationships rather than relying only on visual appearance.
Keyboard access
Interactive controls should be reachable and operable by keyboard, with a visible focus indicator and a logical navigation order.
Responsive layouts
Pages and tools are designed to adapt to smaller screens, text wrapping, zoom, and different orientations without avoidable horizontal overflow.
Clear labels and errors
Inputs should have understandable labels, instructions, required-state information, and error messages that explain how to resolve a problem.
Visual clarity
We aim for readable contrast, visible focus, distinguishable controls, legible text, and information that is not communicated by color alone.
Motion and timing
We avoid unnecessary motion, flashing, and short time limits. Where motion is important, we aim to respect reduced-motion preferences when practical.
Alternative descriptions
Meaningful images and non-text content should receive appropriate text alternatives, while decorative content should not create unnecessary noise.
Accessible results
Generated results, validation messages, score changes, and dynamic updates should be understandable and exposed to assistive technologies where practical.
Accessible content
We aim to use descriptive links, concise instructions, consistent terminology, plain language, and tables or code examples that remain understandable.
How we review accessibility
Manual checks
- Keyboard-only navigation and focus visibility.
- Heading structure, link purpose, labels, instructions, and error recovery.
- Zoom, text wrapping, reflow, orientation, and responsive behavior.
- Screen-reader spot checks on representative pages and workflows.
- Review of dynamic results, dialogs, menus, accordions, and custom controls.
Automated and technical checks
- Automated accessibility scans used as a starting point, not a complete assessment.
- Color-contrast checks for text, controls, and focus indicators.
- HTML, ARIA, label, name, role, state, and duplicate-ID checks where practical.
- Testing in current browser versions and representative device sizes.
- Regression review after significant template, component, or tool changes.
Automated tools can identify some issues, but they cannot determine whether every label, alternative text, instruction, interaction, or result is meaningful. Manual evaluation and feedback from users with disabilities remain important.
Areas that may still create barriers
Despite our efforts, some content may not yet meet our accessibility target. Because the site includes older tools, newly released components, generated output, and third-party services, limitations may vary by page.
Legacy and custom interactive tools
Some older custom controls, drawing areas, charts, canvas-based interfaces, drag-and-drop interactions, or dynamically generated results may not expose all information or actions equally to keyboard and screen-reader users.
Alternative: Contact us with the page URL and the result or task you need. We will review the barrier and, where practical, provide guidance or an alternative format.
Third-party content
Advertising, analytics interfaces, embedded media, external widgets, or linked services may have accessibility behavior that TestsAndTools does not fully control.
Alternative: Tell us which third-party component created the barrier so we can investigate, adjust the integration, or identify another route.
Documents, downloads, and generated files
Some downloadable templates, generated images, signatures, exported files, or older documents may not include complete structure, tagging, descriptions, or keyboard-friendly alternatives.
Alternative: Request the information in a different practical format through our contact page.
Language and complex technical content
Formulas, code, symbols, Unicode characters, visual comparisons, and multilingual text may be announced differently across browser and assistive-technology combinations.
Alternative: Include the browser, assistive technology, language, and affected content in your report so we can reproduce the issue.
Report an accessibility problem
What to include
- The exact page URL.
- The task you were trying to complete.
- What happened and what you expected.
- Your device, operating system, and browser.
- Any screen reader, magnifier, voice control, switch device, or other assistive technology used.
- A screenshot or recording when it is safe and practical to share one.
How we handle reports
- We review the report and attempt to reproduce the barrier.
- We consider severity, user impact, frequency, and whether similar components are affected.
- We may ask for additional details when the problem depends on a specific environment.
- We prioritize fixes and practical alternatives based on impact and available resources.
- Material improvements may be added to our ongoing accessibility work.
Contact information
Use the TestsAndTools contact page or email [email protected]. Please use “Accessibility Report” in the subject line and avoid sending sensitive personal information unless it is necessary and safe to do so.
Browsers, devices, and assistive technologies
Intended compatibility
TestsAndTools is designed for current versions of major browsers and responsive use on desktop, tablet, and mobile devices. Accessibility can vary with older browsers, unsupported JavaScript, browser extensions, device settings, and assistive-technology combinations.
Technical foundation
The site relies on HTML, CSS, and JavaScript. Some tools may also use browser APIs, generated files, canvas, local processing, or third-party components. We aim to use native semantic elements before custom ARIA patterns whenever practical.
Questions about accessibility at TestsAndTools
Does this page claim full WCAG 2.2 Level AA conformance?
No. WCAG 2.2 Level AA is our target. This statement does not certify that every page, tool, third-party component, or generated output currently meets every success criterion.
What should I do if a tool cannot be used with a keyboard?
Send us the URL, the control or task that cannot be completed, the keys you tried, and your browser and assistive-technology details. We will investigate the component and consider an alternative workflow.
Can I request information in another format?
Yes. Explain which content or result you need and the practical format that would help. We will review reasonable alternatives based on the content and available resources.
Why can accessibility differ between tools?
Tools may use different components, browser APIs, output formats, and third-party dependencies. Older resources may also predate newer accessibility patterns. We use reports to identify both page-specific and reusable component fixes.
Do automated accessibility tests prove that a page is accessible?
No. Automated checks are useful for detecting certain technical issues, but meaningful labels, understandable instructions, logical interaction, and real assistive-technology use require manual evaluation.