Accessibility and inclusive UX for NZ websites: practical basics that help everyone
Who this is for. NZ small-business site owners who want broader reach, lower friction, and fewer “I couldn’t use your form” complaints—without pretending a one-page checklist equals WCAG legal sign-off.
Accessibility is not a separate “feature.” It is good UX that includes people using keyboards, screen readers, magnification, voice control, or shaky mobile connections.
1. Why it matters commercially
- Broader audience—temporary and permanent disabilities are common.
- Better SEO hygiene from semantic structure and sensible alt text.
- Lower support load when forms and errors are clear.
- Alignment with procurement and partnership expectations as you grow.
2. Keyboard navigation basics
Every interactive control should be reachable with Tab/Shift+Tab and activatable with Enter/Space as appropriate. Hidden “keyboard traps” frustrate power users and assistive tech alike.
3. Visible focus indicators
Do not remove outlines without designing a clearer replacement. If you cannot see focus, many users cannot either.
4. Forms: labels, errors, and instructions
Associate labels programmatically with inputs. Describe errors next to fields (“This date looks incomplete”) rather than only colour. Required fields should be obvious in text, not only asterisks with unexplained legends.
5. Colour contrast
Body text and essential icons need sufficient contrast against backgrounds. Test buttons and links in all states (hover, focus, disabled).
6. Images and alt text
Alt should convey the communicative purpose of the image. Decorative images can be marked appropriately so screen readers skip noise. Keyword-stuffed alt hurts humans and credibility.
7. Heading hierarchy
Headings outline the document. Do not skip levels for styling convenience—use CSS for size.
8. Video and audio
Provide captions; transcripts help even when audio fails on the train. Auto-captions are a starting point, not always sufficient for compliance-sensitive content.
9. Touch targets and spacing on mobile
Small buttons clustered together cause mis-taps. Tradespeople wearing gloves or using phones in sunlight need forgiving targets.
10. PDFs vs HTML
HTML pages are easier to make accessible and responsive. If you must use PDFs, remediate them or offer HTML alternatives for critical information.
11. Testing: combine automated and manual
Scanners catch some issues; humans catch logic and flow. Quick checks: keyboard-only pass, zoom to 200%, and listen with a screen reader for five minutes on your top tasks.
12. Procurement questions
Ask vendors for recent accessibility examples, component libraries, and how they handle regressions after launches.
13. Frequently asked questions
Do we need WCAG 2.2 AA everywhere?
Many organisations aim for AA as a baseline; requirements vary by sector and contract. Know your obligations; improve continuously.
Will accessible sites look boring?
No—clarity and aesthetics coexist. Constraint often improves design discipline.
Overlay widgets?
Be sceptical of one-line “fixes.” Real accessibility is built into content, design, and code—not bolted on.
Related shorter guides. Visit Accessibility & inclusive UX for keyboard checks, contrast, forms, headings, and testing patterns.