5 terms Reviewed
Terms you meet when an app has to work for people who use screen readers, keyboards or simplified text: the standard, how to test against it, and what that means for the build.
Every entry is reviewed by a practitioner who builds these systems: Daria Gusieva, Łukasz Gajownik.
Accessibility audit (WCAG audit)
An accessibility audit is a structured check of a website or app against a standard, usually WCAG 2.1 or 2.2 at level AA. It combines automated scans with manual testing by keyboard and screen reader, and ends with a report that lists each failed success criterion, where it fails and how to fix it.
Easy-to-read
Easy-to-read (ETR) is a way of writing information so that people with intellectual disabilities can understand it, with everyday words, short sentences and one idea per line, checked by readers from that group. Inclusion Europe publishes the European standard.
Focus management (keyboard and screen reader focus)
Focus management is how an app decides which element receives keyboard or screen reader focus when the screen changes: after navigation, when a dialog opens or closes, or when an error appears. Done right, the user always knows where they are and cannot reach controls that are hidden.
Screen reader testing (VoiceOver, TalkBack, NVDA)
Screen reader testing checks an app or website with VoiceOver, TalkBack, NVDA or another reader that blind and low-vision people use to hear the interface. A tester goes through every screen and checks what is announced, in what order, and whether every task can be finished.
Web Content Accessibility Guidelines 2.2
WCAG 2.2 is the W3C standard for accessible web content. It sets 86 testable success criteria at three levels, A, AA and AAA. Content that meets WCAG 2.2 also meets 2.1, the version that EU and Polish rules for websites and apps point to at level AA.
No terms match your search.
Missing a term your project depends on? Tell us - we add entries that buyers ask about. Suggest a term
Free for buyers
Pick the terms
Tap the plus on every term your project touches: protocols, regulations, market rules.
Get it by e-mail
For each term: the definition and what it requires from your software, written by our engineers.
Use it in your RFP
Paste the requirements into a request for proposal or use them to check what a vendor left out.
Commissioning software and the terms are piling up?
Talk to an engineer, not a salesperson. 30 minutes, we review your requirements and say what we would build first.
