Site 235 · Industry demo · NDIS provider

How Jacaranda Support Co. was designed & built

Jacaranda Support Co. is a fictional registered NDIS provider based in Cannington, serving Perth's south-east. The page has one job — earn a referral or enquiry from a participant, family member, or coordinator — and one argument: on a page for a disability support provider, the accessibility is the product demonstration. Every craft decision below serves that.

The concept

Most provider websites talk about participants in brochure language. This one talks to them: plain words first, NDIS category names quietly second, no inspiration framing, no stock-photo hand-holding. The signature Support Week Planner treats the participant as the person who decides what their week looks like — which is precisely the promise the copy makes.

Palette — the street in November

• Warm paperbark#F6F1E8 — ground. Softer than white for low-vision glare; the bark, not the clinic.
• Deep jacaranda#4A3D6B — structure and every line of body ink. 8.5:1 on paperbark — AAA for normal-size text, measured, not hoped.
• Bloom lilac#9B87C4 — LINE/MARK only: week-grid fills, eyebrow dashes, the river, the tree. It never sets a word of body copy (it fails contrast, so it isn't allowed to try).
• Grevillea#C25E4C — CTA warmth, active chips, and the 3px focus ring. Button text sits on it only at bold 18px+, where its 4.2:1 clears the large-text bar.

The week-grid blocks use a small derived family — deep jacaranda, mid-lilac #6C57A0, bloom lilac, and a muted grevillea #B0523F — one tone per support type, so the grid reads like the jacaranda canopy against paperbark. In-block labels only appear on blocks tall enough to hold them, and only at desktop scale where they render legibly; the real record of the week is the plain-text list beside the grid.

Type — the argument is the typeface

Atkinson Hyperlegible (body, UI) was designed by the Braille Institute for low-vision readers: b/d/p/q are not mirror copies of each other, 0 is slashed against O, 1/l/I are unambiguous, and counterforms stay open at small sizes. On this site, choosing it is the brand argument — a provider that says "we design for access" and then sets its body copy in a face literally engineered for it. Body is 18px minimum everywhere, 1.65 line height.

Zilla Slab (display) brings the warmth: a slab with soft shoulders, set at regular width and never condensed — confident without shouting. Together: a warm, legible page that feels like a person talking, not a compliance document.

The signature — Support Week Planner

Four plain-language support chips (each with its NDIS category named quietly beneath), an hours-per-week stepper, and a procedural SVG week grid built at runtime: the chosen hours are split across the selected supports, each support claims its characteristic slots (morning routine Tuesdays, swimming Thursdays, cooking program Saturdays), and colour blocks settle into a Monday–Sunday grid with a staggered left-to-right sweep. Beneath it, an honest funding line computes live: hours × $67.56 = the weekly figure, always labelled as the standard weekday daytime rate, hedged against the current price guide — the copy even admits a Saturday cooking program would cost more than the simplified maths shows. "Use this plan in my enquiry" copies supports + hours into the referral form, so the demo interaction becomes a warmer lead.

The second-read detail: a voice toggle. "This plan is for: Me / Someone I support" switches the whole planner between participant voice ("Plan my week… from my plan") and coordinator voice ("Plan a participant's week… from the participant's plan") — the page practises the talk-to-not-about rule it preaches.

Everything is a real <button>: chips (aria-pressed), stepper, voice toggle, hand-off. The whole planner drives from a keyboard with no custom key handling to get wrong. The SVG grid is aria-hidden and duplicated as a plain-text week list; the funding line and stepper readout are aria-live="polite". Under prefers-reduced-motion the grid renders settled and complete — no sweep, no pulse, nothing withheld.

Accessibility floor (above the collection baseline)

• Body copy 18px minimum, AAA contrast (8.5:1 ink on paperbark), measured with the WCAG relative-luminance formula before a line was written.
• 3px grevillea :focus-visible rings with 2px offset, on everything focusable.
• Tap targets ≥48px: chips, steppers, FAQ summaries, sticky-bar links, checkboxes' rows, footer links on mobile.
• Every interactive element labelled; icon-only controls carry aria-label; form errors are plain sentences that explain why we ask ("your suburb tells us whether we can staff your supports reliably"), wired via aria-describedby and aria-invalid.
• FAQ uses native details/summary — keyboard and screen-reader behaviour for free.
• Skip link, landmark structure, one real h1, and a no-JS-safe load: content is visible before scripts run, and the intro fade only arms after the JS class lands.

