Building an Accessible Tire Comparison Interface

KMJ brand artwork. The interface described below is a design exercise, not an existing KMJ application.

A tire comparison page is a small information system with unusually expensive misunderstandings. A driver can confuse a load index with a weight, mistake an unexplained dash for a negative result, or lose the identity of a product while scrolling sideways. Making the buttons larger helps, but the deeper engineering problem is preserving meaning as someone moves between products, input methods, and levels of detail.

This article is a frontend design exercise, not a description of KMJ Tire's live infrastructure. Every product label, dataset, interface state, and numeric example below is illustrative. No example represents current pricing, availability, a tested tire recommendation, or an actual customer incident. The practical setting is Calgary: drivers comparing seasonal options for Deerfoot commutes, Stoney Trail travel, and trips west on Highway 1.

The implementation goal is specific: help a reader inspect differences without silently turning a comparison into a fitment approval. We will build from semantic HTML, add restrained interaction, and define tests for the difficult transitions. The result is a design you can adapt, not a completed accessibility audit or a promise that a particular implementation meets every requirement.

Begin with the decision, not the product card

Before choosing a component library, write down what the page must let someone learn. For this exercise, the reader needs to identify the selected options, distinguish category labels, find an explanation of technical markings, and understand which information remains unverified. Buying is not part of the prototype. That narrower boundary makes it possible to evaluate comprehension instead of treating every click as progress.

Imagine a person enlarging text while comparing two options on a phone. Their problem is not a shortage of product imagery. They need to retain the connection between a property and the option it describes. Another reader may listen to the same content through a screen reader and navigate by headings. A third may use only a keyboard because precise pointer movement is difficult. These are different navigation paths through one decision, not separate audiences requiring separate truth.

Write three task statements on the design brief. First, identify whether a category description refers to seasonal use or vehicle compatibility. Second, locate the meaning of a displayed sidewall marking. Third, explain why a missing value cannot be used as evidence that two options are equivalent. None requires a purchase funnel, personalization engine, or ranking algorithm.

For editorial context, KMJ's guide to making an informed tire purchase in Calgary is a sensible reference destination. In the interface, place such help beside a decision where it is useful. Do not make readers navigate away simply to learn what the page expects them to compare.

Define a small presentation contract

The view model should distinguish a display label from its underlying meaning. Even a prototype benefits from an explicit type for missing information. A blank string is not sufficient: it cannot tell the component whether a value is unavailable, not relevant, or awaiting verification. Those states deserve different visible language because they lead to different interpretations.

type DisplayValue =
  | { state: "known"; text: string }
  | { state: "unverified"; explanation: string }
  | { state: "notApplicable"; explanation: string };

type ComparisonOption = {
  id: string;
  label: string;
  category: DisplayValue;
  loadIndex: DisplayValue;
};

const sample: ComparisonOption = {
  id: "example-a",
  label: "Illustrative option A",
  category: { state: "known", text: "Winter category" },
  loadIndex: {
    state: "unverified",
    explanation: "Not verified for this exercise"
  }
};

This contract does not validate a real tire. It limits the ways the interface can accidentally imply certainty. A renderer should exhaustively handle the union rather than convert every non-known value to an em dash. If an additional state is introduced later, a type-level failure is more useful than a silent placeholder that changes the meaning of the page.

Keep identity stable across sorting, filtering, and removal. Use the option identifier as the rendering key, not the current array position. Otherwise a component may retain expanded state or focus-related state from the wrong product after the order changes. That is a general frontend concern with a very concrete consequence here: an explanation could remain open beside a different option.

A presentation contract also gives content editors a review surface. They can inspect the literal strings for uncertainty without reading rendering code. The phrase “not verified” should not gradually become “not required” because two components were implemented independently.

Use a real table for genuinely tabular information

