Accessibility and security testing basics
Accessibility for everyone (the WCAG POUR principles and the issues that trip people up), plus the security basics every tester should grasp: the OWASP Top 10 idea, never trusting input, and threats like XSS and SQL injection in plain English.
Two questions sit just beyond "does it work?" and they belong to every tester now, not just specialists. Can everyone use this, including people who can't see the screen or use a mouse? That's accessibility. And can this be misused by someone with bad intentions? That's security. A feature that's correct but locks out disabled users, or leaks data to an attacker, has failed. This lesson gives you an honest working grip on both.
Part one: accessibility, and why it's everyone's job
Accessibility (often shortened to a11y) means building software people can use regardless of how they see, hear, move, or think. That includes someone blind using a screen reader that reads the page aloud, someone with a tremor who can't use a mouse and navigates by keyboard, someone colour-blind who can't tell your red error from your green success, and someone with low vision who zooms the page to 200%.
A large share of people live with some disability, and nearly everyone is temporarily disabled at times: a broken wrist, bright sun on a phone screen, holding a baby with one arm. Accessible design quietly helps all of them. Captions help in a noisy room; good contrast helps in sunlight. Building for the edges improves the middle.
The world's shared rulebook for this is WCAG (the Web Content Accessibility Guidelines). Its four core principles spell a word that's easy to remember: POUR.
| Principle | Plain meaning | A failing example |
|---|---|---|
| Perceivable | People can perceive the content (see or hear it somehow) | An image with no text description, invisible to a screen reader. |
| Operable | People can operate it, by mouse or keyboard or voice | A menu that only opens on hover, unreachable by keyboard. |
| Understandable | It's clear and predictable | An error that just says "Error 7" with no hint what to fix. |
| Robust | It works across browsers and assistive tech | A custom button screen readers don't recognise as a button. |
Most real-world failures cluster into a short list of repeat offenders. If you check only these, you'll catch a large share of problems:
- Missing alt text: images with no text description, so screen-reader users get silence where meaning should be.
- Poor colour contrast: pale grey text on white that low-vision and sunlight-squinting users can't read.
- No keyboard navigation: you can't reach or use something with the Tab and Enter keys alone, only a mouse.
- Unlabelled form fields: an input box a screen reader announces as just "edit text," with no idea what to type.
- Meaning by colour alone: "the items in red are sold out," invisible to someone who can't see red.
Put your mouse away. Try to use the whole page with only the Tab key (to move), Enter/Space (to activate), and your eyes. Can you reach every button? Can you see which thing is focused? Can you complete the main task? If you get stuck, so does every keyboard-only user. It takes two minutes and reveals an enormous amount.
Part two: security basics every tester should know
You don't need to be a hacker to test for security, but you do need the right instinct. The whole mindset comes down to one sentence: never trust input. Anything a user can type, paste, upload, or send can be twisted by someone with bad intentions, and your software has to assume it might be. A tester who keeps asking "what if this input is hostile?" catches a surprising amount.
The industry's shared starting point is the OWASP Top 10: a regularly updated list of the most common, most serious web security risks. You don't have to memorise it; just know it exists as the map of where things usually go wrong, from broken access control to injection flaws. Two of those flaws are worth understanding by name, because they're classic and the idea behind them is simple.
Cross-Site Scripting (XSS)
- An attacker sneaks code into a place meant for plain text, say a comment box.
- If the site shows that comment back without cleaning it, the code runs in other users' browsers.
- It can then steal their session, impersonate them, or deface the page.
- The fix idea: treat user input as text to display, never as code to run.
SQL Injection (SQLi)
- A site builds a database question by gluing user input straight into it.
- An attacker types input crafted to change that question instead of answering it.
- Suddenly they can read, alter, or delete data they were never allowed near.
- The fix idea: keep the question and the user's answer strictly separate, never glued.
Both XSS and SQL injection are the same mistake wearing two costumes: mixing untrusted input with trusted instructions, so the input gets treated as a command. Almost every injection bug is a version of this. Once you see the pattern, you start spotting it everywhere, and that instinct is the most valuable security skill a tester can build.
There's a gentler, easier-to-check layer too: security headers. These are short instructions a server sends along with every page that tell the browser to behave more safely, for example "only load this site over an encrypted connection" or "don't let other sites embed me in a hidden frame." They're not a complete defence, but missing ones are a cheap, visible signal that security hygiene needs attention, and they're easy to check on any URL.
A clear boundary: probing a real site you don't own for security flaws can be illegal. As a tester, you check systems you're authorised to test, and you raise concerns rather than exploiting them. Curiosity is great; permission is mandatory. Reading the public security posture of a site (like which headers it sends) is fine. Actively attacking one is not.
- Accessibility means everyone can use your software, however they see, hear, move, or think, and building for the edges improves the experience for all.
- WCAG's POUR principles (Perceivable, Operable, Understandable, Robust) are four lenses to test any interface through.
- The most common a11y failures are missing alt text, poor contrast, no keyboard navigation, unlabelled fields, and meaning carried by colour alone.
- Security testing starts with one instinct: never trust input. The OWASP Top 10 is the map of where things commonly go wrong.
- XSS and SQL injection are the same mistake (mixing untrusted input with trusted instructions), and security headers are a cheap, visible hygiene signal.
- Always test with authorisation: read a site's public posture, never attack a system you don't own.