Accessibility

The target

OpenQRS is built to meet WCAG 2.2 at level AA. That is the standard the site is measured against, not a certification it holds: no external audit has been carried out, and this page says what has been done and what has not rather than asserting conformance.

What has been built

• Keyboard operation throughout. Every control is a real button, link, input or select, reachable and operable with the keyboard in the order it appears. A skip link is the first thing focus reaches on every page and jumps straight to the main content.
• Visible focus. Focus is drawn with a two-pixel outline offset by two pixels from the control, in a colour chosen for both themes. It is shown for keyboard and assistive navigation and suppressed for pointer clicks, so it appears when it is useful and never as a stray ring after a mouse click.
• Targets of at least 44 by 44 pixels. Buttons, inputs and the theme toggle all reserve that height, which is well above the 24-pixel minimum of success criterion 2.5.8 and large enough for an unsteady hand on a phone.
• Contrast checked against the token values. The colour tokens are measured against their backgrounds rather than eyeballed; the success colour was darkened during the build of the palette because it measured 4.02:1 against the page background and needed 4.5:1.
• Reduced motion respected. Withprefers-reduced-motion: reduce the transition duration collapses to a single millisecond and the smooth-scrolling behaviour of in-page anchors is turned off. No animation carries meaning, so nothing is lost by removing it.
• A status region that speaks for finished actions. The workspace has one polite live region. It announces things that have completed — a file downloaded, the encoded text copied, a logo accepted or refused — and reports a problem with your input only once you have stopped typing. It deliberately does not narrate the preview redrawing, because a code that regenerates on every keystroke would otherwise talk over you.
• A text alternative for the code preview. The preview carries a label that describes the code rather than its appearance: how many bytes it encodes, at which recovery level, its symbol version and module count, and what happens when it is scanned. If the form currently holds input that cannot be encoded, the label says that the code on screen is the last valid one. The exact string being encoded is also shown as selectable text with a copy button, so it can be read out, copied and checked.
• Labels, help text and errors that are linked, not merely nearby. Every field has a real label; help text and error messages are associated with the field so a screen reader reads them with it, and an error names the fix rather than only reporting a failure.
• Colour is never the only signal. A warning or an error carries text and weight as well as colour, so a red border alone never has to be interpreted.
• No web font. Text renders in your system font stack immediately, which removes the reflow that a font swap causes and respects any font settings you have made at the operating-system level.
• A light and a dark theme. The theme follows your system preference by default and can be switched with a labelled button; the choice is remembered and applied before the page paints, so there is no flash of the wrong theme.

Known limitations

These are unresolved, and stating them is more useful than a conformance claim:

• No independent audit. Nothing on this site has been reviewed by an external accessibility auditor. Automated checks and manual keyboard and screen-reader passes catch a large share of failures but not all of them.
• The automated scan is narrower than the site. It covers three routes in one browser and only in the light theme. Every other page is one of those three with different words in it, and the two themes differ only in the values of the colour tokens, so the scan is a reasonable sample rather than full coverage — but a dark-theme-only or guide-only defect would not be caught by it.
• A QR symbol cannot be conveyed non-visually. The text alternative describes what the code does and the payload panel gives the exact string, but there is no way to convey the symbol itself to a person who cannot see it, and no way for that person to judge whether a styled code is likely to scan. That is a limit of the medium, not a bug we can fix.
• Styling can produce an unreadable result. The style controls let you choose colour combinations and shapes that reduce contrast within the symbol. The workspace warns about combinations known to break scanning, but the final artwork is your decision and the warning cannot cover every case.
• Colour input. Colour is chosen through the browser's native colour control alongside a text field for the hexadecimal value, so the value can always be typed. The native control's own accessibility is the browser's, not ours.
• Reflow at very small widths is checked manually. The layout is built in relative units and collapses to a single column on narrow screens, but reflow at 320 pixels and at 400 percent zoom is verified by hand rather than by an automated gate. If you find a page that scrolls sideways, that is a defect worth reporting.
• Destinations are outside our control. Whatever a code points at is somebody else's page, and its accessibility is theirs.

What does not apply

Success criterion 3.3.8, accessible authentication, does not apply anywhere on this site: there is no login, no account and no cognitive function test to pass. Criterion 3.3.7, redundant entry, is trivially met for the same reason — no generator asks twice for something you already typed, and nothing you type carries over between visits at all. The only things kept on your device are the colour theme and a cache of the site's own files.

How this is tested

Two ways, neither of them a substitute for the other. Automated checks with axe-core run in Chromium, in the light theme, against three routes: the home page, one generator page — as it loads, with a symbol drawn, and while it holds a value the tool refuses — and one legal page. Those three carry every kind of markup the site emits, and a serious or critical violation fails the run. Separately, the generator workspace, the only interactive part of the site, is worked through by hand with the keyboard and with a screen reader.

Automated tooling reliably finds only a minority of accessibility failures, which is why the limitations above are listed rather than inferred from a passing test run, and why a report from someone who hit a real barrier is worth more than either method.

Reporting a barrier

If something on this site stops you doing what you came to do, write toinfo@zenitgroup.com.co. A report is most useful when it includes:

• the page URL;
• what you were trying to do and what happened instead;
• your browser and version, and any assistive technology you were using, with its version;
• whether you were using the light or the dark theme, and any zoom level you had set.

Accessibility defects are treated as defects rather than as requests. There is no promised response time — see the contact page — but a barrier report goes to the top of the list ahead of new features.