When the core task is comparing the same properties across options, a table expresses the relationship directly. A layout composed of visually aligned cards may look equivalent while losing row and column associations. W3C's tables tutorial explains the relationship between header cells, data cells, and programmatic structure. That structure is the starting point, not decoration added after the layout is finished.

<table>
  <caption>Illustrative category comparison; fitment not verified</caption>
  <thead>
    <tr>
      <th scope="col">Property</th>
      <th scope="col">Option A</th>
      <th scope="col">Option B</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Category label</th>
      <td>Winter category</td>
      <td>All-weather category</td>
    </tr>
    <tr>
      <th scope="row">Vehicle suitability</th>
      <td>Not verified</td>
      <td>Not verified</td>
    </tr>
  </tbody>
</table>

The caption identifies the example and its limit. Column headers identify options; row headers identify properties. A person moving through data cells should not have to remember which product occupied the left side several gestures earlier. Keep the first implementation simple enough that its associations are easy to inspect.

Avoid merging cells merely to achieve a cleaner-looking grid. Grouped headings can be appropriate, but they increase the work required to understand and test the structure. If category, size, and uncertainty fit in a straightforward matrix, elaborate spanning headers offer little benefit.

Also resist replacing table semantics with a grid role merely because a design file uses the word grid. An interactive grid carries a different keyboard interaction model. Ordinary links and controls can exist inside a native table without turning every cell into a focus stop. Let document navigation handle the information and reserve the keyboard sequence for actions.

Make units part of the meaning

A heading that says “Width” without units places interpretation work on the reader. A heading that says “Load” beside an index can be worse: it encourages treating an encoded value as a physical quantity. The view should present a property name, its unit where applicable, and the kind of value being shown.

For a simple dimension, a heading such as “Section width, millimetres” is more explicit than a bare abbreviation. A compact visible label can still work if the expanded meaning is readily available. The important point is consistency: do not require someone to infer that one number is millimetres while a nearby number uses inches.

A load index needs a label identifying it as an index. Do not attach a mass unit directly to that code. If a separate capacity explanation is displayed, its source, conditions, and relationship to the index need their own treatment. For this exercise, leaving the capacity conversion out is a deliberate scope decision, not a missing feature.

Place an explanation link near the relevant row, such as understanding a tire load index. The link supports interpretation; it does not certify that the displayed option satisfies a vehicle's requirements. Likewise, reading tire sidewall information provides a useful destination for readers encountering unfamiliar markings.

Formatting belongs in a shared presenter. If one component renders “mm,” another spells “millimetres,” and a third omits the unit in compact mode, those choices should be intentional and reviewed. Accessibility defects often start as small inconsistencies that become impossible to track once every card formats its own values.

Separate category education from compatibility claims

A Calgary reader might compare winter, all-weather, and all-season categories because their route changes throughout the year. The page can explain those terms without deciding which tire fits a specific vehicle. Keep that distinction visible in the layout: category is one row; vehicle suitability is another; verification status is a third concern.

A colour-coded “best” badge collapses several unanswered questions. Best for which vehicle, conditions, usage, and evidence? In this exercise, use neutral labels describing what the data actually contains. If the dataset only identifies a category, display that category. Do not elevate it into a suitability verdict because the design needs an accent colour.

Provide contextual education at the point of confusion. A reader examining the winter column could use Calgary winter tire guidance. Someone trying to understand the neighbouring category can follow an explanation of all-weather tires. A separate reference for all-season tire terminology completes that comparison without merging the categories into a marketing score.

Local context belongs in the surrounding explanation rather than an invented performance figure. Chinooks and large day-night temperature swings explain why seasonal terminology matters to a Calgary audience. They do not justify a made-up stopping-distance chart or a claim that one illustrative option will handle a specific icy interchange.

A useful content review question is whether the interface could be mistaken for approval. Ask a reviewer to point to the evidence supporting every positive badge. When no evidence exists, change the presentation rather than adding a tiny disclaimer beneath an authoritative-looking score.

