Making a Website Accessible: Accessibility in PHP for All Users

Why Accessibility Is Not a "Checkbox" but About Real People

Imagine: you visit a website, and the "Buy" button doesn't work. Or the text blends into the background like a chameleon on asphalt. For a person with poor vision or motor impairments, this is not a "bug" but daily reality. Accessibility (a11y) is not a trendy fad, but a bridge that connects your code with millions of users.

In Russia, according to WHO, over 12 million people have disabilities. And if you add elderly people and temporary limitations (a broken arm, bright sunlight) — the audience that needs accessibility becomes enormous. PHP development with Accessibility in mind is not only ethical but also profitable: search engines love semantics, and users love convenience.

In this article, we'll break down how to implement WCAG (Web Content Accessibility Guidelines) principles directly in PHP code. No fluff, with live examples and ready-made solutions.

Where to Start: Semantic Markup and PHP

Many think Accessibility is only about CSS and JavaScript. But the root of the problem often lies in the server-side part. PHP generates HTML, and if that HTML is "deaf" — no frontend can save it.

Proper Headings and Structure

Screen readers rely on headings. If your page has one <h1> and then immediately an <h3> — it's like a book where a footnote follows the table of contents. The hierarchy is broken.

Bad approach:

<?php\n// Generating content without considering semantics\necho '<div class="title">' . $title . '</div>';\necho '<div class="subtitle">' . $subtitle . '</div>';\n?>

Good approach (Accessibility in PHP):

<?php\n// Semantic structure for screen readers\necho '<h1>' . htmlspecialchars($title, ENT_QUOTES, 'UTF-8') . '</h1>';\necho '<h2>' . htmlspecialchars($subtitle, ENT_QUOTES, 'UTF-8') . '</h2>';\n?>

Notice the htmlspecialchars() — this is the foundation of security and accessibility. Special characters in headings can break markup or be read incorrectly.

ARIA Attributes: When HTML Isn't Enough

ARIA (Accessible Rich Internet Applications) is a set of attributes that supplement semantics. For example, if you're making a custom dropdown list in PHP and JavaScript, the screen reader needs to be told: "Hey, this is a button that opens a menu."

Example of generating an ARIA-compatible button:

<?php\nfunction renderAccessibleButton(string $label, string $id): string {\n    return sprintf(\n        '<button id="%s" aria-expanded="false" aria-controls="menu-%s">%s</button>',\n        htmlspecialchars($id),\n        htmlspecialchars($id),\n        htmlspecialchars($label)\n    );\n}\necho renderAccessibleButton('Menu', 'main-menu');\n?>

The aria-expanded attribute tells the screen reader whether the menu is open. aria-controls links the button to the dropdown block. It's like a GPS navigator for a blind user.

Working with Forms: A Trap for Accessibility

Forms are the most painful spot. A user fills in a field, and the screen reader says: "Text editing." What text? For what purpose? Without labels, it's a gamble.

Linking label and input

In PHP, you often generate fields dynamically. The main rule: every <input> must have a <label> with a for attribute, or the input itself must be wrapped in a label.

Example for a dynamic form:

<?php\n$fields = [\n    'name' => 'Name',\n    'email' => 'Email',\n    'phone' => 'Phone'\n];\nforeach ($fields as $key => $label):\n?>\n    <div class="form-group">\n        <label for="input-&