Web accessibility: why it matters and how to improve your site

When people cannot use your site, you lose them quietly

Most businesses do not receive a detailed complaint every time someone encounters a digital barrier. A visitor who cannot open the menu with a keyboard, understand an error message, or read low-contrast text will often simply leave.

Accessibility problems may therefore show up as:

• abandoned forms
• fewer bookings or purchases
• more questions for support
• visitors unable to find important information
• staff having to provide manual workarounds
• weaker trust in the business

Web accessibility is more than an ideal or a technical checklist. The practical question is whether people can perceive the content, navigate the website, understand the interface, and complete the task they came to perform.

My view is straightforward: accessibility is usability taken seriously. Many improvements that help people with disabilities also make the site better for older visitors, mobile users, people with temporary injuries, and anyone using it in difficult conditions.

WCAG is the practical reference point

The Web Content Accessibility Guidelines (WCAG) are developed by the W3C through its Web Accessibility Initiative. They describe how to make web content more accessible to people with visual, auditory, physical, speech, cognitive, and neurological disabilities.

WCAG is organized around four principles. Content and functionality should be:

• perceivable
• operable
• understandable
• robust

In practice, that includes:

• text alternatives for images that communicate information
• keyboard access to menus, buttons, and forms
• sufficient color contrast
• clearly visible focus indicators
• correct heading structure and semantic HTML
• labels and error messages that explain what to do
• content that still works with zoom and larger text
• support for assistive technology such as screen readers

WCAG defines three conformance levels: A, AA, and AAA. Level A addresses foundational barriers. AA adds requirements important to practical access across a broader range of use cases. AAA is the highest level, but it is neither achievable nor necessary for every kind of content.

For many professional websites, AA is a sensible quality target. The legal requirement may be different depending on the country, organization, audience, and service.

WCAG 2.2 is the latest completed version, but laws may reference earlier standards

WCAG 2.2 is the latest completed W3C Recommendation. It extends WCAG 2.1 with additional criteria covering areas such as visible keyboard focus, target size, and accessible authentication.

The W3C encourages organizations to use the latest version. WCAG 2.2 is designed to build on the earlier 2.x standards, although an organization reporting against a specific legal or contractual version may still need to test according to that version’s exact requirements.

This does not mean every law automatically requires full WCAG 2.2 AA conformance. Regulations and procurement standards may still reference WCAG 2.1, WCAG 2.0, or standards such as EN 301 549.

It helps to separate three questions:

1. What does the law require for this particular service?
2. What quality target should guide new design and development?
3. Which barriers are preventing real users from completing tasks today?

A useful accessibility review addresses all three rather than producing one generic score.

What about legal requirements?

Accessibility law varies considerably by jurisdiction, sector, service type, and organization size.

In the European Union, public-sector websites and mobile applications are covered by Directive (EU) 2016/2102 and related national implementations. The requirements commonly reference EN 301 549 and WCAG 2.1 Level AA, alongside provisions that extend beyond WCAG.

The European Accessibility Act has applied to specified products and consumer services since 28 June 2025. Covered areas include:

• e-commerce
• consumer banking and payment services
• electronic communications
• e-books
• parts of passenger transport
• access to audiovisual media services

That does not mean every small business website is covered in the same way. The directive includes exceptions, including one for micro-enterprises providing services, and national implementation still matters.

In the United States, Section 508 applies to federal agencies when they develop, procure, maintain, or use information and communication technology. The Department of Justice also provides web accessibility guidance under the ADA for state and local governments and businesses open to the public. The precise obligations and technical standards vary by context.

Other countries have their own rules. A technical audit can identify barriers and possible failures, but it is not a substitute for legal advice. If legal conformance matters to a launch, procurement, or regulated service, the scope should be confirmed for the relevant jurisdiction.

The point is not to frighten businesses into buying an audit. Accessibility requirements already appear in law, procurement, contracts, and quality standards. Building sound patterns early is usually less expensive than retrofitting an entire design system later.

The business case is practical

Accessibility work does not guarantee a particular increase in conversions. Its value comes from removing avoidable barriers from tasks the website is already supposed to support.

Forms, booking, and checkout

A form without clear labels, useful errors, or a logical focus order is a conversion problem before it becomes a legal question.

An accessible form should, among other things:

• give each field a visible and programmatically associated label
• explain the expected input format
• identify errors clearly
• manage focus predictably
• confirm a successful submission
• work without a mouse

That helps screen reader users, but it also helps anyone completing the form on a phone or correcting a simple mistake.

Mobile use

Many accessibility improvements directly benefit mobile users:

• larger touch targets
• stronger contrast in bright light
• clear focus and active states
• layouts that tolerate zoom
• less demand for precise input
• more useful error messages

A person does not need a permanent disability to benefit. They may be holding the phone with one hand, travelling on a train, or dealing with a temporary limitation.

Structure and findability

Semantic headings, descriptive links, text alternatives, and well-structured content help search and other discovery systems understand the page. That is not a ranking guarantee, but it creates a better technical and editorial foundation.

Accessibility and SEO overlap in some areas, but they are not interchangeable. A page can be well optimized for search while remaining unusable with a keyboard or screen reader.

Maintenance and quality

Accessible components are often easier to:

• test systematically
• document
• reuse
• hand over
• verify after future changes

