Accessibility in Software: Building for Everyone

Approximately 7.5% of South Africa's population — over 4.5 million people — live with some form of disability. Globally, the World Health Organisation estimates that 16% of people experience significant disability. These are not edge cases. They are your users, your customers, and your colleagues. Building software that excludes them is not just ethically problematic — it is a business failure.

Accessibility (often abbreviated as a11y) is the practice of designing and building software that can be used by people with diverse abilities, including those with visual, auditory, motor, and cognitive impairments. This article provides a practical guide to building accessible web applications, grounded in the WCAG 2.2 standard and informed by real-world implementation experience at Pepla.

WCAG 2.2 AA: The Standard That Matters

The Web Content Accessibility Guidelines (WCAG) are published by the W3C and are the globally recognised standard for web accessibility. WCAG 2.2, released in October 2023, is the current version. It defines three conformance levels: A (minimum), AA (recommended), and AAA (ideal).

For most organisations, WCAG 2.2 Level AA is the target. This is what legislation typically references, what procurement requirements specify, and what provides a meaningfully accessible experience without requiring impractical constraints on design.

WCAG is organised around four principles, often remembered by the acronym POUR:

• Perceivable: Information and UI components must be presentable to users in ways they can perceive. This covers text alternatives for non-text content, captions for video, sufficient colour contrast, and resizable text.
• Operable: UI components and navigation must be operable. This covers keyboard accessibility, sufficient time to interact, seizure-safe animations, and navigable page structure.
• Understandable: Information and operation of the UI must be understandable. This covers readable text, predictable behaviour, and input assistance for forms.
• Robust: Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This primarily means valid, semantic markup.

WCAG 2.2 added several new success criteria particularly relevant to mobile and touch interactions, including minimum target size (at least 24x24 CSS pixels), consistent help mechanisms, and redundant entry (not requiring users to re-enter information they have already provided).

Semantic HTML: The Foundation

The single most impactful thing you can do for accessibility is use semantic HTML correctly. This means using the right element for the right purpose: <button> for actions, <a> for navigation, <nav> for navigation regions, <main> for primary content, <header> and <footer> for page structure, <h1> through <h6> for heading hierarchy.

When you use a <button> element, the browser provides keyboard focusability, Enter/Space key activation, and an implicit ARIA role — for free. When you use a <div onclick="..."> instead, you must manually implement all of that. Most developers do not, and the result is an element that works with a mouse but is invisible to keyboard users and screen readers.

Common semantic HTML mistakes we encounter in audits:

• Using <div> or <span> for interactive elements instead of <button> or <a>.
• Skipping heading levels (jumping from <h1> to <h3>) or using headings for styling rather than structure.
• Missing <label> elements for form inputs, or using placeholder text as a substitute for labels.
• Using <table> for layout instead of data presentation.
• Missing landmark regions (<main>, <nav>, <aside>) that screen reader users rely on for page navigation.

ARIA: When Semantic HTML Is Not Enough

Accessible Rich Internet Applications (ARIA) attributes extend HTML's accessibility semantics for complex interactive components that have no native HTML equivalent — tabs, accordions, modals, autocomplete dropdowns, tree views.

The first rule of ARIA is: do not use ARIA if native HTML can achieve the same result. A <button> does not need role="button". An <input type="checkbox"> does not need role="checkbox". ARIA is for custom components where no native element provides the required semantics.

When you do need ARIA, the essential attributes are:

• role — defines what the element is (tab, tabpanel, dialog, alert, etc.).
• aria-label and aria-labelledby — provide accessible names for elements that do not have visible text labels (icon buttons, complex widgets).
• aria-describedby — associates supplementary information (help text, error messages) with an element.
• aria-expanded, aria-selected, aria-checked — communicate the current state of interactive components to assistive technology.
• aria-live — announces dynamic content changes (notifications, form validation errors) to screen readers without requiring focus change.
• aria-hidden="true" — hides decorative or redundant content from assistive technology.

Keyboard Navigation

Every interactive element in your application must be operable with a keyboard alone. This is not only a WCAG requirement — it is essential for users who cannot use a mouse due to motor impairments, for power users who prefer keyboard workflows, and for screen reader users who navigate entirely by keyboard.

Keyboard navigation fundamentals:

