Accessibility Statement

Last updated: January 15, 2025

Our Commitment

ToolsKit is committed to ensuring digital accessibility for people with disabilities. We believe everyone deserves equal access to useful tools, and we are continually improving the user experience for everyone by applying the relevant accessibility standards. Accessibility is not an afterthought — it is a core part of how we design and build our tools.

We recognize that accessibility is an ongoing process, not a destination. As web standards evolve and our tools grow, we continuously evaluate and improve our accessibility practices to ensure all users can fully interact with our site and tools.

WCAG compliance level

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at the AA level. These guidelines, published by the World Wide Web Consortium (W3C), explain how to make web content more accessible for people with disabilities and more user-friendly for everyone. The AA level is the standard used by government agencies, educational institutions, and organizations worldwide.

Our goal is to achieve substantial conformance with WCAG 2.1 Level AA across all pages and tools on the site. We are actively working toward full conformance and conduct regular audits to identify gaps. We are also monitoring the upcoming WCAG 2.2 and WCAG 3.0 standards to ensure we remain aligned with best practices as they evolve.

Keyboard navigation

All tools, navigation elements, interactive controls, and links can be accessed and operated entirely using a keyboard. No mouse or touch interaction is required to use any feature on the site. Specifically:

  • Tab order: Focus follows a logical sequence that matches the visual layout of the page. You can tab through all interactive elements — links, buttons, form fields, and tool controls — in the order you would expect.
  • Arrow keys: Within composite widgets like dropdown menus and tab panels, arrow keys navigate between options. This follows the WAI-ARIA Authoring Practices for each widget type.
  • Enter and Space: Buttons and links activate with Enter or Space. Checkboxes toggle with Space. Select menus open with Enter or Space and navigate with arrow keys.
  • Escape: Modals, dropdowns, and popups close when you press Escape. Focus returns to the element that triggered the popup.
  • No keyboard traps: You can always tab away from any element. There are no keyboard traps where focus gets stuck in a component with no way to escape.

We test keyboard navigation manually by putting down the mouse and completing common tasks — uploading a file, processing it, downloading the result — using only the keyboard. If any step requires a mouse, we fix it before launch.

Screen reader support

All interactive elements have proper ARIA (Accessible Rich Internet Applications) labels, roles, and states. Form fields are programmatically associated with their labels, and dynamic content updates are announced to screen readers using ARIA live regions. Specifically:

  • ARIA labels: Every button, link, and interactive control has a descriptive label that screen readers announce. Icons without visible text have aria-label attributes.
  • ARIA roles: Custom widgets use appropriate ARIA roles (button, tab, tabpanel, dialog, etc.) to communicate their purpose to assistive technology.
  • ARIA states: Dynamic state changes (expanded/collapsed, selected/unselected, checked/unchecked) are communicated via ARIA attributes that screen readers monitor.
  • Live regions: When tool results appear, processing status updates, or error messages display, ARIA live regions announce these changes to screen reader users without requiring them to navigate to the changed area.
  • Landmark regions: The page uses semantic HTML5 landmark elements (nav, main, section, aside, footer) so screen reader users can jump between page regions quickly.

We test with NVDA on Windows and VoiceOver on macOS and iOS. We verify that all controls are announced correctly, that the reading order makes sense, and that dynamic content updates are communicated to screen reader users.

Color contrast

We maintain minimum color contrast ratios of 4.5:1 for normal text and 3:1 for large text, meeting WCAG AA requirements. All text and interactive elements are readable against their backgrounds in both light and dark modes. Specific contrast requirements we follow:

  • Normal text: Minimum 4.5:1 contrast ratio against the background
  • Large text (18pt+ or 14pt+ bold): Minimum 3:1 contrast ratio against the background
  • Interactive elements: Minimum 3:1 contrast ratio for borders, icons, and focus indicators
  • Placeholder text: Meets the same contrast requirements as regular text
  • Error states: Error messages and validation indicators have sufficient contrast to be clearly visible

We test color contrast in both light mode and dark mode, because colors that have sufficient contrast in one mode may not in the other. Our color palette is designed to meet WCAG AA contrast requirements in both modes.

Focus indicators

Clear, visible focus indicators show which element currently has keyboard focus. Focus order follows a logical sequence that matches the visual layout of the page. Our focus indicators are designed to be visible against any background color used on the site:

  • Visibility: Focus indicators are visually distinct from the element's default state, using a combination of outline, border, and/or background color changes.
  • Contrast: Focus indicators have sufficient contrast against both the element and the surrounding background.
  • Consistency: All interactive elements use a consistent focus indicator style, making it easy to recognize when an element has focus.
  • Size: Focus indicators are large enough to be clearly visible without being obtrusive.

We do not remove or hide focus indicators for aesthetic reasons. Some sites disable focus outlines to improve visual appearance, but this makes keyboard navigation impossible for users who rely on visible focus cues. We believe visible focus indicators are essential for accessibility.

Skip links

Skip-to-content links are provided at the top of each page, allowing keyboard and screen reader users to bypass repeated navigation and go directly to the main content. When you press Tab on any page, the first element you encounter is a skip link that says "Skip to main content." Activating this link moves focus directly to the main content area, bypassing the navigation menu.