Conversion decisions

• Above the fold at 375px: name, trade + area in the h1, enquiry CTA, and the provider-registration trust line — plus the sticky call/enquire bar (each target ≥48px). On mobile the header CTA is dropped in favour of the sticky bar, so there's exactly one obvious path, twice.
• Planner before services: the signature is the qualification step — a visitor who has built a week is a warmer enquiry, and the hand-off pre-fills the form to prove the site was listening.
• "Who is this enquiry for?" as a required select — coordinators and plan managers are half the referral traffic for a real provider, and the first call is pitched differently for each.
• Local confirmation, honestly local: submit validates in the browser and renders a designed confirmation ("Thanks — your enquiry has been received… we'd be in touch within one business day") that states plainly nothing was sent — no fake network round-trip, no spinner theatre.
• The conflict-of-interest card: "We don't offer support coordination — that's a conflict" is the strongest trust signal on the page precisely because it declines revenue.

Techniques

No libraries. All visuals are procedural SVG: the hero jacaranda (blossom-cluster circles over an ink branch armature), the service-area map (river, highways, seventeen suburb marks), and the week grid — built element-by-element in vanilla JS with createElementNS. The settle animation is CSS transitions on the SVG <g> blocks with per-block transition-delay, sorted Monday→Sunday so the week sweeps in reading order; the funding total pulses once per change with a small spring cubic-bezier. A state probe (window.__ndis: supports, per-support split, hours, voice, weekly figure, form status) updates on every interaction so the page can be verified against an independent oracle rather than against itself.

Honest numbers

$67.56/hr is the standard weekday-daytime anchor used on all four surfaces (planner, two service cards, FAQ), always hedged as "at or below the current NDIS price-guide cap" because that figure is set by an external authority and moves. The planner declares its simplification — every hour priced at the weekday rate — and names the exception it creates (a Saturday program would cost more). Transport is "the per-km guide rate, agreed in writing", never a hard number. Verification re-implemented the rate maths in separate harness code: 9 hrs → $608.04 and 14 hrs → $945.84, both asserted against the rendered line, not the page's own function.

Local SEO we'd implement for the real business

This demo intentionally ships only WebPage schema naming it a demonstration — fictional LocalBusiness or Review markup in a real search index would be dishonest. For a real provider, we'd ship:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Jacaranda Support Co.",
  "description": "Registered NDIS provider — support work at home and
    in the community across Perth's south-east.",
  "telephone": "+61-8-XXXX-XXXX",
  "url": "https://www.example.com.au",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Cannington",
    "addressRegion": "WA",
    "postalCode": "6107",
    "addressCountry": "AU"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": -32.017, "longitude": 115.934 },
  "areaServed": ["Cannington","Bentley","Wilson","Beckenham","Queens Park",
    "East Cannington","Ferndale","Lynwood","Langford","Thornlie","Gosnells",
    "Maddington","Kenwick","Riverton","Shelley","Willetton","St James",
    "Victoria Park"],
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "08:30", "closes": "17:00"
  }],
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "Real client, with consent" },
    "reviewRating": { "@type": "Rating", "ratingValue": "5" },
    "reviewBody": "Genuine review text, imported from Google with permission."
  }],
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "38"
  }
}
</script>

Plus: a Google Business Profile tuned for "NDIS provider Cannington / support workers Perth south east", suburb-level service pages for the high-intent corridors, and FAQ schema on the genuine questions.

What would change for the real client

• Rostering & care management: the enquiry form would land in their intake pipeline — ShiftCare, Splose, SupportAbility or Brevity depending on their stack — with the planner's supports + hours attached as structured data, not free text.
• Claiming: rates and invoices reconciled against PRODA/PACE claiming; the price-guide anchors on the page generated from the same rate table the claims run on, so the website can never argue with the invoice.
• Real registration: their actual NDIS registration number and ABN replacing the placeholder patterns; real worker-screening and insurance references.
• Real people: photography with participant consent, reviews imported with permission, and staff bios — the procedural jacaranda stays as the brand system around them.
• Compliance content: service agreements, complaints and incident policies, easy-read document versions — the NDIS Commission expects them, and participants deserve them.

Iteration log