Keep keyboard order predictable

The simplest reliable keyboard model is usually the document order. A reader moves through filters, help controls, product actions, and subsequent content in a sequence that matches the visual arrangement. Avoid positive tabindex values. They create a second ordering system that becomes difficult to maintain as components appear and disappear.

Product removal is a good place to find hidden complexity. Suppose the focus is on “Remove option B,” and activating it deletes that button. The implementation must decide what receives focus next. Leaving the browser to improvise can move the user somewhere surprising, particularly if the removed control was inside a large dynamically rendered section.

Define a fallback sequence in the interaction specification. If another removal control occupies the same logical position, focus it. Otherwise use the preceding remaining option action. If the comparison is empty, move to a stable heading or the control used to add an option. A heading intended for programmatic focus can use tabindex="-1" without joining the normal Tab sequence.

Do not move focus simply because someone changes a filter. When the triggering control remains valid, keeping focus there usually supports continued adjustment. Announce the resulting count separately. The reader can then decide whether to explore the updated comparison or modify another setting.

Test the reverse direction as carefully as the forward direction. Shift+Tab should not enter a hidden panel, vanish beneath a sticky element, or land on duplicated mobile markup. Keyboard testing is not complete after demonstrating that the first button responds to Enter.

Preserve focus through reactive updates

Framework rendering does not remove the need for a focus policy. A state update can replace the focused DOM node even when the screen appears unchanged. Sorting is particularly revealing: if keys reflect positions, the option name, button label, and component state can become misaligned.

Treat focus restoration as part of the state transition rather than an unrelated visual effect. Capture the meaningful destination before updating the list, let the framework finish rendering, and then locate the surviving control by a stable identifier. Do not retain a reference to a deleted node and assume it remains usable.

The destination should be based on the action's meaning. Removing an option suggests a nearby option control. Opening additional information suggests the disclosure remains the anchor. Submitting an invalid filter may require a clear path to the erroneous input. One generic “focus the top of the page” helper is unlikely to respect all three situations.

Avoid automatically focusing status text. That interrupts navigation and can produce duplicate speech when the same message also belongs to a live region. Focus and announcement are separate mechanisms: one changes where the user is; the other reports information while allowing the current position to remain stable.

For regression notes, write observable outcomes rather than framework details. “After removing the final option, the add-option control receives focus” is testable across implementations. “The effect hook runs” does not establish that a person can continue their task.

Use text alongside colour and icons

A green cell and a red cell do not explain the difference between confirmed data, missing data, and incompatibility. Those are different states, and colour alone cannot carry them. Start with a visible text label. Add an icon or colour treatment only if it reinforces information already available in words.

The illustrative interface might use “Value available,” “Not verified,” and “Not applicable.” An icon next to each can make scanning easier, but repeating its accessible name beside the same visible text can become noisy. If the icon is decorative reinforcement, hide it from assistive technology while retaining the real label.

Difference highlighting needs similar restraint. Shading a row may show that values differ, but the row should also include a clear indication of the difference or a control label explaining what the current view includes. A person using a monochrome display or forced-colours mode still needs to understand the state.

Text should also avoid visual idioms such as “choose the green option.” Refer to the option's name or property instead. That improves instructions for everyone, including a reader hearing the content without seeing it.

In a Calgary tire context, the temptation to borrow road-signal colours is strong. Resist translating yellow into a vague caution state unless the words explain exactly what is uncertain. “Load index not provided in this example” is actionable information. A yellow triangle with a tooltip is an interpretation puzzle.

Offer details without hiding essential limits

Progressive disclosure can make a comparison easier to scan when it hides secondary explanations. It becomes harmful when it hides the conditions needed to interpret the summary. Keep uncertainty, units, and the fact that compatibility is unverified in the primary content. Longer educational definitions can live behind a disclosure.

