Why this is part of the product, not an afterthought
Nonkera's whole premise is that a useful tool shouldn't have gates in front of it — no account, no install, no payment. Accessibility is the same promise applied to how the site actually works: a tool that can't be operated with a keyboard, or that a screen reader can't make sense of, has quietly put a gate back up for a specific group of people. So rather than treating accessibility as a checklist bolted on at the end, it's reviewed the same way performance or mobile layout is — as a basic requirement for every page and every tool, not a separate initiative.
The approach: an audit against WCAG, not just a plugin
Nonkera's accessibility work is grounded in the Web Content Accessibility Guidelines (WCAG) 2.1, using Google's own web.dev accessibility guidance as a practical reference for what to check and how to check it — things like accessible names for every control, visible focus indicators, color contrast ratios, and correct heading structure. Every shared component (buttons, form fields, the file upload area, tool cards) and every individual tool page was reviewed against that guidance and fixed directly in the code, rather than run through an automated scanner and left at 'no errors found.' Automated tools catch missing alt text and a handful of other issues, but they miss things like a form field that only has a label on the first row of a repeated list — a real bug this process found and fixed in the GPA calculator.
What this looks like in practice
A few concrete things are true across every page on Nonkera as a result: every page has a skip link so keyboard and screen reader users can jump straight past the repeated header navigation instead of tabbing through it every time. Every interactive element — links, buttons, form fields, the drag-and-drop upload areas — is reachable and operable with a keyboard alone, with a visible focus outline that shows up for keyboard navigation without flashing on every mouse click. Every input has a real accessible name, not just a placeholder or a visual label that a screen reader can't see. Selected states (like an active category filter) are marked in a way screen readers can detect, not just shown with a color change. Text and interactive-control borders meet WCAG's minimum contrast ratios in both light and dark mode. Smooth scrolling and other motion effects are turned off automatically for anyone who's told their operating system they prefer reduced motion.
How this shows up in the tools specifically
These aren't abstract principles — they're wired into the tools people actually use. The PDF Merger's drag-and-drop upload area is a real keyboard-operable control, not just a mouse target: press Tab to reach it and Enter or Space to open the file picker, exactly like clicking it. Tools that show a result only after a button click — like the JSON Validator's valid/invalid check — announce that result to screen readers automatically, so there's no need to go hunting for what changed after pressing the button. And in list-style tools like the GPA Calculator, where a column header like "Grade" is only shown visibly once at the top for sighted users, every row underneath still has its own full accessible name ("Grade for course 2," "Grade for course 3"), so a screen reader user never lands on an unlabeled dropdown.
What 'accessible' doesn't mean here
This is worth being direct about: Nonkera follows WCAG 2.1 AA guidance as closely as the team can manage, but it hasn't gone through a formal third-party accessibility audit or certification, and no site of meaningful size gets every single case right on the first pass. If a specific tool or page doesn't work the way it should with your keyboard, screen reader, or browser zoom setting, that's useful information, not an inconvenience — the Contact page is the fastest way to report it, and issues get fixed directly rather than filed away.