• Tab order must follow visual order. Users navigate with Tab (forward) and Shift+Tab (backward). The focus sequence should match the logical reading order of the page. CSS techniques like flexbox order or absolute positioning can create mismatches between visual and DOM order — test by tabbing through your page.
• Focus must be visible. The browser's default focus outline is functional but often overridden by CSS resets. If you remove the default outline, you must replace it with a custom focus indicator that is clearly visible against your background colours. A 2px solid outline with sufficient contrast is the minimum.
• Modal focus trapping. When a dialog or modal opens, keyboard focus must be trapped within it until it is dismissed. Tab should cycle through the modal's interactive elements without escaping to the page behind. When the modal closes, focus should return to the element that triggered it.
• Skip links. A "Skip to main content" link as the first focusable element on the page allows keyboard users to bypass repetitive navigation on every page load.

Colour Contrast

WCAG 2.2 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). This ensures readability for users with low vision or colour deficiencies.

Common contrast failures include light grey text on white backgrounds (popular in "modern" designs but often falling below the 4.5:1 threshold), coloured text on coloured backgrounds without sufficient luminance difference, and placeholder text in form inputs (which is inherently low-contrast by browser default).

Contrast checking should be part of your design process, not an afterthought. Tools like the Stark plugin for Figma, the axe browser extension, and the built-in contrast checker in Chrome DevTools make this easy to verify during both design and development. At Pepla, our designers check contrast ratios as they work, not after handoff.

Remember that colour must never be the sole means of conveying information. If an error state is indicated only by turning a field border red, colour-blind users will miss it. Combine colour with icons, text labels, or pattern changes to ensure the information is perceivable regardless of colour vision.

Screen Reader Testing

Automated tools catch approximately 30-40% of accessibility issues. The rest require manual testing, and the most important manual test is using a screen reader. If you have never navigated your application with a screen reader, you do not understand how accessible it is.

The major screen readers are:

• NVDA (Windows, free) — the most practical option for developer testing.
• JAWS (Windows, commercial) — the most widely used screen reader among blind users.
• VoiceOver (macOS/iOS, built-in) — essential for testing Apple platform accessibility.
• TalkBack (Android, built-in) — essential for Android accessibility testing.

Screen reader testing should verify: all images have appropriate alt text, all form fields have accessible labels, all interactive elements announce their role and state, page structure (headings, landmarks) provides meaningful navigation, and dynamic content changes (notifications, updated regions) are announced.

Automated Accessibility Testing Tools

While automated testing cannot replace manual testing, it is essential for catching regressions and enforcing baseline compliance at scale. Key tools include:

• axe-core — the industry-standard accessibility testing engine, available as a browser extension, CI integration, and testing library. It catches common issues like missing alt text, insufficient contrast, missing form labels, and incorrect ARIA usage.
• Lighthouse — Google's auditing tool includes an accessibility score based on axe-core rules, plus additional best practice checks.
• Pa11y — a command-line accessibility testing tool that can be integrated into CI/CD pipelines to fail builds on accessibility violations.
• jest-axe / cypress-axe — integrate axe-core into your unit and end-to-end test suites so accessibility regressions are caught the same way functional regressions are.

At Pepla, we run axe-core in our CI pipeline on every pull request. Any new accessibility violation blocks the merge. This does not guarantee full accessibility — it guarantees that the issues automation can detect are caught before they reach production.

Legal Requirements in South Africa

South Africa's Constitution (Section 9) prohibits unfair discrimination on the basis of disability. The Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA) extends this to services — including digital services. While South Africa does not yet have legislation specifically mandating WCAG compliance (as the EU's European Accessibility Act or the US's ADA do), the constitutional framework and PEPUDA create legal risk for organisations that provide inaccessible digital services.

For organisations doing business with government, the State Information Technology Agency (SITA) has published guidelines recommending WCAG 2.0 AA compliance for government websites. And for any organisation operating internationally or serving international customers, the European Accessibility Act (effective June 2025) and ADA compliance may apply directly.

Beyond legal compliance, accessibility is increasingly a procurement requirement. Large corporate and government clients include accessibility requirements in their RFPs. Building accessible software from the start is cheaper than retrofitting it when you lose a deal over non-compliance.

Accessibility is not a checklist you complete at the end of a project. It is a quality standard you maintain throughout development — just like security, performance, and code quality. Build it in from the start, test it continuously, and treat violations as bugs.

The tools, standards, and techniques are mature. The knowledge is freely available. The only barrier to building accessible software is the decision to prioritise it. Make that decision, and your software will serve everyone.