Add to Preferred Sources
A website accessibility testing guide gives you a structured process for finding and fixing the barriers that prevent users with disabilities from navigating your site — and, in South Africa's context, for managing the legal exposure that comes with inaccessible digital services. Testing is not a single tool run: it is a three-layer process combining automated scanners, manual keyboard and screen reader checks, and real-user review, each catching different categories of failure that the others miss.
Statistics South Africa's 2022 Census recorded about 3.3 million South Africans aged five and older living with disabilities — roughly 6% of that population under Stats SA's measure — including people with sight, mobility, hearing, and cognitive impairments who interact with websites through assistive technology.
For any business investing in professional web design in Johannesburg or anywhere else in the country, accessibility testing is the step that turns a design that looks inclusive into one that actually functions for every user. The legal and compliance implications for SA websites are also growing as courts in the region begin to test whether inaccessible digital services breach equality legislation.
Quick Answer
A website accessibility testing guide covers three layers: automated scanning (which catches roughly 57% of real-world issues by volume, according to Deque's analysis of 13,000+ pages), manual keyboard and screen reader testing, and assisted user review. The right starting tool for most SA businesses is a free browser-based scanner — WAVE or axe DevTools — followed by a keyboard walk-through. WCAG 2.2 Level AA is the current international standard; South Africa's Government Communication and Information System (GCIS) recommends at least Level A for government websites, and best practice for private businesses follows the same benchmark.
Jump to Section
What Is a Website Accessibility Testing Guide?
Three Layers Every Audit Needs
Automated Scanning Tools Compared
Manual Checks: Keyboard, Screen Reader, and Structure
Not sure where your site stands on accessibility?
Send us your URL and we will run a first-pass audit and flag the highest-priority failures — no obligation, back to you within 24 hours.
Get a free accessibility reviewWhat Is a Website Accessibility Testing Guide?
Web accessibility testing is the practice of evaluating a website against the Web Content Accessibility Guidelines (WCAG) to confirm that people with disabilities can perceive, operate, understand, and navigate it.
WCAG organises every requirement under four principles — Perceivable, Operable, Understandable, and Robust (POUR) — and grades them across three conformance levels: A (minimum), AA (standard), and AAA (enhanced). Level AA is the target for most business websites and is the level referenced in most regulatory and legal contexts internationally.
A complete website accessibility testing guide covers all three testing layers, not just the automated scan that many teams stop at. The W3C's Web Accessibility Initiative is explicit on this point: "No tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required."
WCAG 2.2 — published as a W3C Recommendation in October 2023 and the current standard — added success criteria specifically designed to require human judgement: checking whether a sticky header visually covers a focused element, confirming that a login flow does not depend solely on a dragging gesture, verifying that an authentication step doesn't require solving a cognitive puzzle.
WCAG 2.2: The Four Principles
- Perceivable: Content is available to all senses — adequate colour contrast, text alternatives for images, captions for video.
- Operable: All functionality works with a keyboard alone; no keyboard traps; users have enough time to complete actions.
- Understandable: Language is declared, labels are clear, error messages explain what went wrong and how to fix it.
- Robust: Code is clean enough for assistive technologies (screen readers, switch controls, braille displays) to interpret reliably.
Why Most SA Pages Fail Audits
Inaccessible websites are not the exception — they are the norm. WebAIM's 2026 analysis of one million home pages found that 95.9% had detectable WCAG 2 failures, with an average of 56.1 accessibility errors per page — a 10.1% rise from the 51 errors recorded in 2025, reversing several years of gradual improvement. The six most common failures account for 96% of all errors detected:
| Failure Type | % of Pages Affected |
|---|---|
| Low contrast text | 83.9% |
| Missing image alt text | 53.1% |
| Missing form input labels | 51.0% |
| Empty links | 46.3% |
| Empty buttons | 30.6% |
| Missing document language | 13.5% |
Source: WebAIM Million 2026, top one million home pages
For South Africa, the stakes are higher than the global numbers suggest. Statistics South Africa's 2022 Census recorded about 3.3 million people aged five and older living with disabilities — around 6% of that population — using the internationally recognised Washington Group Short Set methodology. That is a large group of potential customers, service users, and employees who encounter barriers on most commercial websites. A site that fails contrast checks or has unlabelled form fields is not just inconvenient for these users; it is functionally unusable with a screen reader.
Beyond the user impact, most of the top six failures are also directly testable by automated tools, which means they are the easiest failures to catch before launch — and the hardest to justify having shipped.
Three Layers Every Audit Needs
A thorough website accessibility audit uses three testing layers because each one detects failures the others cannot reach — no single approach covers the full WCAG 2.2 success criteria set.
| Layer | When to Run | What It Catches | Primary Tools | Time (typical site) |
|---|---|---|---|---|
| 1 — Automated scanning | Every code push; pre-launch | ~57% of issues by volume: contrast, missing labels, empty buttons, missing alt text, document language | WAVE, axe DevTools, Lighthouse, Pa11y | 30–90 minutes |
| 2 — Manual keyboard + screen reader | Per major design change; before launch | Focus order, keyboard traps, meaningful link text, logical reading order, dynamic components (modals, menus) | NVDA or VoiceOver + keyboard only | Half day |
| 3 — Assisted user testing | Annually; at major redesign | Real-world barriers automation cannot predict: cognitive load, unfamiliar navigation patterns, assistive tech quirks | Recruited testers with disabilities; moderated sessions | Half to full day |
Deque's analysis of more than 13,000 pages and nearly 300,000 issues puts the automated detection rate at 57.38% of real-world issues by volume — and it reframes how to think about scanning. The traditional claim that "automated tools catch only 30–40% of accessibility problems" counts the number of WCAG success criteria that automation can test (roughly 16 of 50 under WCAG 2.1 AA), not the volume of issues those criteria generate.
Deque's volume-based approach shows that the automatable criteria include contrast — which alone accounts for roughly 30% of all errors on typical pages — and that automation detects contrast failures with near-perfect accuracy. Layer 1 is not just a starting point; it handles the largest share of the repair workload.
The practical implication: Start every project with a Layer 1 automated scan to clear the bulk of fixable errors before investing time in manual review. Layer 2 then catches what automation misses — focus traps, illogical tab order, misleading ARIA labels. Layer 3 validates the real experience for users who rely on assistive technology daily.
For teams working on responsive web design projects, Layer 2 is particularly important on mobile: screen reader behaviour on touch devices differs significantly from desktop, and keyboard-equivalent testing (using switch controls or touch navigation) can reveal entire interaction paths that break for motor-impaired users.
Automated Scanning Tools Compared
The table below compares the most widely used accessibility testing tools available to SA developers and site owners. Every major free scanner shares the same underlying rules engine — axe-core — which means their automated detection capability is broadly comparable. The differences lie in workflow integration, output format, and which additional checks they include alongside the axe-core base.
| Tool | Format | Best For | Key Limitation |
|---|---|---|---|
| WAVE | Browser extension | Visual in-page review; learning to spot failures | Manual review of flagged items needed; no CI integration |
| axe DevTools (free) | Browser extension / CLI | Developer workflow; most complete free axe-core rule set | No visual overlay like WAVE; results need interpretation |
| Google Lighthouse | Built into Chrome DevTools | Fast combined audit (performance + accessibility + SEO) | Runs a subset of axe-core rules; a score of 100 does not mean full WCAG compliance |
| Pa11y | Command-line (Node.js) | Automated pipelines; batch scanning multiple URLs | Developer setup required; not suitable for non-technical teams |
| Accessibility Insights | Browser extension (Microsoft) | Guided walk-through combining automated and manual checks | Slower than a pure automated scan; requires time investment |
Struggling to interpret what your audit results actually mean?
We can review your current scan output and prioritise which failures to fix first based on user impact, not alphabetical WCAG numbering.
Book a free audit reviewManual Checks: Keyboard, Screen Reader, and Structure
Manual accessibility testing validates that a site is genuinely usable by someone who navigates without a mouse, depends on a screen reader, or uses switch control input — categories that automated tools cannot evaluate because they require interactive human judgement.
Run these checks in this order for the most efficient Layer 2 workflow:
- Keyboard-only navigation. Disconnect the mouse entirely. Press Tab through every interactive element — links, buttons, form fields, menus, modals, carousels. Confirm that: every focusable element receives a visible focus indicator; focus never becomes trapped inside a component; Escape closes any modal or expanded menu; a skip-to-content link appears at the top when Tab is pressed for the first time.
- Heading structure audit. Use the WAVE browser extension or your screen reader's heading navigation (H key in NVDA/JAWS) to skim the page by headings alone. A logical heading hierarchy — H1 → H2 → H3 — tells users where sections begin and end without requiring them to read every line. Missing or skipped heading levels break this navigation.
- Screen reader read-through. Download NVDA (free, Windows) or use VoiceOver (built into macOS and iOS). With your monitor off or eyes closed, navigate the key pages — homepage, product or service page, contact form. Listen for: images announced as "image" with no description; links announced as "click here" or a bare URL; form fields with no associated label spoken before the input.
- Dynamic component testing. Open and close every modal, accordion, tooltip, and dropdown. Confirm that focus moves into the component when it opens, returns to the trigger element when it closes, and that the component's content is announced correctly by the screen reader.
- Colour contrast manual spot-check. Even after an automated contrast scan, check text over gradient backgrounds and on photographs — areas where automated tools often mis-detect the effective contrast ratio.
Budget for manual testing time before launch, not after complaints. A keyboard walk-through of a typical ten-page SA business website takes two to three hours for a developer with basic screen reader familiarity. Retrofitting accessibility failures after launch — once a component has been built, content loaded, and the design locked — costs significantly more than catching them in the wireframe stage, when changing a label or adjusting a focus order is a five-minute fix rather than a development sprint.
For SA websites optimised for local user behaviour, manual testing also surfaces load-shedding-related issues: pages that rely on JavaScript for core navigation may fail entirely when a user's browser is in power-save mode or on a slow connection, leaving keyboard-dependent users with no fallback.
South Africa's Legal Framework for Digital Inclusion
South Africa has no single dedicated statute that explicitly mandates website accessibility for private businesses — but several national instruments create meaningful legal exposure for sites that actively exclude users with disabilities.
The Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA) prohibits unfair discrimination on grounds including disability, and its principles extend to digital services. The White Paper on the Rights of Persons with Disabilities (2015) sets accessible digital content as part of equal participation, and a Rights of Persons with Disabilities Bill has been in a draft and consultation process since 2026 — there is no enacted Act yet. The Constitution's equality and dignity provisions provide the constitutional foundation. South Africa also adheres to the UN Convention on the Rights of Persons with Disabilities (CRPD), which explicitly addresses equal access to information and communication technologies.
For the public sector, the Government Communication and Information System (GCIS) recommends that government departments conform to at least WCAG 2.2 Level A as a minimum standard, with broader best practices including mobile-first design and POPIA-compliant data handling. Private-sector businesses undertaking WCAG accessibility testing to this standard are aligned with government guidance and better positioned if a discrimination complaint is ever filed.
Practical Position for SA Businesses
No SA court has yet issued a binding order specifically requiring private websites to meet WCAG. That gap is closing: a growing body of case law across South Africa, Kenya, and Nigeria is beginning to translate paper disability rights into enforceable digital standards. Achieving WCAG 2.1 or 2.2 Level AA — the global benchmark — is the most defensible position for a South African business serving the public, and it also removes genuine barriers for users who need assistive technology to buy from you or contact you.
Why South African Businesses Choose Growth Pulse Media
Accessibility testing sits at the intersection of technical execution and strategic design — which is where our work lives. Every website we build at Growth Pulse Media is designed for the full user spectrum: our web design service incorporates WCAG-aligned structure from the first wireframe, not as a retrofit after launch. That means heading hierarchies that work for screen readers, colour palettes checked against contrast ratios, form labels coded to their inputs, and keyboard flows tested before any content goes live.
Growth Pulse Media operates from Johannesburg with a deliberately limited client load. Every project receives direct senior attention — the same person who scopes the work runs it, not a junior handed a checklist. We have built and scaled businesses in South Africa before running campaigns or auditing websites for others, which means we understand what it costs when a site fails users who are ready to buy but cannot complete a form or read a product page.
Accessibility improvements also compound with Core Web Vitals performance and with mobile-first design — semantic HTML, clean code structure, and logical navigation patterns that serve screen reader users are the same patterns that serve Google's crawlers and low-bandwidth mobile users on South Africa's mobile networks.
Who This Is NOT For
Ready to make your site accessible for every South African user?
Tell us what you're building or fixing, and we'll assess whether our web design process is the right fit — no obligation.
Start the conversationFrequently Asked Questions
Is website accessibility testing required by law in South Africa?
No single South African statute explicitly requires private websites to meet WCAG. However, the Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA), the 2015 White Paper on the Rights of Persons with Disabilities (with a draft Bill in process), and the Constitution together create a legal framework under which inaccessible digital services can be challenged as discriminatory. Government websites are guided by GCIS to meet WCAG 2.2 Level A at minimum. For private businesses, achieving WCAG 2.1 or 2.2 Level AA is the most defensible standard and aligns with international best practice.
Can automated tools alone confirm WCAG compliance?
No. Automated scanners — including WAVE, axe, and Lighthouse — detect roughly 57.38% of accessibility issues by volume (Deque, analysis of 13,000+ pages). The remaining issues — keyboard behaviour, reading order, and WCAG 2.2 criteria such as accessible authentication and focus not obscured by sticky headers — require manual testing or real users with disabilities to evaluate. A Lighthouse score of 100 is not a WCAG compliance certificate.
How often should I run an accessibility audit?
Layer 1 automated scanning should run with every significant code push or content update — most development pipelines integrate axe or Pa11y for this. A full Layer 2 manual audit should happen before every major launch and after significant design changes. Layer 3 user testing with people who rely on assistive technology is appropriate annually or at each major redesign. Accessibility is a maintenance discipline, not a one-time project: every new page, image, form, and interactive component is a potential failure point.
What is the difference between WCAG Level A and Level AA?
Level A covers the minimum barriers that make a site completely unusable for some users — missing alt text on images, no keyboard access, no page titles. Level AA adds requirements that address significant practical barriers: sufficient colour contrast for body text (per the WCAG specification), visible focus indicators, captions for live audio, and consistent navigation. Level AA is the standard referenced in most international legislation, procurement requirements, and best-practice guidance, including the GCIS recommendation for South African government sites (which sets Level A as a minimum with Level AA as the implied target).
Where should I start if my site has never been tested for accessibility?
Start with a free automated Layer 1 scan using WAVE (install the browser extension and visit your most-visited pages) or Google Lighthouse (open DevTools → Lighthouse → run an accessibility report). Export the results and sort by impact: missing form labels, missing alt text, and contrast failures affect the most users and are typically the fastest to fix.
Once those are resolved, run a keyboard-only navigation check — tab through every page without using the mouse and confirm that focus never gets trapped and every interactive element is reachable. That two-step process, achievable in a half-day, will clear the majority of user-facing barriers on most South African business sites.
Make Your Site Work for Every South African User
Growth Pulse Media designs and builds websites with WCAG-aligned structure from the first wireframe. We handle the full three-layer workflow — automated scanning, manual keyboard and screen reader testing, and ongoing accessibility monitoring — so your site works for every user, supports your legal position, and performs for search engines. All work is executed in-house from Johannesburg. No obligation — we will get back to you within 24 hours.
Get your free accessibility consultation