qrcodeq

Legal

Accessibility Statement

qrcodeq should be usable by people who rely on keyboards, screen readers, zoom, high contrast and predictable layouts. The site is designed with labeled form fields, visible focus states, stable preview areas and readable color contrast.

QR and barcode tools can become difficult quickly because they mix form controls, previews, file exports, camera permissions and status messages. We try to keep those pieces explicit: controls have visible labels, export feedback is announced as status text and important scan warnings are written in plain language rather than hidden behind icons.

Current goals

  • Keep the main generator controls reachable by keyboard.
  • Use visible labels instead of placeholder text alone.
  • Avoid text overlap on small screens.
  • Warn when QR colors may be too low contrast to scan reliably.
  • Keep download, copy, scan and camera actions understandable without relying on color alone.
  • Maintain breadcrumbs, headings and skip navigation so pages are easier to move through.

How we test common flows

We check the main pages with keyboard navigation, mobile widths and desktop layouts. The goal is simple. A person should be able to enter data, read the warning text, test the scan and download a file without losing their place.

We also watch for layout shifts. QR previews, barcode previews, buttons and status messages should not push controls around in a confusing way. Text should wrap inside its area, not cover the next control.

Forms and status messages

Generator pages rely on forms, so labels matter. A field should explain what belongs there before a person starts typing. Help text should add useful context, not repeat the label in softer words.

Status messages should be written in plain language. If a QR scan test fails, the page should say what to try next. Better contrast, a larger quiet zone or a removed logo are more helpful than a vague error.

Color and scan contrast

Accessibility and scan reliability often point in the same direction. Dark code colors on a plain light background help people see the preview and help phones read the file. Low contrast brand colors may look nice but fail in dim rooms or on glossy material.

We try to flag risky contrast choices in the tool. That warning is not a full accessibility audit of the final design. A code placed over a photo, texture or tinted poster still needs a real check.

Known limits

Some browser features, especially camera access, image clipboard copying and file sharing, depend on the device and browser permission model. When a feature is blocked, the interface should offer a fallback such as downloading the PNG, copying text or uploading an image instead of using the camera.

Browser support also affects screen readers and mobile controls. The same camera picker can behave differently on iOS, Android, Chrome, Edge and Safari. We try to keep fallback paths available when those differences appear.

Feedback

If a control is hard to use, a label is unclear or a page does not work with assistive technology, contact [email protected] with the page URL, browser, device and a short description of the issue.

Helpful reports include the assistive technology used, the step where the issue happened and what you expected to hear or see. A short screen recording can help, but it is not required.