Accessibility

Where accessibility fits in the customer journey

Accessibility belongs in acquisition, evaluation, conversion, and retention work. A person may discover a useful article but encounter an inaccessible download, or successfully register for a demonstration and then be unable to use the meeting platform. Treating only the first page as the experience misses these handoffs.

Map one complete task before creating a long checklist. For a webinar campaign, the task includes reading the invitation, understanding the topic, choosing a session, registering, receiving confirmation, joining, following the presentation, and accessing the recording. Each step has content, interaction, and communication requirements.

Also consider who controls each step. Your team may own the landing page while a vendor supplies registration and video hosting. Vendor ownership does not remove the visitor's difficulty. Record dependencies early enough to choose a suitable service, configure it properly, or offer an equivalent accessible route while a defect is resolved.

Four principles for evaluating an experience

A useful framework asks whether an experience is perceivable, operable, understandable, and robust. These principles connect technical work to what a person needs to accomplish.

• Perceivable: information can be received through appropriate alternatives. An important spoken announcement needs a text equivalent, while a chart needs a way to communicate its meaning beyond its visual appearance.
• Operable: people can use the controls and move through the experience. A navigation menu that only opens on mouse hover can prevent someone using a keyboard from reaching its links.
• Understandable: the content and behavior make sense. Clear field labels and specific recovery instructions help a person understand what happened and what to do next.
• Robust: the implementation works with relevant browsers and assistive technologies. A custom control must communicate its purpose and state, not merely resemble a familiar button.

Use these questions during design reviews. They expose different kinds of failure and help avoid reducing accessibility to one visual check.

Standards, scope, and the meaning of conformance

The Web Content Accessibility Guidelines provide testable criteria for web accessibility. WCAG 2.2 organizes requirements into levels A, AA, and AAA. A team can use a defined version and level to create a shared evaluation target; a vague promise to make something “accessible” leaves too much room for different interpretations.

Specify the scope as well as the target. A review of five landing pages is not an assessment of every website feature. Document the pages, processes, states, technologies, and evaluation date that a conclusion covers. A form's empty state, validation errors, and confirmation state all matter.

Technical conformance and applicable legal duties are separate questions. Do not turn a scanner score or a limited review into an unsupported compliance claim. For marketing teams, a practical starting point is a documented standard, clear acceptance criteria, and responsibility for investigating barriers that people report.

Write and structure content for navigation

Headings should explain the content beneath them and form a useful outline. A person scanning visually or navigating with assistive technology should be able to find pricing, eligibility, limitations, and next steps without reading every paragraph. Choose heading levels for document structure rather than selecting a level simply because its default size looks right.

Write link text that describes its destination or action. “Compare subscription plans” carries more information than a repeated “Click here.” Keep important conditions near the claim they qualify. A short offer followed by distant, dense qualifications creates avoidable interpretation work.

Plain language also helps readers who are unfamiliar with a subject or have difficulty processing complex text. Explain necessary terminology, split complicated instructions into manageable steps, and use examples that support the decision being made. Clarity does not require removing useful detail. A carefully organized explanation can remain comprehensive while giving readers several ways to locate the part they need.

Make visual design readable and adaptable

Brand colors need usable combinations, not just attractive individual swatches. WCAG's minimum text-contrast criterion generally requires a ratio of 4.5:1, with 3:1 for qualifying large text and specified exceptions. Test actual foreground and background combinations, including text over photographs, gradients, and interactive states. A successful measurement in the design file does not prove every live variation works.

Do not communicate a result through color alone. A red field border should be accompanied by an understandable error message. A chart can combine labels, patterns, or distinct shapes with color so that the meaning survives when colors are difficult to distinguish.

Layouts should also accommodate enlargement. Check that headings wrap, controls remain reachable, and text does not disappear inside fixed-height containers. For typical vertically scrolling content, reflow evaluation includes a width equivalent to 320 CSS pixels, subject to exceptions for content that requires two-dimensional layout. Inspect the experience, including sticky elements, rather than treating a narrow screenshot as sufficient evidence.

Give images, audio, and video useful alternatives

Decide what each image contributes in its particular context. An informative image needs an alternative that conveys its relevant meaning. A purely decorative image should not add unnecessary screen-reader announcements. When an image acts as a control, its accessible name should explain the action rather than describe its appearance.

For a performance chart, a brief image description may identify the subject but fail to communicate the evidence. Include the important conclusion and provide the underlying values in an accessible form when readers need them. Avoid forcing essential offer details into a graphic that cannot adapt like ordinary text.

Plan media accessibility before recording. Review captions for names, technical terms, and meaningful sounds instead of assuming an automatic transcript is accurate. Describe important visual information that the spoken track omits. Provide a useful transcript, but do not assume that a transcript alone replaces every accessibility requirement for every video. The format and content determine what alternatives are needed.

Support keyboard operation and predictable focus

A keyboard user should be able to reach and operate the controls needed to complete a task. Test menus, filters, accordions, dialogs, media controls, and submission buttons. A page that works with a mouse can still contain an unreachable control or trap keyboard focus inside an overlay.

The focused element needs a visible indication. Removing outlines without providing a clear replacement makes navigation difficult. Follow the focus sequence yourself: it should reflect a sensible reading and interaction order, and opening or closing a dialog should not leave the user searching for their position.

