Healthcare website accessibility means designing and developing a site so that people with disabilities can understand the content, navigate the experience, complete forms and access important services without unnecessary barriers. For healthcare organizations, that should be considered part of good patient experience rather than something added at the end of a project to satisfy a checklist.

WCAG 2.2 is the current Web Content Accessibility Guidelines recommendation from the W3C. It was published as a W3C Recommendation in October 2023 and builds on WCAG 2.1 with additional criteria around areas such as keyboard focus, target sizes, dragging interactions, consistent help and accessible authentication.

For Canadian healthcare organizations, the exact legal requirements depend on where the organization operates, its size and the legislation that applies to it. Ontario is a good example: under the AODA, certain public-sector organizations and businesses or non-profits with 50 or more employees are required to make public websites and web content conform to WCAG 2.0 Level AA, with limited exceptions. That legal baseline is not identical to WCAG 2.2, but from a design perspective we generally think it makes sense to build toward the newer standard rather than designing a new website around an older version simply because that is the minimum named in legislation.

Accessibility requirements should always be confirmed with appropriate legal or accessibility counsel where compliance is material. From a design standpoint, however, the principles are much easier to understand: people need to be able to see, understand and operate the website.

One of the biggest misconceptions about website accessibility is that it can be checked at the end of development and fixed with a few technical changes.

Some issues can certainly be corrected later, but many accessibility decisions are made much earlier. Typography, colour contrast, navigation, button styles, information hierarchy, form structure, link treatment, interaction patterns and mobile behaviour are all design decisions before they become development decisions.

If accessibility only enters the conversation during QA, the team may discover that an entire colour system has insufficient contrast, the navigation cannot be operated properly without a mouse, or a visual interaction depends on something that is inherently difficult to make accessible.

That is why we prefer to think of accessibility as part of the design system itself.

For healthcare in particular, this approach makes sense even before legislation enters the conversation. A patient trying to book care should not have to overcome a design barrier simply because they use a keyboard, screen reader, magnification software or another assistive technology.

Healthcare brands often use soft, calming palettes, and there is nothing wrong with that. The problem arises when those softer tones are also expected to carry important text, buttons or interface elements without enough contrast.

A colour may look beautiful in a brand presentation and still be inappropriate for body text.

That does not mean an accessible healthcare brand has to become visually harsh or limited to black and white. It means the design system needs enough range within the palette to handle different jobs. A pale sage may work beautifully as a background. A darker green from the same system may be needed for text or interactive elements.

Accessibility is not usually about abandoning the brand direction. It is about designing the palette with more intention.

This is one reason accessibility is easier to address during branding and web design together. The team can establish which colours are decorative, which are suitable for text, which combinations work for buttons and how the overall system behaves before dozens of screens have already been designed.

Healthcare websites often need to communicate a lot of information, which makes typography especially important.

Body text should be easy to read. Line lengths should be comfortable. Text should have enough spacing. Headings should create an obvious hierarchy. Decorative typefaces should be used carefully rather than becoming the primary way essential information is communicated.

The goal is not simply to make everything larger.

Good typography creates levels. A strong heading helps someone understand where they are. Subheadings break complex topics into manageable sections. Body text remains comfortable to read, while supporting information can be visually quieter without becoming illegible.

This matters for people with low vision, but it also helps someone who is tired, stressed, distracted or reading a medical page on a phone in poor lighting.

That is one of the recurring themes in accessibility: improvements intended to reduce barriers for people with disabilities often make the site easier for almost everyone.

If an error message is only indicated by a red border, someone who cannot distinguish that colour may not understand what happened.

If active navigation is shown only through a change from blue to green, the same issue can arise.

Use additional signals such as text, icons, labels, underlines, borders or other visual changes where meaning matters.

The same principle applies to charts, status indicators and medical information.

Colour can reinforce meaning. It should not be the only way meaning is communicated.

A website should be operable without requiring a mouse.

That means someone should be able to move through navigation, links, buttons, form fields, accordions, modal windows and other controls using a keyboard.

Just as importantly, the person needs to be able to see where they are.

WCAG includes requirements around visible keyboard focus, and WCAG 2.2 adds further guidance intended to prevent focused elements from becoming obscured by other content.

In practice, that means we should not remove visible focus outlines simply because someone thinks they look unattractive.

Focus states can be designed.

They should be visible, consistent and integrated into the visual system just like hover states and active states.

A keyboard user should never have to guess which link will activate when they press Enter.

Large healthcare organizations often have complex navigation because they have complex offerings.

The solution is not to accept that the menu will be difficult.

Clear labels, logical grouping, predictable menu behaviour and accessible dropdowns all matter. W3C guidance specifically addresses the need for navigation structures and controls to be usable through keyboard interaction.

For patients, this is not an abstract technical concern.

Someone may already be trying to decide between several services, providers or locations. If the navigation itself creates another layer of difficulty, the website is making care harder to access.

That is why accessibility and information architecture are closely connected.

Our guide to medical website navigation looks more closely at how larger service structures can be simplified for patients.

Forms are one of the most important accessibility points on a healthcare website because they are often the point where someone is trying to move from research into care.