When buttons, dialogs, forms, and navigation follow defined standards, the team does not have to solve the same defects again in every campaign.

Common problems I see in practice

Accessibility failures are not always technically complex. Many result from design and development choices that looked harmless in isolation:

• pale grey text that looked polished in Figma but is difficult to read on an ordinary screen
• icon-only buttons without an accessible name
• custom dropdowns that cannot be operated with a keyboard
• autoplaying carousels without appropriate controls
• heading levels selected for their appearance rather than document structure
• links labelled only “Learn more”
• errors communicated only through red color
• image filenames used as alt text
• videos without captions
• PDFs used as the only source of essential information
• cookie and chat tools that trap keyboard focus
• animation that ignores the reduced-motion preference

Automated tools can detect some of these issues. Others require manual testing and an understanding of what the user is trying to accomplish.

Where I would start on a typical business website

You do not need to address every issue simultaneously. Begin with the journeys where a barrier has the greatest consequence.

1. Test the main journeys with a keyboard

Check:

• navigation
• priority service pages
• contact forms
• booking or purchase
• login
• dialogs and cookie settings

Use only Tab, Shift+Tab, Enter, Space, and the arrow keys. Confirm that everything can be reached and operated, that focus remains visible, and that its order makes sense.

2. Fix forms first

Forms are often the final barrier before an inquiry or order. Check labels, instructions, errors, focus order, and confirmation after submission.

Do not rely on placeholder text as the only label. It disappears as soon as the user types and is often difficult to interpret.

3. Check contrast using real content

Test more than the hero section:

• body copy
• small supporting text
• links
• buttons
• error messages
• text over images
• navigation and footer
• hover, focus, and disabled states

Contrast failures often appear when colors from a design system are used in combinations nobody tested.

4. Review structure and semantics

Each page should have a meaningful document structure:

• one clear main heading
• a logical hierarchy of subheadings
• real lists for list content
• buttons for actions and links for navigation
• landmarks such as header, nav, main, and footer
• descriptive page titles and link text

Semantic HTML gives browsers and assistive technologies better information without requiring a visual redesign.

5. Audit images, icons, and graphics

Informative images need text alternatives that communicate their function or meaning. Decorative images should not create unnecessary noise for screen reader users.

Alt text should not describe every visible detail. It should provide the information someone would otherwise miss.

6. Test zoom and larger text

Zoom the page to at least 200% and check whether:

• content remains readable
• controls overlap
• important text becomes hidden
• unnecessary horizontal scrolling appears
• forms remain usable
• fixed banners obscure too much of the viewport

7. Review video, audio, and motion

When speech or sound conveys important information, provide captions or a suitable text alternative.

Motion should be pausable or reducible where it may cause difficulty. Respect the user’s reduced-motion preference when animation is not essential to the function.

8. Test with a screen reader

A basic pass with VoiceOver, NVDA, or another screen reader can reveal problems automated tests miss:

• a confusing reading order
• buttons without names
• unclear field labels
• status messages that are never announced
• dynamic content that appears without notification
• unnecessary noise from decorative elements

For larger services, testing with people who use assistive technology in daily life is even more valuable.

Automated tools help, but they are not enough

Tools such as axe and Lighthouse are useful for finding certain technical issues quickly. They can identify some contrast failures, missing names, and invalid structures.

They cannot reliably determine:

• whether alt text is genuinely useful
• whether the heading structure makes sense
• whether the focus order is logical
• whether an error message helps someone recover
• whether a workflow is understandable
• whether keyboard use feels predictable
• whether the content is written clearly

A green automated score is therefore neither proof of legal conformance nor evidence of a good user experience. It is one input in a broader review.

Trade-offs worth discussing honestly

Full review or staged improvement

A small marketing site and a complex booking platform do not carry the same level of risk. If everything cannot be corrected at once, prioritize functions that deliver a service, handle purchases, or generate inquiries.

Staged work still needs a plan. Otherwise, “we will fix it later” becomes one of the signs your website needs an upgrade.

Brand expression or readability

A brand can remain distinctive without thin grey text, weak contrast, and constant motion. Accessibility does not remove creativity. It requires more deliberate decisions about what matters.

Your own code or third-party tools

A strong website can still inherit barriers through:

• chat tools
• cookie banners
• booking platforms
• payment providers
• maps
• video players
• embedded forms

Include these in testing. The user does not care which vendor owns the defect.

Technical conformance or actual usability

A product can pass many formal checks while remaining unnecessarily complicated. WCAG is an essential reference point, but accessible experiences also require clear content, predictable navigation, and real user testing.

What meaningful progress looks like

Meaningful improvement does not require making the entire website perfect at once.

Good progress may mean:

• contact and checkout forms work with a keyboard and screen reader
• primary navigation has visible focus and a logical order
• key calls to action are clear and readable
• priority pages have a meaningful heading structure
• videos containing important speech have captions
• the team knows how to publish more accessible content
• new components are tested before being reused across the site

That removes real barriers now and makes future improvements less expensive.

Accessibility should not be a one-time project immediately before launch. It belongs in design, development, content production, and quality assurance so the same problems are not introduced again.

Want to know where your website stands today?

Contact me for a focused accessibility review. You will receive a prioritized overview of real barriers, the user journeys that should be improved first, and the changes that can be planned as the next step.