Use standard controls where they fit the task. A native button already carries useful behavior; an element that merely looks like a button needs additional implementation work. If a custom widget is necessary, agree on its keyboard behavior and accessible semantics before styling it. After implementation, check the behavior in context, including what happens after validation, loading, cancellation, and success.

Build forms that help people recover

A form is accessible only when people can understand its requirements, enter information, recognize problems, and complete submission. Give every field a persistent label and identify required information clearly. Placeholder text is a poor substitute for a label because it disappears when someone begins typing.

Explain unusual formatting requirements before submission. Accept reasonable variations when they do not change meaning; an unnecessarily strict phone-number pattern can reject valid information. When an error occurs, identify the affected field and explain how to correct it. Preserve valid values so that recovery does not require repeating the whole task.

Ensure that error and success messages are available to assistive technology, and test their timing. Validation that interrupts on every keystroke can become confusing. Check both browser-side and server-side handling: accessible feedback does not replace secure validation, and secure validation does not automatically produce understandable feedback.

For a lead form, a practical acceptance test is to submit an incomplete entry, correct it using only the keyboard, and verify that confirmation is unambiguous. Include a server failure scenario so the person knows whether their enquiry was received.

Worked example: improving a webinar registration journey

Consider a fictional software company promoting a product webinar. Its invitation uses a poster image containing the time and title. The landing page has a custom dropdown that cannot be operated by keyboard, and unsuccessful registration produces only a red outline. These are three separate barriers in one campaign.

The team first moves the event details into live email text and gives the poster an appropriate alternative. It replaces the custom dropdown with a suitable standard control. It adds persistent field labels, specific error messages, and an announced confirmation. The webinar producer checks captions and ensures that presenters describe demonstrations that would otherwise depend entirely on sight.

The acceptance task is concrete: a participant can find the event time, choose a session, recover from a missing required field, register, and access the session information. The team tests that journey with keyboard navigation, enlargement, and relevant assistive technology, then includes people with disabilities in a usability review.

Success is demonstrated by removing the identified barriers and verifying task completion. A subsequent increase in registrations may be encouraging, but other campaign changes and audience differences prevent attributing the entire increase to accessibility work without a suitable evaluation design.

Combine automated checks with human evaluation

Automated checks are useful for finding certain repeatable problems, such as missing accessible names or some contrast failures. Run them during development and after changes to shared components. They can catch regressions quickly, but their coverage is limited.

Human evaluation is needed to judge whether an image alternative is meaningful, instructions are understandable, focus behaves sensibly, and a task can actually be completed. Build a test plan around representative journeys and component states, including errors, empty results, loading, and success. Include assistive technology testing performed by people with the necessary skills.

Involving people with disabilities adds insight that a technical checklist can miss. Recruit participants whose access needs are relevant to the experience, provide accessible research materials, and compensate their time. Record barriers with reproduction steps, affected tasks, observed impact, and environment details. One participant's success does not establish universal accessibility, just as one scanner's clean result does not prove that all criteria are met.

Assign ownership and prioritize remediation

Accessibility work stalls when a report lists issues without a delivery process. Give each issue an owner, a concrete expected outcome, and a verification method. Separate the person implementing the change from the person confirming that the original barrier has been removed when possible.

Prioritize by impact and reach. A keyboard trap in a shared navigation component can block many journeys, while an isolated cosmetic problem may affect fewer people. Consider frequency, task importance, reusable components, and dependencies rather than sorting only by how easy a fix appears.

Build prevention into normal production. Designers specify interaction states, writers check structure and alternatives, developers implement semantics, and quality reviewers test journeys. Content editors need guidance for everyday decisions such as uploading images and creating tables. Fixing a component once is valuable, but it must remain usable when real content, translations, or a new campaign variation are added. Include accessibility checks in the definition of done for changes that affect users.

Measure progress without hiding uncertainty

Useful operational measures include unresolved blockers, time to resolve reported barriers, coverage of critical journeys, and recurrence of previously fixed defects. Report the scope behind each number. “All registration journeys tested this release” is more informative than an unexplained accessibility percentage.

A hypothetical audit finds 24 defects across three journeys. The team resolves 18, leaving six open. That is a 75% reduction in recorded defects, not proof that the experience is 75% accessible. Defects differ in severity, the review may have missed others, and new content can introduce new problems.

Keep a record of what was tested, by whom, with which methods, and what remains unresolved. Pair this with an accessible feedback route that reaches someone able to investigate. Avoid inferring a visitor's disability from analytics or collecting sensitive information merely to produce a dashboard. Measure the quality of the experience and the reliability of your improvement process, while giving people a straightforward way to describe barriers voluntarily.

Related terms

• Inclusive design: a design approach that considers different needs and circumstances from the beginning. It helps teams identify exclusion before it becomes a recurring production defect.
• User experience: the broader experience of interacting with a product or service. Accessibility is a necessary consideration within that experience, including the handoffs between marketing and product touchpoints.
• Usability testing: observing people attempting realistic tasks. Including people with disabilities can reveal barriers that technical inspection alone does not expose.
• Image alt text: text that communicates the relevant meaning or function of an image. Its content depends on the image's role and surrounding context.
• Information architecture: the organization and labeling of information. A clear structure supports navigation, understanding, and the ability to locate essential conditions or next steps.
• Conversion rate optimization: improving the proportion of visitors who complete a defined action. Removing access barriers can support completion, while conversion metrics alone cannot establish that an experience is accessible.