In words
What it is, why it matters, and what it is like.
Why am I learning this?
You are learning this because accessibility testing is a mandatory skill for a full-stack tester, as your library notes: 'Testing is a full-stack skill set — the same tester covers functional, visual, performance, accessibility and security layers.' It is a legal requirement in many jurisdictions, not a preference — failing an accessibility audit can mean lawsuits and lost users. This concept unlocks further study in software testing, connecting directly to your notes on Exploratory Testing Frameworks (you will use exploratory charters to find a11y issues), Visual Regression Testing (you will pair screenshots with a11y checks), and Shift-Left Testing (you will catch a11y defects early, when they are cheap to fix). Master this and you can test any application — web, mobile, desktop — for real-world usability by people with disabilities.
The idea, in plain terms
Accessibility testing is the practice of checking that a piece of software can be used by everyone, including people who rely on assistive technology like screen readers, voice commands, or keyboard navigation. Imagine walking into a building with steps but no ramp — a person in a wheelchair cannot enter. The building is not 'badly designed' in a aesthetic sense, but it is functionally unusable for that person. Software is the same: a button that requires a mouse and good eyesight leaves out people who cannot use a mouse or see the screen. Accessibility testing is a systematic check that the ramp exists — that every feature can be reached and operated by anyone, regardless of ability. It is not about being nice; it is about being functionally complete. It is a separate layer of testing, like security or performance, because you have to check specific things that functional tests often miss, like whether a screen reader can announce a field, whether the contrast between text and background is strong enough, and whether every action can be done from the keyboard alone.
An analogy
Think of accessibility testing like a building inspector checking a new office block, not for structural integrity but for universal access. The inspector walks the building, not just the main lobby, and tries every door, every corridor, every light switch. They check a set of known requirements: are doorways wide enough for a wheelchair? Are there tactile indicators for people who are blind? Do fire alarms have both sound and flashing lights? They also try things they have not planned: they walk with their eyes closed, or they try to get from the entrance to the third-floor meeting room using only one hand. The inspector does not just trust the blueprints; they test the real building. Accessibility testing is the same for software. The standards, like the Web Content Accessibility Guidelines (WCAG), are your checklist — they tell you the doorway width and the alarm requirements. But you also test in exploratory ways: you turn off your monitor and use only the keyboard, you run a screen reader and try to navigate a form, you look at a page in shades of grey. The building inspector analogy stops working when you consider that buildings are physical and have the same structure for everyone, but software has different 'entrances' — the same app can be used on desktop, mobile, and by different assistive technologies, and each combination can behave differently. The building inspector's checklist is static, but your accessibility testing has to adapt to the technology and the user.
Definition
Accessibility testing is the process of verifying that a software application can be perceived, understood, navigated, and operated by all users, including those with disabilities, and that it conforms to accessibility standards such as WCAG, by using automated tools, manual testing with assistive technology, and keyboard-only and screen reader checks.
Where this sits
Your library notes that accessibility testing belongs to Software Testing and sits alongside your notes on Exploratory Testing Frameworks — accessibility testing is a form of exploratory testing, where you have a charter (e.g., 'complete a purchase using only the keyboard') and you follow the surprises. It also connects to Visual Regression Testing because you can combine accessibility tools with screenshot comparisons to catch issues like missing alt text that would show as a broken image. And it connects to Shift-Left Testing: the earlier you run an accessibility scanner in development, the cheaper the fix — a contrast fix after launch costs much more than a design adjustment before coding. You have not yet met API testing, which is separate — accessibility is about the user interface, not the service interface.