Every field should have a meaningful label associated with it.

W3C guidance specifically recommends identifying form controls with labels so that both users and assistive technologies can understand what information belongs in each field. Visible labels also improve usability for people with cognitive disabilities, screen-reader users, speech-input users and people with limited dexterity.

A placeholder inside the field is not a good replacement for a label.

Once someone begins typing, the placeholder disappears. That can make it difficult to remember what the field was asking for, particularly in a longer form.

The label should remain visible.

Instructions should also be provided where the expected format is not obvious. WCAG requires labels or instructions where content requires user input.

Accessibility is not only about technical compatibility with assistive technology.

Cognitive load matters too.

W3C’s form guidance recommends keeping forms simple and asking only for information needed to complete the relevant process, noting that unnecessary or excessive requests can increase abandonment.

That aligns very closely with how we think about healthcare conversion.

If someone is requesting an initial consultation, they may not need to provide a full medical history at that moment. A shorter form is easier to complete on mobile, easier for people with cognitive or motor disabilities, and less intimidating for someone already unsure about taking the next step.

The website should collect what is necessary for that stage of the journey.

The clinical intake system can handle the clinical intake.

This is one of the places where accessibility and conversion design often support exactly the same outcome.

People should not have to hunt for links.

A common modern design habit is removing underlines from text links and relying entirely on colour. That can make pages feel visually cleaner, but it can also make interactive content harder to identify.

The answer does not necessarily mean underlining every navigation item and button.

Context matters.

A button clearly looks like a button. A navigation item clearly sits in a navigation system. A link inside a paragraph may need a stronger visual cue because otherwise it can look exactly like the surrounding copy.

Again, clarity should win over visual subtlety when the two are in conflict.

The same applies to hover states, focus states and disabled controls. Interactive elements should behave predictably.

WCAG 2.2 introduced a Level AA criterion addressing minimum target size for pointer inputs.

From a practical design standpoint, this reinforces something we already want on healthcare sites: links and buttons should be easy to tap.

Small icons pressed tightly together can be difficult for anyone using a phone, but especially for people with limited dexterity, tremors or other motor impairments.

This becomes particularly important around mobile navigation, booking controls, pagination, form checkboxes and close buttons.

Making a tap target slightly larger is rarely going to hurt the design.

It may make the interface substantially easier to use.

Not every image needs a long description.

Alternative text should communicate the purpose of an image when that information matters to someone who cannot see it.

A decorative image that adds atmosphere but no meaningful information may not need descriptive alt text. A photograph identifying a provider may benefit from straightforward identification. An infographic containing important information needs an accessible alternative that communicates that information rather than simply saying “infographic.”

The question should be: what would someone miss if they could not see this?

Write alt text based on that answer.

Healthcare websites also need to be especially careful when important information is embedded inside graphics. If treatment instructions, schedules, service details or other essential content only exist as text inside an image, that creates obvious accessibility problems.

Important information should exist as real page content wherever possible

If your website uses video, think about the people who cannot hear the audio and the people who cannot see the visuals.

Captions can make spoken content accessible to people who are deaf or hard of hearing while also helping people watching without sound.

Depending on the content, transcripts or audio description may also be appropriate.

Do not assume video automatically creates a richer experience for everyone.

The richer experience is one that gives people more than one way to access the information.

Headings are not simply larger text.

A well-structured page uses headings to establish relationships between sections and help people understand how the content is organized.

That makes a long healthcare page much easier to scan visually, but headings also provide useful structure to assistive technologies.

The page should generally have one clear primary topic, with H2s and H3s used in a logical hierarchy underneath it.

Do not choose heading levels based purely on what size you want the text to appear.

That is a styling problem.

The semantic structure should describe the content. CSS can determine what it looks like.

This also happens to be good for search.

Strong accessibility, UX and SEO often reward the same basic discipline: clear structure.

Healthcare brands increasingly want digital experiences that feel modern and dynamic, and motion can absolutely help with that.

But it should have a purpose.

Large parallax effects, constant movement, auto-playing carousels or dramatic transitions can become distracting or uncomfortable for some users.

Motion should not be required to understand the content, and users who have indicated a preference for reduced motion should be considered during development.

This does not mean accessible healthcare websites need to feel static.

It means motion should support the experience rather than becoming the experience.

Healthcare websites often contain downloadable patient forms, referral documents, brochures, reports and other PDFs.

Those documents can create their own accessibility issues.

A website redesign can meet a strong accessibility standard while still sending patients into inaccessible PDFs once they click a resource link.

If an important form or document can be provided as accessible HTML content, that is often easier to maintain and use across devices. Where PDFs are necessary, the documents themselves may need accessibility consideration, including reading order, headings, tags and form fields.

Accessibility does not stop at the edge of the webpage.

Accessibility widgets and overlays are sometimes marketed as a fast way to make a site accessible.

We would not treat them as a replacement for designing and developing the underlying website properly.

Accessibility needs to exist in the HTML, interaction patterns, forms, navigation, content structure and visual design itself.

A widget cannot retroactively fix every structural problem in a poorly built site.

