Accessibility

Our target

Property Ranker targets the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA across the public website and authenticated application. Accessibility is intended to be included in design review, implementation, automated checks and manual testing rather than treated as post-launch work.

A WCAG 2.2 AA audit, including keyboard and screen-reader journeys, is a proposed release gate before public beta.

Keyboard, focus and structure

• Every wizard, reaction, sharing and summary action should work with a keyboard.
• Focus order should be logical, with a clearly visible focus indicator.
• Wizard steps should use labelled headings and named progress indicators.
• When a step changes, focus should move to its heading for assistive technology.
• Validation failures should provide an error summary as well as field-level help.

Meaning beyond colour or icons

Status, fit, evidence coverage and partner reactions must not rely on colour alone. Icons need meaningful text alternatives—for example, “Thumbs up: I like this”—and every explanation should remain understandable without a map or chart.

Maps should have a list or table alternative. Match-status and score changes should be announced to assistive technology without excessive interruption.

Visual, touch and motion needs

• Interactive touch targets should be at least 44 by 44 CSS pixels.
• Text and controls should have sufficient contrast.
• Content should support browser zoom and text resizing.
• Motion should respect reduced-motion preferences.
• Unknown, eligible and excluded states should pair visual treatment with explicit text.

Clear and inclusive content

The intended service uses Australian English, Australian dollars, metric distances and plain-language explanations. It should ask one concept at a time, explain why personal information is requested and keep sensitive questions optional.

Unsupported qualities such as smell, room feel or neighbour noise should become inspection checks instead of fabricated scores. Missing data should be stated as unknown, never presented as a pass.

Testing and accountability

The proposed test coverage includes keyboard and screen-reader completion of the wizard, reactions, sharing and status explanations, plus browser, mobile and regression testing. Accessibility findings should be reviewed before release and after material interface changes.

This prototype has not yet completed the planned WCAG 2.2 AA audit. Any known limitations and remediation timing should be published as the product moves toward beta.

Feedback and assistance

A dedicated accessibility feedback and assistance route will be published before release, alongside a correction and complaint process. It should allow people to report a barrier, request information in an accessible form and receive a clear response without exposing private profile details.