A file tool should not require perfect hands

1. What is in place

• Semantic structure. Pages use landmarks — header, navigation, main, footer — with one h1 and a logical heading order.
• Skip links. The first Tab press offers a link straight to the tools or the article, past the navigation.
• Visible focus. Interactive elements have a visible focus ring that is not removed for aesthetic reasons.
• Keyboard operation. Menus, dialogs, file pickers, theme controls and the command palette can be reached and operated without a mouse. The palette opens with Ctrl+K (or —+K).
• Reduced motion. The animated background and hover transitions are disabled when the operating system requests reduced motion.
• No time limits. Tools do not expire, count down, or log you out. There is no CAPTCHA and no —prove you are human— step.
• No autoplay. Audio and video previews do not start on their own.
• Responsive text. The layout reflows at 200% zoom and on narrow screens without a horizontal scrollbar for the main content.
• Labels and instructions. Form fields have visible labels, buttons say what they do, and errors are written as sentences rather than colour alone.
• Two themes. Light and dark modes are both checked for contrast; the choice is remembered locally.

2. Keyboard shortcuts

If a shortcut conflicts with your browser or assistive technology, the browser wins. Every action reachable by a shortcut is also reachable through ordinary links and buttons.

3. Screen readers

Pages have document titles, language attributes, landmark roles and descriptive link text. Icon-only buttons carry accessible names; decorative icons are hidden from the accessibility tree. Status messages — a copied link, a contact draft opening — use aria-live so they are announced rather than only changing colour.

The site has been checked with browser accessibility trees and keyboard navigation, but it has not had a full audit with every screen-reader and browser combination. That is an honest gap, not a claim of completeness. If something is announced badly or not at all, the report is genuinely useful.

4. Visual accessibility

Text is sized in relative units and reflows at 200% zoom. The palette is checked in both themes for contrast, and information is never conveyed by colour alone: errors have text, success has text, and the selected theme has a label. The animated aurora behind the header is decorative, pauses under reduced motion, and sits behind the content rather than over it.

Charts and previews are not the only way to get a result. For example, the image compressor reports the output size as text, and the PDF page tools list page numbers in text. If a visual preview is the only route to a setting, that is a bug worth reporting.

5. Known limitations

• Canvas-based tools. Cropping, drawing a signature, and some image positioning tools rely on pointer coordinates. They can be difficult or impossible to use with a screen reader alone. A text-based alternative exists for some settings, but not all; this is the biggest accessibility gap on the site.
• Drag and drop. Every drop zone also has a file-picker button, so drag-and-drop is never the only route. The visual drop area may still be described as a button rather than a drop target.
• Complex tool panels. A few advanced tools have dense controls that are usable with a keyboard but tiring to tab through. Grouping and shortcut improvements are planned.
• Video previews. The video tools show a visual preview and a timeline. The output is still available as a download, but frame-accurate trimming is a visual task.
• Third-party engines. OCR and video engines produce their own progress messages, which are not always announced. The page provides a text status alongside them where possible.
• No formal certification. The site has not been audited by an external accessibility specialist. The target is WCAG 2.2 AA; the current state is —most content, with known canvas gaps—.

6. Report a barrier

If a page, menu or tool is hard to use with a keyboard, a screen reader, a switch device, high contrast mode or a small screen, please say so. Useful details:

• The page or tool, and what you were trying to do.
• Your browser, operating system and assistive technology (name and version).
• What happened, and what you expected instead.

Use the feedback form and choose —Accessibility barrier—. Accessibility reports are treated as bugs, not as feature requests. There is no charge for reporting and no need to prove the problem is severe.

This statement will be updated when the known limitations change. The date at the top is the last review, not the date the site was launched.