Accessibility statement

Effective 27 September 2026.

What we aim for

The target is WCAG 2.2 level AA. For a site made of calculators and file converters, the criteria that decide whether it is usable rather than merely legal are the ones about keyboards, focus, target size and text alternatives — 2.4.7 and 2.4.11 (focus visible, and never hidden by other content), 2.5.7 (dragging movements have a single-pointer alternative) and 2.5.8 (target size). Each of those is answered below with what the site actually does, and the last section says how the answers are checked and re-checked rather than asserted once.

With a keyboard

• The first Tab press offers a way past the navigation on browsers where Tab reaches links. Every page starts with an off-screen “Skip to content” link that becomes visible the moment it has focus, and it jumps to the page's main region. Safari does not move Tab focus onto links by default; its users can turn on Full Keyboard Access to reach the link the same way.
• Tab order follows the page. Header and navigation, then the tool itself, then the footer — the same order in the markup and on the screen, with no positive tabindex anywhere to reorder it.
• Focus is always visible, and nothing covers it. Links, buttons, expandable questions and dropdowns get a 2-pixel outline in the color of the theme you picked, offset from the shape so it stays legible. Text inputs keep their own border-and-ring treatment instead. The header scrolls away with the page rather than sticking to the top of the window, so no focused control can slide underneath it.
• Theme chips answer the arrow keys. The six color buttons are a group: left and right arrows walk between them, and each one reports whether it is the selected theme.
• Dragging is never the only way to hand over a file. Every drop zone says “Drag & drop … or choose files”, and that button opens the browser's own file dialog — the same dialog a keyboard visitor can reach without touching a mouse. Files selected that way behave identically to files dragged in, and each one gets a remove button that names the file it removes.

With a screen reader

• Real landmarks, not styled boxes. Each page is a header, a main and a footer; navigation is a nav labeled “Main”, and tool pages carry a labeled breadcrumb trail.
• One first-level heading per page, and headings step down in order. Sections sit under the heading that names them, so a list of headings read aloud is also a map of the page.
• Results announce themselves. The calculators render their answer into the page instead of opening a dialog, and the progress line that reports what a file job is doing is a live status region, so a long job does not go silent.
• Tables are real tables. Result schedules use th scope="col" headers, each table sits under its own heading, and the full detail view is a second table rather than a picture of one.
• Buttons that show only a symbol carry a name. The ✕ that removes a row, the ✕ that removes a file and each theme chip all have text a screen reader reads — including which row or file is being removed.
• Pictures are either named or ignored. Generated output that is an image — a QR code, a barcode, an SVG that wraps a photo — is written with a title and a label.

Seeing and reading the page

• Contrast is measured, not eyeballed. The build refuses a palette that drops below AA for the combinations the site really renders — the tightest of them is 4.60:1 in light mode and 4.97:1 in dark mode, with a separate 3:1 check for interface shapes, and both modes of all six themes are checked.
• Zoom and small screens. Text scales without a zoom lock, and the layout reflows to a single column on narrow screens; wide result tables scroll inside their own box rather than pushing the page sideways.
• Dark mode is a first-class mode. The choice is written into the page before the first paint, so it neither flashes nor depends on scripting, and a themed page still renders with JavaScript switched off.
• Motion is optional. If your system asks for reduced motion, the smooth scrolling and the color transitions stop; nothing on the site needs them to work.

What we know does not work well

• The files we produce are not tagged. A PDF downloaded from here carries a document title but no tagging structure, so assistive technology reads its content linearly rather than as headings, lists and table headers. If you need an accessible PDF, the source document is the place to fix that, with software that writes tags.
• Heavy jobs depend on the device. Merging large PDFs, re-encoding images and recognizing text in a scan all run in your browser, which is the point — nothing is uploaded — but it also means an older phone with little free memory will be slower, and may refuse the largest jobs.
• Optical character recognition has to fetch its engine first. The first pass of the image-to-text tools loads roughly 4 MB of engine and language data from this site (never from a third party), so it is slower on a slow connection and is not usable offline.
• Advertising is not ours to make accessible, and none is running. No ad space is reserved while the review is open — before the placeholder slots came down they were empty boxes that kept their height, so they shifted nothing and were not announced. When ads do run, an ad's contrast, motion and labeling would belong to the advertiser and to Google rather than to us, and each slot would be labeled “Advertisements” for screen readers.
• Pages we link to are not ours — including the sources quoted under “Assumptions and sources” on each tool page.

Telling us about a problem

If something here is unusable for you — a target too small, a control you cannot reach, a file that comes out in the wrong shape — write to contact@danfio.com with the page address, what you were using (keyboard, screen reader, magnifier, which browser) and what happened instead. We answer within 30 days; we do not ask you to prove a disability to be heard; and a blocker found this way is fixed before new feature work.

How this statement is kept honest

The claims above are not annual-review boilerplate. Contrast is enforced by a test that fails the build, and the keyboard side — the skip link, focus visibility, focus never being covered, the button that replaces dragging, and the 24-pixel target size — is walked in a real browser by this project's end-to-end suite, so a change that breaks one of them turns a gate red instead of waiting to be noticed. The walkthrough that produced this statement, including what it found and what was changed because of it, is recorded in the project's verification log alongside the other measured readings.

Related pages: privacy policy, disclaimer, methodology, contact.