Designing pages that work with screen readers
For a minimal information site such as smcasino-game.com, an uncluttered visual presentation is a useful starting point. A screen reader turns the page into synthesised speech or braille, so structure and wording matter as much as colour and layout. People may move directly between headings, navigation landmarks, lists and form fields, bypassing much of the visual design.
For Australian readers, accessibility is a practical requirement, especially on federal, state and local services. Australian Government digital services are expected to meet WCAG 2.1 AA through the Digital Service Standard, which provides a strong baseline for any general resource. Accessible pages also support people using magnification, speech input or reduced motion, and remain clearer on small or ageing devices.
Build a structure assistive technology can understand
Use native HTML elements for the page frame: header, nav, main, aside and footer. Give the main content one clear h1, then organise subsections with h2 and h3 elements. These markers create a navigable outline for screen readers; choosing a large font for ordinary text does not create a heading.
Keep the DOM order aligned with the intended reading order. If CSS moves a sidebar or card, the spoken sequence should still make sense. Do not hide content with display: none when it is needed to understand the page, and use an empty alt attribute for genuinely decorative images so they are skipped rather than announced as “image”.
Give controls and content meaningful names
Every control needs an accessible name that describes its purpose. Use a button for an action and an a element for navigation, even when both look similar on screen. An icon-only control such as a menu button needs a programmatic label, while a disclosure should expose whether it is expanded or collapsed. Visible labels should remain part of the interface whenever possible.
Links should describe their destination instead of saying “click here” or “read more”. Image alternatives should convey the information or function of the image, not merely identify it as an image. Text embedded in a picture should also appear as selectable text, and repeated images can use empty alternatives when nearby text already conveys the same meaning.
Keep keyboard and screen reader navigation in step
Every interactive element must work with a keyboard, with focus following the visual and logical order. Provide a visible focus indicator with enough contrast, rather than removing the browser outline. A skip link can be the first focusable item, allowing keyboard and screen-reader users to bypass repeated navigation and reach the main content.
Custom widgets need the expected keys: Enter or Space for a button, arrow keys for many menus, and Escape to close an overlay. Update aria-expanded, aria-selected or aria-checked when the visual state changes. Do not move focus automatically when background information refreshes, because that can interrupt a screen-reader user mid-sentence.
| Element | Preferred implementation | User experience |
|---|---|---|
| Navigation | nav landmark with descriptive links |
The user can enter and leave a clearly named navigation area |
| Link | Link text that identifies the destination | The user can decide whether to follow it from a list of links |
| Icon control | Native button with an accessible name and state |
The control has a spoken purpose and announces its current state |
| Informative image | Concise alternative text describing its meaning | The image contributes information without relying on sight |
| Form field | Associated visible label, instructions and error message | The user hears the field name, requirement and any problem |
| Status update | Status region with aria-live="polite" for non-urgent changes |
New information is announced without an unexpected focus shift |
Preserve clarity in visual, spoken and zoomed views
Readable typography, short line lengths and generous spacing benefit screen magnification and some forms of dyslexia. Text and essential controls should meet WCAG contrast requirements, and information must never rely on colour alone. The page should also reflow at high zoom without horizontal scrolling for ordinary content, so no text, link or control is clipped.
Set the document language to en-AU when the content uses Australian English; this helps VoiceOver and other tools choose an appropriate voice and pronunciation. Use plain Australian English, expand agency acronyms on first use and format dates, times, phone numbers and dollar amounts consistently. Writing “$” and dates in standard Australian order helps content sound natural when spoken aloud.
Make changing service information dependable
Updates such as opening hours, transport disruptions and form confirmations need a programmatic status message. A non-urgent change can use a polite live region, while an error tied to the current action should be identified as an alert and associated with the relevant field. Move focus only when the user must respond somewhere else.
This matters for Australian service portals such as Service NSW and myVicRoads, and for public transport information used in Sydney, Melbourne and Brisbane. A disruption should be available as text, not only on a colour-coded map or station screen. In regional and remote Australia, where connections can be slow and people may make long journeys to reach services, keep essential information lightweight and provide clear phone, email and downloadable alternatives.
Establish a repeatable accessibility standard
Quality checks should combine automation with manual use of the keyboard and at least one screen reader. Automated tools can identify missing labels and weak contrast, but they cannot judge whether link text makes sense or whether focus order supports the task. Include people with disability in testing, since disabilities and preferred assistive technologies vary.
- Define accessible patterns for navigation, headings, links, forms, media and status messages.
- Require keyboard operation, visible focus and logical focus order for every component.
- Require accessible names, useful alternatives and accurate state changes.
- Test key journeys with at least one of VoiceOver, NVDA or TalkBack, plus zoom and reflow.
- Record an accountable owner who reviews accessibility whenever content or components change.
Publish the standard in the release process and include a plain-language accessibility statement with contact details and known limitations. A general information site can retain its clean appearance while treating accessibility as an ongoing publishing responsibility rather than a one-off repair.