In an earlier post, I covered the accessibility challenges screen reader users hit on the search results pages of real estate websites. In this post, I want to build on that and dig into the search filtering systems on these platforms. Housing searches are personal, so they need granular control over things like price range, home size, amenities, and location, and almost every search involves some filtering to narrow the results.
As things stand, working with these filter menus is not very accessible for blind people like me who use a screen reader to browse the web, and I will walk through why in the following sections.
One of the most frustrating parts of real estate filters, from an accessibility standpoint, is the interactive elements you have to manipulate to set your criteria. The most common one I run into is the adjustment slider. These show up for everything from setting a price range to choosing a minimum square footage. Sliders give me trouble for a few reasons.
My screen reader often speaks a rounded value for the slider position. For example, it might say "40%" when the handle is really at "43%." That lack of precision makes granular control close to impossible.
The handle also sometimes springs back to its original spot once I finish interacting and move focus away. That can produce false results, because I think I set a value when the change never actually took. In other cases my screen reader will not read the reference range shown below the slider, the one that explains the scale. Without it, I am left guessing at what my criteria even mean.
Another element I hit several times was a small line graph used to show ranges, where you set the start and end points by clicking along the axes. My screen reader treats these as plain images or graphics, which makes interacting with them impossible.
A lot of the actions in these filter menus come down to selecting and deselecting items. They might be a row of buttons, a list of checkboxes, items inside an expandable section, and so on. For example, I might set the number of bedrooms and bathrooms by choosing from a list. On many sites, there are problems with how my screen reader announces the status of these items.
For one, there is often no spoken indication that an option is selected when I return to it. That makes it impossible for me to review and double check my choices before I run the search. There are also times when an item is visually selected by default but announced as "Unselected" when I focus it.
In rarer cases the status is completely inverted, where an item reads as selected when it is not, or unselected when it visually is. Toggling it just keeps the inversion going. Sometimes an element that should be actionable is picked up as static text, so I cannot manipulate it at all.
Most real estate filter menus open as a pop-up or a separate window, and that brings its own focus problems. In some cases there is focus bleed-through between the filter menu and the main page behind it. That turns into a confusing jumble of speech as my screen reader tries to process elements from both places at once.
Other times I can work through the filter options fine but cannot find the "Apply" or "Reset" button to lock in my choices. Moving through the whole window manually simply never lands focus on them. I think this happens because those buttons sit right on the border of the window and the code does not let screen reader focus reach there.
On other sites, my screen reader tries to read the entire filter menu as one big block of static text. To me that points to a deeper flaw on the back end that is breaking the whole system's accessibility.
The bottom line is that real estate searches are essentially useless without filters that work. Right now, accessibility problems stand directly in the way of equal access to them. Until issues like these get fixed, assistive technology users like me simply cannot use real estate websites to their full potential.
Range sliders frequently fail screen reader users when they announce a rounded value instead of the exact position, snap back to the default after focus moves away, or never read the reference scale beneath them. Any one of these makes precise filtering unreliable and can silently produce the wrong results. On your own site, set a slider with a screen reader, move focus away, then return to confirm the value held and was announced exactly.
Selection state breaks for screen readers when a control does not announce its selected status on refocus, or when the state is inverted so selected reads as unselected and the other way around. Users then cannot trust or verify their own choices before running a search. The check is to select several filter options with a screen reader, move away, then return to confirm each one is announced with the correct state.
Apply and Reset controls often sit on the very edge of a filter pop-up, and when the code does not allow screen reader focus to reach that region, the buttons become unreachable through normal navigation. A filter a user cannot submit is effectively a dead end. To check, open a filter menu and confirm a screen reader can reach and activate both the Apply and Reset controls without a mouse.
Filter menus concentrate several of the highest-risk patterns for screen reader users, including inaccessible sliders, wrong status announcements, and focus that bleeds between a pop-up and the page behind it. Because screen reader users file a large share of ADA web accessibility complaints, filtering is a common place those complaints originate, though whether any specific case creates exposure is a legal question. The practical point is that a filter a screen reader user cannot operate is a barrier to the core task of the site.
The filter barriers Michael runs into here, sliders that round or reset, controls that misreport their state, and Apply buttons a screen reader cannot reach, sit on the exact path a buyer needs to complete a search, which is why they surface in screen reader complaints. UsableNet Assistive remediates issues like these on your live site through runtime JavaScript, with assistive-technology testing and conditional legal support. It does not, by itself, eliminate legal risk, but it closes the gaps that prevent screen reader users from filtering at all. See how UsableNet Assistive works.