Standards
Cobalt59 works with government and public agencies, whose own digital standards require accessible suppliers. This site is built to meet them.
This site targets WCAG 2.2 Level AA. WCAG — the Web Content Accessibility Guidelines — is the international standard published by the World Wide Web Consortium for making web content usable by people with disability. Level AA is the middle of three conformance levels and the one almost universally adopted in procurement.
It is the level referenced by the Australian Government Digital Service Standard, and by most state government procurement requirements, including the NSW Digital Service Toolkit. It is also the level referenced in Australia’s obligations under the Disability Discrimination Act 1992, which applies to information and services provided online.
WCAG is organised around four principles. Content must be perceivable, operable, understandable and robust. The sections below set out what each principle requires and how this site meets it.
Information must be presentable in ways people can perceive, whatever their vision, hearing or reading needs.
Every image that carries meaning has alternative text describing it. Decorative images — the watercolour artwork in the page headers and footer, for example — are marked as decorative so screen readers skip them rather than reading out noise.
Body text is set in a dark slate on a warm paper background, and headings in near‑black. Both exceed the 4.5:1 contrast ratio Level AA requires for body text, and the 3:1 ratio required for large text and user interface components. Link colour is a deep cobalt chosen to pass against both the paper and surface backgrounds.
No information on this site is conveyed by colour alone. Links are distinguishable by position and context as well as colour, sector labels carry text as well as a coloured chip, and form errors are described in words.
All type is set in relative units and the layout reflows to a single column on narrow screens. Text can be enlarged to 200% without loss of content or function, and the site reflows to a 320 pixel viewport without requiring horizontal scrolling.
A light and dark theme are both provided, with the theme control in the site header. The dark theme maintains the same contrast ratios rather than simply inverting colours.
Interface components and navigation must be usable by people who do not use a mouse.
Every interactive element — navigation, the sector dropdown, case study cards, buttons, form fields and the theme toggle — is reachable and operable by keyboard alone, in a logical order that follows the visual layout. There are no keyboard traps.
Focused elements show a visible focus indicator, so keyboard users can always see where they are on the page.
The site uses no autoplaying video, no carousels that advance on their own, and no parallax or scroll‑triggered animation. Navigation menus open and close without motion. Nothing on the site flashes.
Interactive targets meet the 24 by 24 pixel minimum introduced in WCAG 2.2, with touch targets on phones sized more generously again.
The same navigation appears in the same place on every page, and links that open in a new tab are the exception rather than the rule — used only for external publications and downloads, and marked accordingly.
Content and operation must be clear.
The page language is declared as English. Each page has a single, descriptive first‑level heading, with sub‑headings in a proper nested order, so screen reader users can navigate by heading structure.
Pages are written in plain English. Technical terms — program logic, cost‑benefit analysis, value for money — are explained where they first appear rather than assumed.
Every form field has a visible, permanently associated label rather than placeholder‑only text. Required fields are identified in words. Error messages describe what went wrong and how to correct it, and are announced to assistive technology.
Content must work reliably with current and future assistive technologies.
Pages are built from semantic HTML — real headings, lists, links, buttons and landmark regions — rather than styled generic containers. This is what lets screen readers, voice control software and browser reader modes interpret the page correctly.
Custom controls expose an accessible name and role. The theme toggle, for example, announces its current state and what activating it will do.
The site has been checked with keyboard‑only navigation and with screen reader output, in addition to automated checking.
We publish some reports and papers as PDFs hosted by third parties — client departments, journals and conference organisers. We do not control the accessibility of those documents. Where a PDF is not accessible and you need its content, contact us and we will provide it in an accessible format.
If you encounter a barrier on this site, or need information from it in another format, please tell us. We treat accessibility problems as defects and aim to respond within two business days.
Email brian@cobalt59.com.au or call +61 408 028 269.
This statement describes the state of the site at its most recent review. We reassess accessibility whenever the site changes substantially, and at least annually.
Independent, evidence-based evaluation of complex environmental, government and public benefit programs.