Accessibility and Inclusion
Roughly one billion people worldwide live with some form of disability. When you ship software without considering accessibility, you are not building a product with a missing feature — you are building a product that excludes a significant portion of humanity by default. Accessibility is not a legal checkbox. It is the practice of taking seriously the question: can every person who might need this actually use it?
What Accessibility Means in Software
Accessibility (often abbreviated a11y — 'a' plus 11 letters plus 'y') refers to the design of software so that people with disabilities can use it effectively. Disabilities affecting software use include: Visual: blindness, low vision, color blindness. Users may rely on screen readers (software that reads interface text aloud), high-contrast modes, or zoom. Motor: limited or no use of hands or fine motor control. Users may rely on keyboard-only navigation, switch access, or voice control instead of a mouse. Cognitive: dyslexia, attention differences, memory conditions. Users benefit from clear language, consistent navigation, and reduced cognitive load. Auditory: deafness or hard of hearing. Audio content requires captions or transcripts. The Web Content Accessibility Guidelines (WCAG) — maintained by the World Wide Web Consortium (W3C) — provide the international standard for web accessibility. WCAG is organized around four principles summarized as POUR: Perceivable: information must be presentable to users in ways they can perceive. Images need alt text. Videos need captions. Operable: interface components must be operable by everyone. All functionality must be available via keyboard. Users must have enough time to complete tasks. Understandable: information and operation must be understandable. Language must be clear. Error messages must be specific and helpful. Robust: content must be interpreted reliably by a wide variety of technologies, including assistive technologies. WCAG defines three compliance levels: A (minimum), AA (standard legal requirement in many jurisdictions), and AAA (enhanced). Most professional products target AA.
A screen reader is software that reads the text and semantic structure of an interface aloud, allowing visually impaired users to navigate. It relies on the semantic markup of the page — HTML elements like button, nav, h1, and ARIA attributes. A button implemented as a div with an onclick handler looks identical visually but is invisible to a screen reader. Semantic HTML is accessibility infrastructure.
Practical accessibility techniques that every builder should apply: Alt text: every image that conveys information needs an alt attribute describing what it shows. Decorative images get an empty alt attribute (alt='') so screen readers skip them. Keyboard navigation: tab through your entire interface. Every interactive element — buttons, links, form fields, modal dialogs — must be reachable and operable via keyboard alone. Color contrast: text must have sufficient contrast against its background. WCAG AA requires a ratio of at least 4.5:1 for normal text. Tools like WebAIM's Contrast Checker verify this. Focus indicators: the visible outline that shows which element is focused via keyboard. Do not remove this (CSS outline: none on focused elements breaks keyboard navigation). Form labels: every form input must have an associated label element. Placeholder text is not a label — it disappears when the user starts typing. Error messages: identify which field has an error, state what the error is, and tell the user how to fix it. Turning an input box red without explanation fails WCAG. Heading hierarchy: use heading levels (h1 through h6) in logical order to give screen reader users a navigable document structure. AI note: current AI coding tools generate accessible code inconsistently. A function that outputs a button may or may not include proper ARIA roles. Always audit AI-generated UI code for accessibility before shipping.
Complete each statement with the correct term.
Inclusion Beyond Disability
Accessibility addresses disability. Inclusion is broader: designing software so that people across the full diversity of language, culture, device capability, and connectivity can participate. Language and localization: is your product only usable in English? Who does that exclude? Even within English, vocabulary choices, idioms, and reading level affect who can use your software. Device and bandwidth: your product may work beautifully on a high-end laptop on fiber internet. Does it work on a three-year-old Android phone on a slow mobile connection? Optimizing for performance is an inclusion decision. Representation in defaults: software defaults communicate assumptions. A form that assumes two parents, a form that requires a surname, a name field with a character limit that excludes certain cultures' names — each default is a design choice that includes or excludes. Testing with real diversity: if every person who tests your software is similar — same background, same ability level, same devices — you will not discover exclusions until users you excluded encounter them. Diversity in testing is not idealism; it is quality assurance.
Before shipping any user interface, spend fifteen minutes navigating it using only your keyboard. Then, if you can, enable a screen reader (VoiceOver on Mac/iOS, TalkBack on Android, NVDA on Windows — all free) and try to complete a core task. The gaps you find in fifteen minutes are the gaps your disabled users face every time they visit.
A developer implements a dropdown menu that works perfectly with a mouse but cannot be opened or navigated with a keyboard. Which WCAG principle does this violate?
A form shows a red border around an incorrectly filled input field but displays no text explaining what is wrong or how to fix it. Which two WCAG failures best describe this?
Accessibility Audit
- Step 1: Choose any web page — a project you built, your school website, or any site you use regularly.
- Step 2: Perform a keyboard-only audit: unplug or disable your mouse (or use Tab, Shift+Tab, Enter, and Arrow keys only). Navigate to three core features. Record any point where you got stuck or could not complete an action.
- Step 3: Inspect three images on the page. Do they have alt text? Is the alt text descriptive and useful?
- Step 4: Check two form inputs. Do they have visible labels (not just placeholder text)?
- Step 5: Write a short report (one paragraph): what did you find? What would a screen reader user or keyboard-only user experience on this page? What one change would have the largest accessibility impact?