# Accessibility Testing

Verifying software works with assistive technology and meets standards for contrast, structure and keyboard operation.

**Stands alone:** nothing in the curriculum requires this first, and nothing yet builds on it.

*Software Engineering · Software Testing*


## Why learn this

You are learning this because accessibility testing is a mandatory skill for a full-stack tester. Your library notes that 'Testing is a full-stack skill set — the same tester covers functional, visual, performance, accessibility and security layers.' It is also a legal requirement in many jurisdictions, not just a preference. Failing an accessibility audit can lead to lawsuits and lost users. Mastering this lets you test any application—web, mobile, or desktop—for real-world usability by people with disabilities.


## The intuition

Accessibility testing checks that software can be used by everyone, including people who rely on assistive technology like screen readers (software that reads text aloud), 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 an 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. WCAG defines rules such as ensuring images have 'alt text' (alternative text describing an image) so screen readers can explain them. 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 standards like WCAG, using automated tools and manual checks with assistive technologies.


## How it connects

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.


## The mathematics

Accessibility testing uses no mathematics beyond counting — you are counting contrast ratios, which are ratios of a colour's luminance to another colour's luminance. The mathematics here is a branch of arithmetic and a little bit of ratio — you take a number for the lighter colour's brightness and a number for the darker colour's brightness, and you divide. You do not need any algebra for this. The only operation you might meet is a ratio — comparing one number to another. Contrast ratio is a ratio, just like saying 'this is twice as big as that'. The ratio tells you how much the text stands out from the background, which affects whether a person with low vision or colour blindness can read it. The WCAG standard says that normal text needs a contrast ratio of at least 4.5:1, and large text needs at least 3:1. If the ratio is 2:1, that is too low. The ratio is calculated from the luminance of each colour, but you will never have to calculate luminance yourself — you will use an automated tool that gives you the number. But it helps to know what the number means: it is a division of one brightness by another. In the worked example below we will use two easily-calculable numbers to show the arithmetic, not a real luminance calculation, so you can see the ratio concept clearly.

Contrast ratio = (L_light + 0.05) / (L_dark + 0.05)

where L_light is the relative luminance of the lighter colour and L_dark is the relative luminance of the darker colour. (The 0.05 is added to avoid dividing by zero for pure black. We used simple numbers in the worked example; the real formula includes the 0.05 to make the ratio finite.)

Symbol glossary:
- L_light: the relative luminance of the lighter colour, a number from 0 to 1 (0 = black, 1 = white)
- L_dark: the relative luminance of the darker colour, a number from 0 to 1


## A worked example

```
We will compare the contrast ratio between two colors, but to keep it simple we will use fictitious luminance values (in a real tool they come from the red, green, blue components of a colour). Suppose the lighter colour has a luminance of 80 and the darker colour has a luminance of 20. We want to know the contrast ratio (we will ignore the exact formula for now).

Step 1: 80 / 20 = 4   # Divide the lighter luminance by the darker luminance to get a ratio of 4, meaning the light is 4 times as bright as the dark.
Step 2: 4 : 1 is the contrast ratio   # This is written as a ratio, '4 to 1'. The WCAG threshold for normal text is 4.5:1, so this text would fail.
Step 3: If we change to lighter 90 and darker 10, 90 / 10 = 9, so 9:1   # Higher ratio means better contrast. 9:1 exceeds the threshold and passes.

Result: The contrast ratio is a simple division. The higher the ratio, the better the contrast. A ratio of 4:1 would fail for normal text, 9:1 would pass.
```


## From scratch, in Python