A native details element is a useful starting point for a simple expandable explanation. If a custom component is necessary, W3C's disclosure pattern describes a button with an expanded state and an associated content region. Prefer an established pattern over inventing keyboard behaviour for a clickable paragraph.

<details>
  <summary>What does this category label describe?</summary>
  <p>
    This label describes the illustrative category, not verified
    suitability for a particular vehicle or journey.
  </p>
</details>

The summary should answer “what will open?” rather than saying only “More.” A page containing several identical “More” controls forces readers to infer context repeatedly. Specific wording also helps when assistive technology presents controls as a separate list.

Do not move expanded content to an unrelated location in the DOM for visual convenience. The explanation should follow its trigger in reading order unless a different established interaction pattern is being used. Check that collapsing the panel cannot strand focus inside content that is now hidden.

For deeper seasonal workflow education, a contextual reference to seasonal tire changes belongs in a relevant explanation panel. It should not masquerade as a required step in the technical comparison. The reader is exploring information, and the interface should preserve that freedom.

Announce outcomes, not every render

Dynamic filtering creates a communication problem: the comparison changes while focus remains on a control elsewhere. A concise status message can explain the result without forcing navigation. The message should describe a meaningful outcome, such as the number of illustrative options remaining, rather than narrate every internal state update.

W3C's guidance on status messages distinguishes these updates from changes that move the user's context. For the prototype, create the status region in the initial markup and update its text when a completed action changes the result. Do not wrap the entire table in a live region.

<p id="comparison-status" role="status" aria-atomic="true"></p>

function describeResult(count) {
  return count === 1
    ? "1 illustrative option remains."
    : `${count} illustrative options remain.`;
}

function updateResultMessage(count) {
  document.getElementById("comparison-status").textContent =
    describeResult(count);
}

This fragment only demonstrates message construction and placement. A real component must integrate it with completed updates and test the chosen browser and assistive-technology combinations. Timing, repeated identical text, and rapid updates can affect what is actually announced.

A burst of changes from a text filter may need debouncing or an explicit Apply button. The product decision depends on whether instant updates genuinely help the task. A quieter interface is often easier to understand than one that reads a new count for every keystroke.

Errors deserve equally precise language. “Unable to update the example; previous results remain visible” tells the reader what happened and which content is still present. “Something went wrong” provides neither orientation nor a reasonable next step.

Adapt the comparison to narrow viewports

A wide table does not automatically become usable when placed inside an overflow container. The surrounding page must still reflow, controls must remain reachable, and the horizontal movement must be discoverable. W3C's reflow explanation discusses two-dimensional content such as data tables while preserving requirements for surrounding material.

For this prototype, begin by limiting the number of simultaneously compared options. That is a product constraint, not an accessibility cure, but it reduces complexity. Let row labels wrap. Avoid a rigid minimum width large enough to force sideways movement through every ordinary paragraph on the page.

If horizontal scrolling remains necessary, provide a visible cue that more columns exist. Verify keyboard access to the scrollable region in the target browsers; do not assume every browser exposes overflow in the same way. A region that receives focus should have a clear name and a visible focus indicator, without adding unnecessary stops to an already simple layout.

An alternative compact representation can work if it preserves relationships. For example, a stacked option summary can repeat property labels beside values. But maintaining both table and card DOM trees risks duplicate content, duplicate identifiers, and controls that remain focusable while visually hidden. Prefer one well-tested representation unless the additional complexity solves a demonstrated problem.

At high zoom, sticky columns deserve scrutiny. A frozen property column can consume nearly all the visible width. The feature that helped at desktop scale can make the actual values inaccessible on a narrow viewport. Test the available reading area rather than judging a screenshot at a comfortable default size.

Design the empty and uncertain states first

An empty comparison is a normal state, not an error. Explain how to add illustrative options and preserve the page's educational context. A no-results state after filtering is different: there were options, but none currently satisfy the selected presentation filters. Those messages should not share a generic empty illustration and no useful text.

