accessibility

Tocko is a time clock for schools. Custodians, bus drivers, kitchen staff, aides, and office staff all have to use it to get paid, which means it has to work for all of them. Accessibility here isn’t a feature, it’s the difference between someone being able to clock in and not.

We build to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. The legal floor under ADA Title II is WCAG 2.1 Level AA. We build to 2.2, the newer standard, so districts clear the rule with margin and stay current as the guidelines evolve. Where it’s relevant for our education customers, we also reference Section 508 in the United States.

Tocko partially conforms to WCAG 2.2 Level AA. “Partially conforms” is the standard’s own wording for “most of it meets the bar, and we will tell you which parts we have not finished proving.” It covers the marketing pages, the kiosk, the employee screens, and the admin and super admin screens.

We used to say “fully conforms, no known exceptions.” That was more than we could back up, so we stopped saying it. What changed is not the product getting worse: we built the automated testing this page had been describing, pointed it at every screen, and fixed what it found along with a round of manual review. The claim is smaller now, and there is something behind it.

If you find something that does not meet the standard, that is a bug and we want to hear about it.

• Every interactive element is reachable and operable by keyboard, with a visible focus indicator.
• Kiosk PIN entry uses large targets, and the entered-digit count is announced to screen readers as you type.
• Pinch-zoom stays enabled on the kiosk. Locking it down would keep a wall-mounted tablet tidier, but it would also lock out anyone who needs to magnify the screen.
• Text and controls meet AA contrast against their backgrounds.
• Errors are announced, not just shown in red.
• Decorative animation respects prefers-reduced-motion. That includes the punch celebrations and the drifting background on the kiosk, which stop entirely rather than merely slowing down.
• Layouts reflow down to 320px and tolerate 200% zoom.
• The kiosk signs people out when it is left idle, because it is a shared tablet. It warns first, and gives you at least 20 seconds to stay signed in, or to sign out on the spot if you are done.
• Dialogs keep keyboard focus inside them while they are open, and hand it back to whatever opened them on close.
• Sign-in fields are marked up so a password manager can fill them.
• The kiosk does not make you remember a PIN. Districts can turn on a badge you scan, or a staff card you tap on a reader, and either works instead of typing a number. The PIN keeps working for anybody who prefers it.

Our automated suite reports no WCAG 2.2 Level A or AA violations on any screen it covers. That is a real result, and it is a narrower claim than it may sound:

• Automated testing covers roughly a third of the standard. Criteria that need a person to judge them, such as whether a link makes sense read on its own or whether an error message actually helps, depend on our manual review, and manual review can miss things.
• We have not finished a full screen reader pass with NVDA, JAWS and VoiceOver across every screen. Until we have, treat the screen reader experience as tested but not certified.
• Of the two badge options, the card reader is the more accessible. Scanning a code removes the need to remember a PIN, which is the barrier the standard is concerned with, but it asks you to aim a camera instead, which is a task of its own if you have low vision or limited dexterity. Tapping a card asks for neither. Districts choosing between them should know that.
• Signing up is partly handled by Stripe, whose checkout pages are theirs rather than ours. Everything up to and after that step is covered here.
• The kiosk is designed to be mounted and shared. If your district mounts a tablet at a height or angle that isn’t reachable from a wheelchair, no amount of software accessibility fixes that. It’s worth checking the physical install too.

This is a self-assessment. We have not commissioned a third-party audit. What we do:

• Automated testing with axe-core, the open-source engine most accessibility checkers are built on, against the WCAG 2.0, 2.1, and 2.2 A and AA rule sets. It runs on every change, in continuous integration, and a violation fails the build rather than filing a note for later.
• Coverage is every surface, not only the public one: the marketing pages, the kiosk keypad including the state it shows after a wrong PIN, the employee punch and history screens, the idle sign-out warning, the badge scanner with the camera running, the badge page on a phone, all of the admin and super admin screens, and dialogs scanned while they are open.
• Accessibility linting on every build, so the common markup mistakes are caught before they ever reach a browser.
• Manual keyboard and screen reader checks during development.
• Contrast review of the palette used across the product.

Automated tools verify roughly a third of the WCAG success criteria. Passing them is necessary, not sufficient, which is why the manual checks and your feedback matter.

If something in Tocko is hard to use, or you can’t get to information you need, tell us. Include the page, what you were trying to do, and the browser and assistive technology you were using. That helps us reproduce it faster.

Email [email protected] with the subject line “Accessibility feedback.” We aim to acknowledge within 5 business days.