Route changes
After navigation without a page load, the new view needs a meaningful title and the focus needs a sensible new place.
Services · Web apps
Web apps that work without a mouse
A web app changes constantly while people use it: panels open, lists update, routes switch without a page load. That is where accessibility breaks. Our reviewer tests your app the way keyboard and screen reader users work with it.
Why web apps need more human testing
Our scanner sees what is reachable without logging in, and it never clicks or submits anything. That is deliberate: we do not change data on your system. For a web app this means the scan covers the public entry points, and the real product is tested by a person.
Before we start, we agree the scope: which journeys, which roles and which app version. You give us a test account in a test or staging environment. That exact scope and version appear on the certificate.
Single-page apps fail in typical ways: focus that stays on a button that has just disappeared, a new view that no screen reader announces, a custom dropdown that looks fine and says nothing. These are the things we look for first.
What we look at in web apps
Dialogs and panels
Focus moves into the dialog, stays there while it is open, and returns to the trigger when it closes. Escape closes it.
Dynamic content
Search results, notifications, autosave and inline validation are announced as status messages without moving focus.
Custom widgets
Tabs, menus, comboboxes, sliders and data grids follow the expected keyboard patterns and expose the right roles and states.
Tables and charts
Data grids keep their headers for screen readers. Charts have the same information available as text.
Tooltips and popovers
Content that appears on hover or focus can be dismissed, stays while the pointer moves over it, and does not cover what you are working on.
Criteria that matter most in web apps
- 2.4.3Focus Order
Focus order must follow the meaning of the interface, also after content is added, removed or moved.
- 2.1.2No Keyboard Trap
Rich text editors, embedded maps and modal dialogs must never trap the keyboard.
- 4.1.2Name, Role, Value
Name, role and state of every control must be available to assistive technology, for example “Filters, collapsed, button”.
- 4.1.3Status Messages
Status messages such as “Changes saved” must be announced without the user losing their place.
- 1.4.13Content on Hover or Focus
Tooltips and hover cards must be dismissible, hoverable and persistent.
- 3.3.7Redundant Entry
In multi-step flows, information already entered must not be asked for again unless it is essential.
How we test a web app
Scope and version
Journeys, user roles and the app version to be tested, agreed in writing.
Access
A test account with dummy data in a test or staging environment. We never need production data.
Review
The reviewer works through each journey with keyboard and screen reader (NVDA or VoiceOver) and decides all 55 criteria.
Findings per component
Each finding names the component, the criterion, the location and a fix hint, so your team can fix it once in the component library.
Frequently asked questions
What do you need from us?
A test environment, a test account for each role in scope, a short description of the key journeys and the version number. If parts of the app are behind a VPN or IP allowlist, tell us early: our scanner cannot reach them, and we agree with you before the audit whether and how the reviewer can get access.
Does the framework matter?
No. We test the result in the browser, whether it is built with React, Vue, Angular, Svelte or plain JavaScript. The fix hints describe what the HTML and behaviour must be.
Does monitoring cover the logged-in app?
No. Monitoring uses the same scanner, which never logs in. It watches your public pages. For the logged-in product, plan a new audit when the interface changes significantly.
Related
SaaS & software
Products, tenders, apps
Developers
Findings with code fixes
Keyboard test
See and practise focus
Method
All 55 criteria, openly described