A Beautiful Website Can Still Be Impossible to Use

Keep the atmosphere. Remove the obstacle.

A business website should let people understand an offer and act on it in the ways they use the web. For this imagined studio, the useful question is simple: can someone choose a class, reserve two places and know the booking succeeded? A polished homepage only answers part of that question.

Keyboard access matters to people who cannot use a mouse, including some people with mobility or vision disabilities. W3C’s Web Content Accessibility Guidelines, or WCAG, include a requirement for functionality to work through a keyboard interface, with a narrow exception for activities that inherently depend on a movement path, such as freehand drawing. Choosing a class date is an ordinary interaction to support. [1] (opens in a new tab)

The studio can keep its generous spacing, earthy colors and beautiful photography. The work is to make its controls, content and booking sequence function as carefully as they look. This is a practical design review, not a determination of legal compliance.

The customer should always know what happens next

Picture the same customer moving from the class description to available dates. A visible outline tells them which control is selected for keyboard input. They open the calendar, choose Saturday and move on to the number of places. If the outline disappears, even a reachable control becomes difficult to use: the customer cannot see where their next keypress will act. WCAG addresses visible keyboard focus separately from keyboard operation. [2] (opens in a new tab)

For a first check, use Tab and Shift+Tab to move through ordinary links and controls, Enter to activate links, and the appropriate keys for buttons or selectors. A calendar may use arrow keys inside its date grid. Ask the builder to verify the expected interaction; pressing Tab alone is not a complete calendar test. Check browser keyboard-navigation settings if links seem to be skipped. [1] (opens in a new tab) [9] (opens in a new tab)

Continue beyond the calendar. Can the visitor change two places back to one? Can they return to the class details without losing their selection? Does a fixed booking bar cover the control they are trying to use? In a preview or agreed test environment, follow the whole reservation through its confirmation. Avoid placing a real paid booking merely to inspect the design.

Warm colors do not have to mean faint words

Now imagine a different visitor enlarging the class description to read it comfortably. The price remains visible, but the cancellation sentence is cut off inside a fixed-height box. That missing sentence is part of the purchase decision. Text needs room to wrap, and neighboring controls need to move with it.

W3C’s reflow guidance uses a width equivalent to 320 CSS pixels for vertically scrolling content, without losing information or functionality or requiring scrolling in both directions. One example is a 1280-pixel-wide viewport at 400% zoom. There are exceptions for content that genuinely needs two dimensions, such as a map. A class description should generally wrap into a readable column. [3] (opens in a new tab)

Color offers a concrete design choice. In an original calculation using W3C’s contrast formula, muted taupe #A69E94 on warm ivory #F8F5EF produces about 2.43:1. Deepening only the text to warm brown #55483D gives about 8.11:1. Ordinary text under WCAG 2.2’s Level AA contrast criterion needs at least 4.5:1; qualifying large text has a 3:1 threshold. Those example colors illustrate one check, not an assessment of an entire design. [4] (opens in a new tab)

A designer can use the pale taupe for decoration while giving the class price and preparation details a stronger text color. Review the actual page at enlarged sizes, including button labels and error messages. A calm palette and legible information can belong to the same visual system.

A mistake should not end the booking

The customer types an email address but leaves out the @ symbol. A red border appears. Nothing else changes. They know something went wrong, but the page gives them no useful way forward.

A better version keeps the field’s visible label and provides a specific correction nearby: “Enter an email address with an @ symbol.” The underlying code must connect the label and feedback to the right field so assistive technology can identify them. Adding helpful-looking words beside an input is only part of that job. [5] (opens in a new tab) [6] (opens in a new tab)

After a successful reservation, the page should also communicate completion clearly. W3C’s forms guidance covers both error feedback and success messages. In our studio example, a useful confirmation would repeat the chosen class, date and number of places, with the next step for the customer. That is a proposed design, not a claim that a particular booking provider already supports it. [6] (opens in a new tab)

The same thinking applies when a class becomes full during booking. Explain what changed and offer available alternatives. Preserve information the customer can reasonably reuse. A customer recovering from a mistake is still trying to buy; the website should help them continue.

Decide whether to repair the page or replace the component

For the studio owner, the first version of this work can be one complete class reservation. Give the builder a short record of each obstacle: the page, browser, input method, steps taken, expected result and what actually happened. “Saturday cannot be selected with the keyboard” is something a developer can reproduce.

The response depends on who controls the broken part. Text color and clipped copy may be theme changes. A custom calendar may need engineering work. An embedded booking tool may require its supplier to fix the component or provide a better-supported replacement. Before switching providers, check how reservations, payment settings and staff routines would move. The scope is larger than replacing a box on a page.

Ask for a quote that includes the affected components, manual review, retesting and responsibility for future updates. A fixed fee based only on page count misses the difference between a simple class description and an interactive reservation system. No universal price or completion time fits both.

The portfolio’s Vanta Booking project shows the separate parts of a booking business: hosted storefronts, checkout and merchant tools. That is useful context for planning a connected reservation journey. It is not evidence of an accessibility audit or certification, and a proposed change still needs its own testing.

Measure whether people can finish

After the repair, repeat the exact task that exposed the problem. Record whether the date can be selected, whether the selected class remains understandable after an error, and whether confirmation is reachable. Keep unresolved obstacles visible rather than replacing the findings with a single score.

Automated scans can support this work, but W3C says no tool alone can determine whether a site meets accessibility standards. Include knowledgeable manual evaluation. Involve people with disabilities, using relevant assistive technology, to learn how the journey works in practice; one person’s experience does not stand for everyone. [7] (opens in a new tab) [8] (opens in a new tab)

For business measurement, compare completed reservations with booking starts over a sensible period and note requests for help. Use aggregate, privacy-conscious reporting; do not infer a visitor’s disability from their behavior. Small samples, seasonality and changes in advertising can move the numbers, so a higher completion rate alone would not prove the repair caused it.

The most direct evidence is the previously blocked task working in the reviewed conditions. Keep that task in the review whenever the calendar, theme or booking provider changes. A beautiful website earns its place when customers can enjoy the promise in the photographs and actually reserve a seat at the table.