Uncertain values are more subtle. Suppose option A has a visible load index while option B is marked unverified. Sorting unknown values as zero can place B first and make it look like a meaningful minimum. A display sort must preserve missingness, and its label should explain any unusual ordering.

Likewise, a “show differences” filter must define how it treats unknown values. Are two unverified fields considered equal? Visually hiding the row could imply that the options share a confirmed specification. For this exercise, keep rows with unresolved values visible and explain that they cannot be compared conclusively.

The same principle applies to imagery. An absent product image is not evidence of an absent product, and a generic tire photograph is not evidence of a specific model's details. Use a neutral placeholder with appropriate text. Do not fabricate a tread picture to fill a content gap.

General driver education such as practical tire-care basics can remain available outside the result region. That gives an empty page continuing value without claiming to solve the missing data. Useful help and truthful uncertainty can coexist.

Keep illustrations honest and alternative text purposeful

A hero image can establish the subject, but it must not be the only place where the comparison's distinctions appear. If a diagram contains the meaningful labels, provide those relationships in actual text as well. An image of a table is a poor substitute for the semantic table the tutorial has carefully designed.

Write alternative text according to the image's role. A purely decorative tread photograph may need empty alternative text within a functioning interface. A diagram demonstrating the arrangement of a property row and option columns needs a concise description of that arrangement. A detailed screenshot used to explain a defect may need nearby prose covering what the reader should notice.

Do not write “real KMJ customer comparison” unless that is actually established. For this design exercise, label custom visual examples as illustrative. Generic images should not imply a particular product, inventory position, completed installation, or software feature currently operated by the business.

The article's code and example labels remain understandable without the hero. That is a useful editorial test: remove every image and ask whether the technical instruction still works. Then restore them and ask what each adds. If the answer is only “it fills space,” the image probably needs a different role or removal.

Image captions and alternative text serve different readers and may overlap, but they need not repeat each other mechanically. A caption can identify an illustration's purpose while alternative text communicates the visual information required in context.

Build a task-based test matrix

Automated accessibility checks are valuable for detectable structural defects, but they cannot establish that someone correctly understands a comparison. Pair them with a small set of task-based checks. Each task should define a starting state, an action, and an observable result without assuming a particular assistive technology speaks identical words.

One task begins with two selected options. Using only the keyboard, remove the second and continue to the remaining option's explanation. The pass condition includes both the correct data and a sensible focus destination. A successful state mutation with focus lost to the document body is not sufficient.

Another task begins with an unresolved specification. Ask the tester to explain whether the two options have the same confirmed value. The answer should be that the comparison does not establish equality. If the interface encourages a confident but unsupported answer, improve the labels or layout before tuning colours.

A third task uses enlarged text and a narrow viewport. The tester must identify which option owns a value after horizontal movement. Record whether the table headers, visual presentation, and reading sequence preserve that relationship. Avoid turning the exercise into a speed contest.

A fourth task changes a filter and then returns to it. Observe the status announcement, focus retention, and visible count. The interface should not force the tester through the entire updated table to learn that nothing remains.

Write findings in concrete language: “The second option label disappeared behind the sticky property column at the tested zoom setting.” That gives the developer something reproducible. “Mobile accessibility feels off” does not.

Inspect structure with developer tools

The accessibility tree is a useful debugging view because it reveals some of what the browser exposes beyond pixels. Inspect the table's role, caption, headers, and control names. Compare that representation with the intended relationships. A visually prominent heading that is actually an unlabelled generic container may explain a navigation problem immediately.

Check accessible names after localization and responsive changes. A remove control should identify its target even when the product name is visually truncated. Conversely, avoid stuffing a control's name with every specification; overly long names make repeated navigation exhausting.

Inspect hidden states too. A visually collapsed panel should not leave active controls in the keyboard sequence. A mobile-only duplicate should not contribute another identical heading or button when it is supposedly absent. CSS decisions can alter accessibility exposure in ways that deserve direct verification.