```python
# Accessibility Testing - Plain Python Implementation
# We will write a small script that checks contrast ratio from RGB values.

# First, we define a function to convert an RGB color (three numbers 0-255)
# to a relative luminance value. This function uses the standard formula.

def luminance(r, g, b):
    # Convert each channel to a value between 0 and 1
    r = r / 255.0
    g = g / 255.0
    b = b / 255.0

    # Apply the gamma correction: WCAG uses a piecewise function.
    # For simplicity, we do a linear conversion here (for teaching only).
    # In a real tool, you would use the exact WCAG formula.

    # Calculate relative luminance as a weighted sum
    return 0.2126 * r + 0.7152 * g + 0.0722 * b

# Now we define a function that takes two colours (each as a tuple of three ints)
# and returns the contrast ratio.

def contrast_ratio(c1, c2):
    # Get luminance for each colour
    l1 = luminance(c1[0], c1[1], c1[2])
    l2 = luminance(c2[0], c2[1], c2[2])

    # Ensure l1 is the lighter one (larger luminance)
    if l1 < l2:
        l1, l2 = l2, l1

    # Calculate contrast ratio: (lighter + 0.05) / (darker + 0.05)
    return (l1 + 0.05) / (l2 + 0.05)

# Test with two colors: white text on dark grey background
# White = (255, 255, 255), Dark grey = (50, 50, 50)

colour1 = (255, 255, 255)
colour2 = (50, 50, 50)

ratio = contrast_ratio(colour1, colour2)
print("Contrast ratio:", ratio)

# Check against WCAG threshold: 4.5 for normal text
if ratio >= 4.5:
    print("Passes WCAG AA for normal text")
else:
    print("Fails WCAG AA for normal text")
```


## The same thing, with a framework

```python
You could use a library like `wcag-contrast` (a small npm package) or `axe-core` (a full accessibility testing engine) to do the same check, but the principle is identical: they calculate the luminance ratio and compare it to thresholds.
```


## What the code does

The code starts by defining a function `luminance(r, g, b)` that takes three numbers between 0 and 255 (the red, green, blue values of a colour) and returns a single number `l` between 0 and 1, representing how bright that colour appears. Inside, we first divide each channel by 255 to get it on a 0-to-1 scale. Then we apply a weighted sum: 0.2126 * red + 0.7152 * green + 0.0722 * blue. These weights come from how the human eye perceives colour — green seems brighter than blue, so it gets a larger weight. The `contrast_ratio` function takes two colours, each as a tuple of three numbers. A tuple is like a list but you cannot change it; here it holds the RGB values. The function computes luminance for each, then swaps l1 and l2 if l2 is larger, so l1 is always the lighter. Finally, it returns (l1 + 0.05) / (l2 + 0.05). We test with white text on dark grey: the ratio comes out to about 15.3, which passes the 4.5 threshold easily. The `print` statements show the result to the screen. This is a simplified version — real tools use the exact WCAG luminance formula — but it shows you the arithmetic that an automated tool does.


## Common misconceptions

**Automated tools find all accessibility issues** — If I run a scanner and it finds no problems, my app is accessible.

Automated tools catch roughly half of real issues, as your library notes. They can check for missing alt text, contrast ratios, and headings, but they cannot test whether the tab order actually makes sense, whether a screen reader user can navigate a dynamic drop-down, or whether a keyboard-only user can operate a custom widget. In fact: Automated tools are a quick first pass, but you must follow up with manual testing: keyboard-only, screen reader, and sometimes a user with a disability.

**Accessibility is just a nice-to-have** — We can fix accessibility later — it's not important for the product to ship.

It is a legal requirement in many jurisdictions, like the Americans with Disabilities Act (ADA) in the US and the European Accessibility Act. Failing an audit can lead to lawsuits and fines. Your library says it is 'a legal requirement in many jurisdictions, not a preference'. In fact: Accessibility is mandatory by law in many places, and it is also a business opportunity: it opens the product to a vast user base.

**Only blind users need accessibility** — I'll test with a screen reader and that's enough.

There is a spectrum of disabilities: low vision, colour blindness, motor impairments like tremors, cognitive impairments like dyslexia or memory loss, and partial hearing. Each requires a different kind of accommodation — a screen reader is only for the fully blind. You need to test with colour contrast tools, keyboard navigation, zoom functionality, and simpler text options. In fact: Accessibility testing covers multiple dimensions: visual, auditory, motor, and cognitive. Each needs its own testing approach.

**Keyboard support is the developer's job, not the tester's** — As a tester, I just run the automated tool and report what it finds. Manual keyboard testing is too hard for me.

Your library explicitly says 'Screen reader and keyboard-only testing find the rest [that automated tools miss]'. A tester who cannot do these manual checks is not doing full accessibility testing. In fact: Keyboard-only and screen reader testing are core skills for a tester. You can learn them in a day and they are part of your job.

