The Form Looked Finished. The Task Wasn’t.

What accessible web design actually requires

Accessible web design means creating content and interactions that people with different abilities and ways of using technology can perceive, operate, understand, and use reliably. In practice, that means treating the entire user journey—not just a polished screen—as the design object.

The Web Content Accessibility Guidelines (WCAG) organize accessibility under four principles: perceivable, operable, understandable, and robust. WCAG 2.2 is the standard referenced here; specific success criteria and conformance levels matter more than a generic claim that a page is “accessible.”

A screenshot can tell you about hierarchy and some aspects of contrast. It cannot show whether a custom dropdown works from the keyboard, whether a screen reader announces an input's purpose, or whether an error message reaches someone who did not notice a color change. Those questions belong in the design process, not in a last-minute repair queue.

The first failure: the next action is unreachable

Return to the fictional enrollment page. The designer has made the “Continue” button prominent. But at increased zoom, a sticky purchase bar covers the control that currently has keyboard focus. The person can press Tab again, yet cannot easily tell where they are.

Two requirements are relevant. WCAG 2.2, 2.1.1 requires functionality to be operable through a keyboard interface, subject to its stated exception. 2.4.11, Focus Not Obscured (Minimum), a Level AA criterion introduced in WCAG 2.2, requires a focused component not to be completely hidden by author-created content, with defined qualifications. Keyboard focus also needs a visible indication under 2.4.7.

A product decision is hiding inside those rules: a persistent sales bar may improve the visibility of the enrollment action, but it cannot be allowed to block the path to completing it. The remedy might be a different sticky behavior at smaller viewports, adequate scroll space, or a layout that keeps the focused control in view. The right implementation needs testing in the actual browser.

Pointer use has its own constraints. WCAG 2.2, 2.5.8 sets a Level AA minimum target size of 24 by 24 CSS pixels or qualifying spacing, with other explicit exceptions. That is a threshold, not a recommended ideal for every button. Make controls comfortably operable for their context instead of designing every target to the thinnest defensible minimum.

The second failure: the interface asks a question it cannot explain

The same page has a lovely minimal input. “Email address” appears as placeholder text and disappears as the customer types. On an error, the border changes color. No explanatory message appears.

That creates two separate problems. First, an instruction that disappears is difficult to consult while editing. Second, color alone does not tell someone what to fix.

The W3C forms tutorial recommends appropriate labels associated with form controls, typically using a visible HTML label whose for value matches an input's id. Placeholder text is not a dependable substitute for an actual label. WCAG 2.2, 1.4.1 also says color must not be the only visual means of communicating information.

A stronger design retains the field name, presents a specific error in text, and makes the relationship between the message and its input understandable to assistive technology. Rather than “Invalid input,” the interface can say: “Enter an email address such as name@example.com.” If the customer entered other correct information, don't casually erase it just because this one field failed.

The point is not that every form needs more text. It is that the essential information must remain available when the user needs it. W3C's form guidance treats labels, instructions, validation, and feedback as parts of one interaction.

The third failure: brand colors replace legibility

Accessibility does not require abandoning a strong visual identity. It requires choosing color relationships with enough contrast and ensuring that meaning survives without color cues.

Under WCAG 2.2, 1.4.3, normal text generally needs a contrast ratio of at least 4.5:1 for Level AA, while qualifying large text needs at least 3:1. Non-text contrast, 1.4.11, requires at least 3:1 for certain visual information needed to identify controls, states, or graphical meaning. These rules have specific exemptions and scope; a single successful color ratio is never a certificate of page accessibility.

Here is a useful example from GoodScool's own editorial palette. The values below are calculated from the specified hexadecimal colors using WCAG's relative-luminance formula for opaque, flat-color combinations, not measurements from a deployed page.

This creates a clear design rule: use white text on electric blue and black text on electric lime when those surfaces carry ordinary interface copy. Lime can still be used on white as decoration or a large background element, but it should not be the sole meaningful visual cue or small, readable text there.

The answer is not “use fewer colors.” It is assign each color a job it can do reliably. A striking palette and an accessible interface are compatible, but the pairing matters as much as the swatch.

The fourth failure: the layout survives desktop, but not enlargement

Responsive design is often evaluated at familiar mobile widths. Accessibility adds a different question: what happens when someone enlarges the content because the original presentation is hard to read?

WCAG 2.2, 1.4.4 generally requires text to be resizable up to 200% without loss of content or functionality, subject to its exceptions. 1.4.10 Reflow generally requires content to work at a width equivalent to 320 CSS pixels without two-dimensional scrolling, except for content that genuinely requires it.

A two-column checkout that reflows into a single column may be fine. A sticky header that consumes most of the zoomed viewport, clips the error summary, or traps the next action is not. Responsive design should preserve the sequence of decisions, not merely squeeze all the components onto a smaller canvas.

And don't overlook content. Meaningful headings should be actual headings in the page structure. The text alternative for an image should communicate the image's purpose in that context; W3C distinguishes informative, functional, and decorative images. A decorative flourish usually needs empty alternative text, while an icon-only action needs an accessible name that describes what it does. Beautifully typeset text inside an image should not replace real page text when that text needs to be read, resized, or searched.

A better design review follows the task

REVIEW THE WHOLE TASKA polished screen still needs a usable journey.

The most useful improvement is not another accessibility checkbox at the end of the handoff. It is a review in which the team attempts to complete one consequential task using different interaction conditions.

For the fictional enrollment flow, a designer, engineer, and product owner could use this task review:

This is a proposed GoodScool review exercise, not a full WCAG conformance test or a scientifically validated checklist. Real evaluation also needs appropriate browsers, assistive technologies, trained judgment, and—where possible—participation from people with disabilities. One designer borrowing a screen reader for a few minutes is not a substitute for that work.

Automated tools are valuable, but W3C explicitly cautions that they cannot test every aspect of accessibility or determine overall accessibility on their own. A report with zero detected violations means the tool did not flag violations in its checks. It does not mean the experience has no barriers.

That distinction matters for product teams. A dashboard can report a clean scan while the purchase button is unreachable. Both facts can be true.

Accessibility changes what “done” means

It may take more effort to repair a deeply inaccessible product than to make accessibility decisions early. But neither cost nor compliance can responsibly be reduced to a universal promise. Complex workflows, custom components, content, and assistive-technology behavior all affect the work required.

The better business question is not “How cheaply can we pass accessibility?” It is: “What user task are we claiming our product supports, and who will be unable to complete it if our assumptions are wrong?” That question is relevant to a course platform, a bank, a booking service, a government form, and almost anything else that asks people to act.

Go back to the opening enrollment screen. The design wasn't wrong because it looked polished. It was unfinished because important parts of the experience existed only for one way of seeing and operating it.

Apply it: Take one critical flow in your product. Start from the first action, deliberately trigger an error, and reach the final confirmation without a mouse. Repeat with enlarged text and appropriate assistive-technology checks. Record the first place where you can no longer confidently answer “Can the person continue?” Fix that obstacle before adding another visual flourish.

Accessibility is not the extra layer you add after the design. It is part of the evidence that the design works.