This is particularly important for screen reader users who hear the entire page content in sequence. Without skip links, they would need to listen through the full navigation menu on every page before reaching the content they came for.

ARIA labels and semantic HTML

We use semantic HTML5 elements (nav, main, section, article, aside, footer) to provide meaningful structure that assistive technologies can interpret correctly. When semantic HTML is not sufficient for a custom widget, we supplement with ARIA attributes:

  • Form labels: Every form input has a programmatically associated label using the for/id pattern or by wrapping the input in a label element.
  • Button labels: Buttons that perform specific actions have descriptive labels. Icon-only buttons include aria-label attributes.
  • Image alt text: All meaningful images include descriptive alt text. Decorative images are marked as presentational (alt="" or role="presentation") to prevent unnecessary screen reader announcements.
  • Table headers: Data tables use proper th elements with scope attributes to associate headers with data cells.
  • Error identification: Form validation errors are clearly identified in text, with suggestions for correction. Error messages are programmatically associated with the relevant form fields using aria-describedby.

Tool-specific accessibility

Each tool on ToolsKit is designed with accessibility in mind. File upload areas have clear labels and instructions. Interactive controls such as buttons, sliders, and dropdowns follow WAI-ARIA Authoring Practices. Results are presented in both visual and text-based formats to accommodate different assistive technologies. Where tools produce visual outputs (such as formatted resumes or citations), text-based alternatives are always available.

For tools that involve file uploads, we provide multiple methods for selecting files: drag-and-drop, a browse button, and direct file input. All three methods are fully accessible via keyboard and screen reader. For tools that produce downloadable files, we provide clear links with descriptive text that indicate the file type and size.

Responsive design and zoom

All content and tools are fully functional and readable at 200% browser zoom without horizontal scrolling. Layouts adapt gracefully to different screen sizes and orientations. This means:

  • Text resizing: All text can be resized up to 200% without loss of content or functionality
  • Reflow: Content reflows at 320px width (equivalent to 400% zoom) without requiring horizontal scrolling
  • Touch targets: Interactive elements are large enough to be easily tapped on touch devices (minimum 44x44 pixels)
  • Orientation: The site works in both portrait and landscape orientations

Known limitations

While we strive to ensure full accessibility, there may be some limitations that we are actively working to address:

  • Third-party embedded content: Some external resources or third-party content may not fully conform to our accessibility standards. We work to minimize reliance on such content.
  • Complex interactive tools: Some advanced tool features may have accessibility edge cases that require improvement. We prioritize accessibility in our development roadmap.
  • Browser compatibility: Accessibility features may behave differently across different browsers and assistive technology combinations. We test across major browsers and screen readers to minimize inconsistencies.

We document known limitations and track them in our development backlog. We prioritize fixing accessibility issues and aim to address them in regular update cycles. If you encounter an accessibility issue, please report it to us — your feedback helps us prioritize fixes.

Technical specifications

ToolsKit is designed to be accessible with the following technologies:

  • HTML5 with semantic markup
  • CSS3 for visual presentation and responsive layouts
  • JavaScript with ARIA support for interactive elements
  • ARIA 1.2 for enhanced accessibility semantics

We ensure compatibility with major assistive technologies including screen readers (JAWS, NVDA, VoiceOver), screen magnifiers, and alternative input devices.

Assessment approach

ToolsKit assesses accessibility through a combination of methods:

  • Automated testing: We run automated accessibility audits using industry-standard tools to catch common issues such as missing alt text, color contrast failures, and HTML validation errors.
  • Manual testing: We perform manual keyboard-only navigation testing and screen reader testing to identify issues that automated tools cannot detect.
  • User feedback: We actively solicit and respond to accessibility feedback from users with disabilities. Real-world usage reveals issues that lab testing may miss.
  • Regular reviews: We conduct periodic accessibility reviews of all pages and tools, particularly after major updates or feature additions.

Feedback mechanism

We welcome your feedback on the accessibility of ToolsKit. If you encounter any accessibility barriers, have suggestions for improvement, or need information in an alternative format, please let us know by contacting us. We aim to respond to accessibility-related feedback within 5 business days and will work to address any reported issues promptly.

When reporting an accessibility issue, please include:

  • The page URL where you encountered the issue
  • A description of the barrier you experienced
  • The assistive technology you were using (if applicable), including the browser and operating system
  • Any suggestions for improvement

This information helps us identify and resolve issues more effectively. We take every accessibility report seriously and will follow up with you about the resolution.

Formal complaints

If you are not satisfied with our response to your accessibility concern, you may contact the U.S. Department of Justice, Civil Rights Division, Disability Rights Section, or your local accessibility ombudsman for guidance on filing a complaint.

Standards and guidelines

This accessibility statement is informed by the following standards and best practices:

  • Web Content Accessibility Guidelines (WCAG) 2.1 Level AA
  • WAI-ARIA 1.2 (Accessible Rich Internet Applications)
  • Section 508 of the Rehabilitation Act
  • Americans with Disabilities Act (ADA)
  • European Accessibility Act (EAA)
  • EN 301 549 (European standard for ICT accessibility)