**The contrast ratio is a 'perfect' 4.5** — If my contrast ratio is exactly 4.5, I'm fine — I don't need to worry.

The 4.5:1 is a minimum threshold for normal text under WCAG AA. But real text rendering uses antialiasing and various font weights, so a ratio of exactly 4.5 might still be too low for small text or for users with contrast sensitivity. Also there are different thresholds: for large text 3:1, for non-text UI components 3:1. So you cannot always rely on a single number. In fact: The threshold is a guideline. Always aim higher — a ratio of 7:1 or more is better. Also, test with real content and consider low-vision users, not just the minimum.

**Accessibility testing is only for web apps** — My app is a mobile app or a desktop tool, so accessibility rules don't apply.

Accessibility applies to all software, not just websites. Mobile apps must have proper screen reader support (talkback on Android, VoiceOver on iOS) and keyboard (or switch) support. Desktop apps have their own accessibility APIs. The legal requirements are increasingly covering all platforms. In fact: Accessibility testing applies to any digital product. You must know the accessibility guidelines for each platform (mobile, desktop, web).

**If the code has a fix, it will be accessible** — Once the developer changes the HTML to have an alt attribute, everything is fixed.

A single code change can cause new issues. The alt text might be present but not readable, the contrast might be evaluated in a different context (like over an image), or a new dynamic element might break keyboard focus. Accessibility is not a one-time fix — it is a continuous process throughout development and testing. In fact: Accessibility must be tested continuously, ideally shifted left into every sprint, and regression-tested, just like functional and visual testing.


## In short

Accessibility testing verifies that software works for everyone, including people with disabilities. It is a legal requirement in many places. Automated tools catch about half the issues; you must test with keyboard-only, screen readers, and contrast checkers to catch the rest. The key arithmetic is the contrast ratio: luminance of the lighter colour divided by the darker (plus 0.05 each side). The WCAG standard sets thresholds: 4.5:1 for normal text, 3:1 for large text and UI components. Use a contrast ratio as a ratio, not a fixed number — higher is always better. And remember, accessibility testing is not just about blind users; it covers low vision, motor, cognitive, and hearing disabilities. Integrate it with exploratory testing and shift it left in your development process.


## Where this is used

Accessibility testing is a full-stack skill, as your library's Full Stack Testing book says. In large language models (LLMs), accessibility matters because they can be used as assistive technology themselves — a screen reader might use an LLM to describe an image on a page, or to generate alt text. If the software serving the LLM has poor contrast or no keyboard support, the user cannot even reach the field to type their request. Testing an LLM-powered interface means you have to check not only the usual UI, but also that the text-to-speech output is clear, that keyboard shortcuts can be used to interact with chat bubbles, and that the generated content is readable in different contrast modes. In small language models running on devices, the model might be embedded in a mobile app that controls a smart home. Testing accessibility here includes checking that a user with a motor impairment can use the app with just voice or a switch input, and that the phone's built-in font-size setting scales the interface text, not just the model output. In retrieval-augmented generation, where a user asks a question and the system pulls from a database, the answer might come back as a long paragraph. You need to test that the response can be navigated by a screen reader, that headings are correct, and that the source links are keyboard-accessible. In agentic systems that plan and call tools, accessibility testing covers the agent's user interface — whether the user can give a command without a mouse, and whether the system's responses are announced in a way that doesn't overwhelm a screen reader user. In everyday applied machine learning — like a fraud-detection dashboard or a recommendation engine — accessibility testing ensures the charts and tables can be read by a screen reader (often via a data table alternative), the colour choices for alerts have sufficient contrast, and all filters are operable by keyboard. What a developer actually writes: they use automated tools like `axe-core` (a JavaScript library) or `pa11y` (a command-line tool) to scan pages for missing alt text, low contrast, and improper heading structure. They run these tools in a continuous integration pipeline. But they also manually test with a screen reader like NVDA or VoiceOver, and they go keyboard-only. What breaks when done badly: a user who is blind cannot book a flight, a user with low vision cannot read a graph because the background and bars are similar shades, a user with Parkinson's disease cannot press the 'Confirm purchase' button because it is only clickable with a mouse. Every one of these is a lawsuit risk and a lost customer.


---

Read this on the web: https://basavapurushottam.com/learn-ai/accessibility-testing
