Forms that use faceted search filtering present a series of categories to filter search results by. Selecting a filter option will typically auto-submit the form instantly and present the filtered search results. This is a good UX for regular users but what about disabled users?

My concern is over accessibility guideline 3.2.2 "On Input" https://www.w3.org/WAI/WCAG21/Understanding/on-input.html

One of the fail examples it gives is "F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value"

Failure Example 2:

This is an example that submits a form when the user selects an option from the menu when there is no warning of this behavior in advance. The form will submit as soon as an item from the menu is selected. A user using a keyboard will not be able to navigate past the first item in the menu. Blind users and users with hand tremors can easily make a mistake on which item on the dropdown menu to choose and they are taken to the wrong destination before they can correct it.


Faceted search isn't quite the same as that example but it is very similar. Select an option and the faceted search will automatically submit the form and present new data to the user.

It's easy enough to still pass this criterion by simply warning users that the form will filter the search results as they select categories to filter by. My question is, do we really need to include this warning to pass accessibility on a faceted search?

There seems to be many sites that use faceted search that do not include this warning.

  • "Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action." source: w3.org/WAI/WCAG21/Understanding/on-input.html The accessibility guidelines let you warn users as a way to still implement the auto-submit behaviour without breaking accessibility compliance Commented May 30, 2018 at 7:52

3 Answers 3


Going into the Success criterion and the reasons why, one could find:

Intent of this Success Criterion

The intent of this Success Criterion is to ensure that entering data or selecting a form control has predictable effects. Changing the setting of any user interface component is changing some aspect in the control that will persist when the user is no longer interacting with it. So checking a checkbox, entering text into a text field, or changing the selected option in a list control changes its setting, but activating a link or a button does not. Changes in context can confuse users who do not easily perceive the change or are easily distracted by changes. Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action.

OK. So does the faceted search initiates a change of context in the way it is described?

Not really.

A change of context would rather be: User is led to a new page, or focus changes to something else, or the element they were modifying was changed without warning, or the focused element was deleted...

That being said, from my experience user testing blind people who use screen-reader, it would be expected by them to get an information message that the content under the heading "Results" (for example) will be filtered according to their actions in this section (for example the "Filters" section)

This can be done easily by starting the section with a label that would be only visible to screen reader users.

Another, complimentary way to do it (as suggested in @slugolicious's answer), would be to use aria-live regions so that you could keep the user updated as the number of result changes. For example, the screen-reader could read:

30 results found matching current query

In any case, it is legit and totally doable to dynamically change the content of a page for screen reader users.

  • I want to accept both your answer and the answer @slugolicious gave since they both have useful information that the other doesn't have. I can only accept one though :( Commented May 31, 2018 at 14:24
  • I updated to include @slugolicious's answer as well so we can have everything in the same place
    – Leths
    Commented Jun 6, 2018 at 11:26

This is a good UX for regular users but what about disabled users?

It's wonderful that you are considering accessibility issues during development but keep in mind that "disabled users" are "regular users" too. If I have to bump up the font by 150% to read the screen, does that make me not a regular user? Perhaps you were asking how the UX would affect low-vision or cognitively impaired users, all collectively still considered "regular users".

Keep in mind that 3.2.2 is more about a change in context and not a change in content. You can change the content of a page and not violate 3.2.2, provided the change in content doesn't "change the meaning of the Web page". In your description above, it sounds like the faceted filter changes don't change the meaning of the page but just limit what is displayed.

You should be ok if you use aria-live regions to announce how the filter affected the display, such as "10 items shown of 100 (filtered)".

  • You know what I meant by "regular user". -_- I just meant a user who is using all the default settings in a browser that they can see just fine and have no cognitive issues. What is a single word you would use to describe that sort of user? "Regular" was the word I thought made the most sense. Maybe "default" user is a better word. Commented May 30, 2018 at 22:15
  • Yeah, that sounds like a decent alternative. "Using the default settings in the browser" or a user with 20/20 vision, or a user without vision impairments. Not a single word description, but not bad. So perhaps, "This is a good UX for sighted users but what about users with visual impairments" . Commented May 31, 2018 at 1:27
  • It's not just about people with visual impairments though. The guidelines also emphasise that this is also important for people with cognitive impairments. Commented May 31, 2018 at 9:00
  • 1
    The comment section is limited so I couldn't go into details about all the accessibility issues. I teach classes on this subject and it'd be hard to convey that in 500 chars or less. Your original question, "does faceted search fail accessibility", is a qualified "no". It doesn't fail provided you don't drastically update the page to change the meaning of the page and you notify AT users that something changed. Commented May 31, 2018 at 13:37

The the faceted search that I posted this question for was not actually powered by ajax. When you selected a category to filter by it triggered a full page refresh.

I've realised now that due to the full page refresh it most definitely causes a huge accessibility fail. Screen reader users end up having to listen to the whole page again and keyboard users have to tab all the way back to the filters every time they select an option.

The other answers have been helpful for figuring out how to deal with this accessibility fail though.

  • 1
    This ought to be added as an edit to the OP.
    – Mayo
    Commented Apr 15, 2019 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.