Network throttling can expose a different class of defect. If the example simulates delayed results, determine what remains on screen while loading and what the status message says. Replacing content with a blank region removes context. Keeping old content without indicating that it is old can mislead. The loading design needs an explicit choice.

None of these observations replaces testing with assistive technology. Developer tools help explain why something happens; real navigation confirms the experience. Use both, and save the relevant browser, operating-system, and assistive-technology versions with findings so another developer can reproduce them.

Write integration assertions around user outcomes

A useful automated test does more than check that a component exists. It verifies relationships and transitions that are easy to break during refactoring. For example, inspect that each data row includes its property header, that every removal control names the correct option, and that known and unverified states use distinguishable text.

For focus behaviour, simulate removing an option and inspect the active element after rendering completes. Use stable semantic queries wherever possible. A test coupled to a framework's generated class names may break during harmless styling work while missing an actual usability regression.

Status tests should verify the intended message after a completed change, not assume that a DOM assertion proves an announcement was heard. That distinction belongs in the test documentation. The automated layer establishes the conditions; a manual assistive-technology pass checks delivery.

Include a failure-path assertion. If an update fails, confirm that the previous comparison remains identifiable and that the error message explains the situation. A happy-path-only suite often misses the exact moment when a user most needs clear orientation.

Keep the example dataset small enough to understand by inspection. Three illustrative options can exercise removal from the beginning, middle, and end. Unknown values can exercise difference filtering without requiring hundreds of synthetic products. The aim is coverage of meaningful states, not an impressive row count.

Avoid claiming that a green test run certifies accessibility. It shows that the checked behaviours passed under the specified conditions. That is useful evidence, and its value increases when its limits are stated clearly.

Review the words as part of the interface

Content review is engineering work here. A technically valid table can still communicate an unsafe conclusion if its labels are vague. Review headings, empty states, button names, help text, and status strings together rather than treating them as unrelated copy tasks.

Look particularly closely at words such as “recommended,” “approved,” and “compatible.” Each implies evidence beyond simple display. If the prototype has not performed the relevant verification, use language that describes its actual function: selected, compared, shown, unresolved. Plain words are easier to maintain than a disclaimer trying to undo an overconfident badge.

Keep service education separate from product properties. A reference to wheel balancing information can explain a related tire-service concept, but it does not belong as a made-up performance advantage in one option's column. Similarly, tire repair guidance is a help destination, not a promise that any damage shown in a hypothetical example is repairable.

KMJ Tire's scope in this article is tire services and oil changes. The interface exercise does not imply mechanical inspection, alignment, brake work, or other mechanical services. If a real reader describes a concern outside that scope, appropriate professional assessment elsewhere remains separate from this comparison component.

Read the screen aloud once without looking at the design. Repeated labels, ambiguous pronouns, and unexplained abbreviations become easier to notice. Then inspect the compact layout to ensure the corrected wording still fits without being silently truncated into something less clear.

Plan a humane usability session

A short usability session should investigate comprehension without asking participants to prove the interface is good. Give a scenario, not a sequence of clicks. For example: “You are comparing these illustrative options for a Calgary commute. Find which information is confirmed and which information still needs verification.” Then observe how the person explores.

Do not ask someone to disclose a disability or justify their preferred input method. Let participants use familiar tools where practical, explain what will be recorded, and obtain appropriate consent before recording. The goal is to understand interaction barriers, not collect unnecessary personal information.

Separate difficulty caused by the prototype from uncertainty about tire terminology. Both matter, but the remedy differs. If the reader cannot find the explanation, improve navigation. If the explanation is easy to find but incomprehensible, revise the content. If the page appears to approve a vehicle fitment, change the decision model.