The better approach is to create accessibility into the system from the beginning and then test the actual experience.

Automated tools can identify many problems quickly.

They are valuable during design QA, development and ongoing website maintenance.

They cannot tell you everything.

A tool may identify that an image has an alt attribute. It cannot always determine whether the description is actually useful. It may confirm that a form has a label without knowing whether the wording makes sense. It cannot fully replicate what it feels like to move through a complex patient journey using only a keyboard.

Accessibility testing should therefore combine automated checks with human review.

For more complex or high-risk organizations, formal accessibility testing by specialists and users with disabilities can add another important layer.

Clear language is an accessibility issue too.

A page can meet every technical requirement and still be difficult to understand because the content is unnecessarily complicated.

Healthcare naturally requires specialized terminology, and accuracy should never be sacrificed.

But technical terms can usually be explained.

Long paragraphs can be structured more clearly. Headings can help people understand what is coming next. Instructions can tell someone what they need before beginning a form.

That is why we think accessible healthcare content should be designed, not simply pasted into a compliant template.

Our article on Medical Website Copy That Converts looks more closely at how healthcare information can be clear without losing credibility.

WCAG 2.2 builds on the previous guidelines rather than replacing the underlying principles.

Among the additional success criteria are requirements relating to keeping keyboard focus from being obscured, providing minimum target sizes, offering alternatives to dragging interactions, keeping help mechanisms consistent, reducing unnecessary repeated data entry and improving accessible authentication.

Those additions reflect how websites themselves have changed.

Modern sites contain more interactive components, sticky interfaces, authentication flows and application-like behaviours than they did when earlier WCAG versions were written.

For a healthcare website, many of these criteria are particularly relevant because the experience may include patient portals, booking systems, forms, provider filters and other interactive tools.

The more a healthcare website behaves like an application, the more important it becomes to consider accessibility beyond text contrast and alt tags.

Not currently.

Ontario’s public website requirements under the AODA refer to WCAG 2.0 Level AA, with specified exceptions, for the organizations covered by those requirements.

That is an important distinction.

AODA compliance and following the current WCAG recommendation are related, but they are not identical statements.

For a new site, however, designing only to an older standard can be short-sighted. WCAG 2.2 is the current W3C recommendation, so using it as the design and development target can provide a stronger and more current accessibility foundation.

Organizations should confirm their actual legal obligations independently, especially when operating across multiple provinces or serving public-sector audiences.

Canada does not have one simple web accessibility rule that applies identically to every private healthcare organization in every province.

Requirements can vary based on jurisdiction, organizational size and whether the organization is public, private or non-profit.

Ontario businesses and non-profits, for example, have obligations under the AODA depending on their size, and Ontario states that organizations with 50 or more employees are among those subject to its public website accessibility requirements.

A clinic operating only in Ontario may therefore have a different compliance picture from a national healthcare network operating across several provinces.

For that reason, we recommend separating two questions:

What is the legal minimum that applies to us?

What standard do we want our patient experience to meet?

The first is a legal and compliance question.

The second is a design decision.

Ideally, the answer to the second should not simply be “whatever we can get away with.”

For us, accessibility is part of designing a healthcare website well.

It influences how we use colour, type, navigation, hierarchy, forms, buttons, interactions and content. It continues into development, where semantic structure, keyboard behaviour, focus states and other technical considerations become important.

That does not mean an agency should make sweeping legal promises about compliance.

Accessibility is complex, websites change after launch and organizations may have requirements specific to their jurisdiction or operation.

What we can do is design and develop with accessibility deliberately in mind rather than treating it as a repair job.

That distinction matters.

A good healthcare website should not merely pass tests.

It should be easier for more people to use.

It can be.

If the existing site has isolated accessibility issues, those may be fixable without redesigning everything.

If the problems are built into the design system, navigation, templates and underlying development, correcting them one by one can become a much larger exercise.

A redesign gives the organization an opportunity to reconsider the entire system at once: colours, typography, forms, navigation, interaction states, content structure and development patterns.

That is often more efficient than layering fixes onto a site whose foundations were never designed with accessibility in mind.

Our Healthcare Website Redesign Checklist covers accessibility alongside the other signs that a clinic may have outgrown its current site.

Accessibility can sound technical when it is discussed through standards, success criteria and legislation.

At the patient level, it is much simpler.

Can I read this?

Can I understand where to go?

Can I use the menu?

Can I complete this form?

Can I see which button is selected?

Can I access the information in a way that works for me?

Those are design questions.

And for a healthcare organization, they are important ones.

A website may be the first point of access to the organization. Making that experience harder for someone because of a disability is not only an accessibility issue. It is a patient-experience issue.

The best healthcare websites remove barriers wherever they can.

Natashya Vince, Co-Founder & Creative Director, Envy Design Co.

Natashya Vince is Co-Founder and Creative Director at Envy Design Co., an independent branding and web design agency working with healthcare organizations across Canada and the United States. Her work spans brand strategy, visual identity, UX/UI and custom website design for healthcare startups, established practices, mental health organizations, multi-location clinic networks, healthcare technology companies and health systems.