Inclusive websites
What is web accessibility?
Web accessibility means building the website so people with disabilities can perceive it, operate it, understand it, and complete important tasks. It belongs in the content, design, code, and testing process from the beginning. If AI helps develop the site, a human still has to validate the result. An automated score, generated claim, plugin, or last-minute repair cannot prove that the real experience works.
Perceive, operate, understand, rely
Accessibility covers the whole experience
A page must communicate its meaning and behavior through more than one sensory or input path.
People need to perceive the information
Text needs sufficient contrast and must remain readable when enlarged or reflowed. Meaning cannot depend on color alone. Informative images need useful text alternatives, while decorative images should stay out of the reading experience. Audio and video need the appropriate captions, transcripts, or descriptions.
The correct alternative depends on what the content contributes. Repeating a file name or stuffing keywords into alt text does not make an image accessible.
People need to operate the interface
Links, buttons, menus, dialogs, forms, and other controls need to work without a mouse. Keyboard focus must be visible, move in a sensible order, reach every action, and escape components without becoming trapped.
Controls also need usable target sizes and enough time to complete tasks. Motion, animation, dragging, hover behavior, and time limits require alternatives or controls where applicable.
People need to understand what happened
Headings and labels should describe their purpose. Navigation and repeated components should behave consistently. Instructions need to appear before they are needed, and error messages must identify the problem and help the person correct it.
A visual change is not enough when assistive technology also needs to learn that a menu opened, a field became invalid, or a submission succeeded.
Structure and semantics
Native HTML carries useful behavior
The simplest correct element is usually the strongest starting point.
Use elements for their intended purpose
Headings create an outline, lists identify related items, landmarks divide page regions, labels name form controls, links navigate, and buttons perform actions. Browsers and assistive technologies already understand these relationships when the markup is correct.
A styled generic element does not gain button behavior merely because it looks clickable. Recreating native controls requires the developer to reproduce keyboard interaction, focus, name, role, state, and platform behavior.
Use ARIA to add missing semantics, not to disguise broken controls
W3C guidance says to use a native HTML element when it already provides the required semantics and behavior. ARIA can describe advanced widgets and changing states, but it does not automatically add keyboard operation or repair incorrect interaction.
Every ARIA role or state is a promise about how the component behaves. Test that promise with the keyboard and relevant assistive technology.
A complete task
Forms expose accessibility failures quickly
A form is not accessible just because every field can receive focus.
Label and explain the input
Give each control a persistent, programmatically associated label. Group related choices, identify required fields in text as well as code, explain unusual formats before entry, and request only the information needed for the task.
Placeholder text is not a dependable replacement for a label because it can disappear during entry and may not provide a clear accessible name.
Make failure and success recoverable
When validation fails, keep safe values, identify every affected field, explain how to fix it, and move or announce focus so the errors can be found. Do not rely on a red border alone.
After submission, provide a clear confirmation that is available visually and programmatically. If the server rejects the request, say what the person can do next rather than leaving a silent spinner or generic failure.
Evaluation
No single test proves accessibility
Different methods reveal different kinds of barriers.
Automation is useful and incomplete
Automated checks can find conditions such as missing attributes, some contrast failures, duplicate identifiers, and certain invalid relationships. W3C states that no tool alone can determine whether a site meets accessibility standards.
A perfect automated score cannot judge whether alt text is useful, reading order makes sense, instructions are understandable, keyboard behavior matches the visible interface, or a real task can be completed.
Combine standards, manual review, and user evidence
Evaluate representative pages, shared components, states, breakpoints, and complete journeys against the selected WCAG criteria. Manually test keyboard operation, focus, zoom and reflow, screen-reader behavior, form errors, reduced motion, and content meaning. AI-assisted development does not remove that human validation step.
Automation is useful for repeatable checks, and people with disabilities can reveal barriers a checklist misses. Neither a tool nor one small user study establishes accessibility for every disability or page. Record the scope, methods, environments, failures, fixes, and limitations of the evaluation.
Maintenance
Accessibility needs an owner after launch
A site can regress through one component update, content entry, embedded tool, or new document.
Build checks into routine delivery
Define the target standard and scope, reuse reviewed components, include accessibility in acceptance criteria, run automated checks in development, and manually test meaningful changes before release. Review third-party widgets and documents rather than assuming the vendor handled them.
Maintain a way for visitors to report a barrier and give those reports an accountable response path. Prioritize failures that block essential tasks, then address systemic component problems before repeating page-level repairs.
Describe claims precisely
Do not call a site certified or fully accessible because a scanner passed, an overlay was installed, or one assistive-technology session succeeded. State which standard, level, pages, components, methods, environments, and date the evaluation covered.
Accessibility standards and testing evidence can support responsible work. Legal duties depend on the organization, jurisdiction, service, and facts, so legal conclusions require qualified advice.
Common questions
What business owners usually want to know.
Is an automated accessibility score enough?
No. W3C states that no tool alone can determine whether a site meets accessibility standards. Automation should be combined with knowledgeable manual evaluation and, where appropriate, feedback from people with disabilities.
Does adding ARIA make a component accessible?
No. ARIA can expose roles, names, states, and relationships to assistive technology, but it does not automatically provide correct keyboard behavior or interaction. Prefer native HTML when it already supplies the required semantics and behavior.
What WCAG level should a business target?
The target depends on the product, users, contractual requirements, applicable law, and organizational policy. WCAG 2.2 defines A, AA, and AAA conformance levels; a business should document the selected target and obtain qualified legal advice for legal obligations.
Can an accessibility overlay prove that a website is accessible?
No. Adding a script does not establish conformance or prove that complete tasks work across disabilities, browsers, and assistive technologies. The underlying content and components still require scoped evaluation and remediation.
Research
Sources and further reading
Reviewed 2026-08-24. Use these references to check the details and continue your own research.
Need help applying this to your business?
Tell us where the process breaks down today. We will ask the questions needed to find the cause and decide what is worth fixing first.