Record qualitative observations with restraint. This article reports no actual study, measured completion rate, or customer feedback. In a real evaluation, distinguish direct observations from the researcher's interpretation and avoid generalizing from a handful of sessions into unsupported universal claims.

After revisions, revisit the original task rather than inventing a friendlier one. An interface that only succeeds when the facilitator explains its labels has not solved the problem. The strongest result is independent understanding of both the information and its limits.

Treat localization as a structural test

Longer translated labels and different number formatting expose layout assumptions that short English sample text can hide. Even if the first release uses one language, make the component tolerate longer property names without overlapping the adjacent value. A fixed-height row that looks tidy in a mockup can clip the very explanation that makes a number understandable.

Keep complete messages together in the translation layer. Constructing a sentence from scattered fragments makes word order difficult to change and can produce awkward announcements. The result count example is intentionally small, but a real localization implementation should use the application's established pluralization mechanism rather than assuming every language follows the same singular and plural pattern.

Product identifiers and display labels need different treatment. An internal identifier remains stable even when the visible name changes. That distinction prevents translated text from becoming a fragile lookup key for focus restoration or selection state. It also makes it easier to compare a screenshot with a bug report without exposing private data.

Directionality deserves an explicit test if the supported languages require it. Row identity should not depend on instructions such as “the tire on the left.” Logical CSS properties can help a layout adapt, but they do not automatically repair ambiguous wording or a hard-coded icon direction. Test meaning as well as alignment.

For units, decide whether localization changes the displayed unit, its formatting, or only the explanatory language. Those are separate choices. Never convert an encoded tire marking merely because a locale formatter is available. A formatting helper should not quietly become a domain conversion engine.

Make a saved comparison intelligible outside the session

Readers may print a comparison or save it for later discussion. The resulting document should retain the option identities, explanatory labels, and uncertainty statements. A print stylesheet that removes every secondary-looking paragraph can accidentally remove the only text explaining that the examples are illustrative and vehicle suitability is unverified.

Expand essential context for print rather than relying on interactive disclosures that no longer work on paper. Decide which optional explanations belong in the output, and test an actual print preview. Do not assume that a browser will reveal collapsed content in the desired form. Include a clear document title so a saved file is distinguishable from unrelated information.

A saved snapshot can become stale. If the interface uses real changing information in a future implementation, its export design will need an honest observation date and appropriate provenance. This tutorial does not introduce those live data sources, so its export should simply preserve the demonstration label instead of fabricating a refresh timestamp that suggests operational authority.

Avoid embedding unnecessary personal details in filenames or shared URLs. A comparison of illustrative options does not need a driver's identity. Shareable state should contain only what the feature genuinely requires, and any later expansion into private information deserves its own design review.

Finally, inspect the saved version at ordinary reading size. Column labels that are clear on a wide monitor can become tiny when a browser shrinks the entire table onto one sheet. A good on-screen experience is not proof of a good export; the second format needs its own check.

Ship a comparison that remains understandable

The finished design exercise has a modest ambition: preserve relationships, expose uncertainty, and let people navigate without fighting the interface. Semantic tables hold the comparison together. Clear units and category labels prevent avoidable confusion. Stable focus and restrained announcements make updates understandable. Details remain available without concealing the conditions that matter.

For Calgary drivers, those choices connect frontend engineering to an ordinary task: making sense of tire information while planning seasonal changes or highway travel. A readable comparison cannot replace vehicle-specific verification or professional judgment. It can make the next conversation better informed by showing exactly what is known and what still needs checking.

Before release, review the narrowest viewport, the largest practical text setting, keyboard-only interaction, unresolved data, and the final-option removal path. Read every positive claim as though a reader might rely on it. Keep the example framing visible if the page remains a demonstration.

Accessibility in this component is not an extra layer of labels attached at the end. It is the structure of the information, the behaviour of each transition, and the discipline to avoid saying more than the data supports. Build those decisions into the first version, and later styling has a much stronger foundation.