A property search is mostly images, maps, filters, and forms, which is precisely the combination that breaks for keyboard and screen reader users. That makes real estate website accessibility unusually high-stakes: a buyer who cannot operate your map filter or submit a viewing request simply leaves for a competitor's portal.
This guide walks through the four components that cause the most friction on real estate sites, with concrete fixes mapped to WCAG 2.2 Level AA, the baseline expected under the European Accessibility Act and used as the de facto ADA standard in the US.
Property listings: structure before styling
A listing card is a small unit of structured data, and screen reader users navigate it by landmarks and headings, not by visual layout. Give each card a real heading (the address or property title as an h2 or h3) so users can jump between results with the H key, rather than wrapping everything in divs styled to look like headings.
The 'price, beds, baths, area' row is where teams routinely lose meaning. Icon-only specs like a bed glyph next to '3' read as nothing useful; pair each icon with a text label or an aria-label such as 'Bedrooms: 3'. If the whole card is clickable, make the address the actual link and let the card surface act as a larger target rather than nesting multiple competing links, which forces screen reader users through duplicate announcements.
- Mark 'New', 'Under offer', or 'Price reduced' status with text, not color alone (WCAG 1.4.1) so it survives for colorblind and screen reader users.
- Keep status badges and price text at 4.5:1 contrast for normal text and 3:1 for large text (1.4.3); a contrast checker catches the pale-grey-on-white captions that fail.
- Ensure interactive controls such as the favorite/heart toggle expose state with
aria-pressedand meet the 24x24 CSS pixel target size minimum (2.5.8, new in WCAG 2.2).
Image galleries and alt text that actually helps
Galleries fail in two opposite ways: no alt text at all, or a wall of identical filenames like 'IMG_4821.jpg'. Neither helps a buyer decide. Write alt text for the photos that carry decision-making information, the hero exterior, the kitchen, the primary bath, the view, and mark genuine duplicates or decorative thumbnails with empty alt="" so assistive tech skips them instead of reading noise.
Good listing alt is specific and grounded: 'Open-plan kitchen with island and south-facing garden doors' beats 'kitchen photo'. Avoid stuffing the address or price into every image; that data already lives in the page text. Run a representative gallery through an alt text checker to find images that are missing text or carrying filenames instead of descriptions.
The gallery controls are where carousels most often break keyboard access. Next/previous buttons must be real button elements reachable by Tab with a visible focus ring (2.4.7), and that focus indicator must not be hidden behind a sticky header (2.4.11, Focus Not Obscured). Crucially, any swipe-to-advance behavior needs a single-pointer alternative: WCAG 2.2's 2.5.7 Dragging Movements requires that you can also click arrows rather than being forced to drag. Lightbox overlays should trap focus while open, return focus to the trigger on close, and dismiss on Escape.
Maps and search filters: never map-only
An interactive map is a great feature and a terrible sole interface. The core rule for map-based search accessibility is redundancy: every property and filter reachable on the map must also be reachable in a plain results list. A screen reader user filtering for '2-bed, under EUR 400k, with parking' should get the same set as a sighted user dragging the map, without ever touching the canvas.
For the map itself, make pins keyboard-focusable with descriptive accessible names (the address and price, not 'marker'), and ensure cluster expansion works without a mouse. Treat filters as a real form: every range slider, checkbox, and dropdown needs an associated label, error messages tied to fields with aria-describedby, and results that announce updates via an aria-live region so users know the list changed. Custom slider widgets must implement the slider role with arrow-key support and report their current values.
- Don't rely on 'drag the corners to draw a search area' as the only way to set a region; provide a postcode or radius input too (again, 2.5.7).
- Make filter chips removable by keyboard and announce the removal.
- Keep the result count and 'no properties match' state in the live region so it is spoken, not just shown.
Contact and enquiry forms: where conversions are won or lost
The viewing-request or mortgage-enquiry form is the one component you cannot afford to get wrong, because it is the conversion. Every field needs a persistent visible label (placeholder text alone is not a label and disappears on input), inputs need correct type and autocomplete attributes so browsers and password managers can fill name, email, and phone, and required fields must be programmatically marked, not just flagged with a red asterisk.
WCAG 2.2 added criteria that hit forms directly. 3.3.7 Redundant Entry means you should not force users to re-type information they already gave earlier in a multi-step enquiry. 3.3.8 Accessible Authentication (Minimum) means any account login or saved-search gate must not depend on a memory or transcription puzzle without an alternative. Errors must be identified in text and described (3.3.1, 3.3.3), and the error summary should move focus so it is not silently missed.
If you embed a third-party CRM or lead-capture widget, test it as rigorously as your own code, since these are a common source of unlabeled fields that quietly fail your most important conversion path.
Where to start
You don't need to rebuild your portal to make progress. Run a free scan of a representative listing page, a search-results page, and your contact form with AccessScan to surface missing labels, low-contrast text, and unlabeled controls in minutes, then prioritize the conversion path first.
From there, confirm your obligations against the European Accessibility Act if you operate in the EU, where WCAG 2.2 Level A and AA has been the baseline via EN 301 549 since 28 June 2025, and publish an honest accessibility statement describing your conformance level and how users can report problems. Automated tools catch roughly a third of issues; pair them with real screen reader testing on the same three pages and you'll close most of the gap that costs you leads.