WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Filter Component Accessibility

for

From: glen walker
Date: Aug 25, 2020 8:18AM

I agree that this situation is a bit gray. I don't normally fail these
types of checkboxes. Ideally, the user is "advised of the behavior before
using the component" such as if there were a visible note that said filters
are automatically applied. That would satisfy 3.2.2. However, the sighted
user will know that happens the first time they use it. A screen reader
user might not know that if nothing is announced after the filter is
applied (unless they have some limited vision and can see something about
the page changed). A user that is easily distracted by changes might have
difficulty with it too.

I also apply Patrick's argument that if there's a note that updates on the
number of results and that note is *not* announced, it's a 4.1.3 issue. If
the note *were* announced, not only does that satisfy 4.1.3 but it also
helps 3.2.2. Granted, the note being announced after the checkbox is
selected is not advising the user *before* the component is used, it kind
of has the same effect after the fact.

I use the "change of context" definition all the time and make sure I point
out that change of "context" and change of "content" are quite different.
Changing the "content" can be ok, if, as Patrick says, it does not change
the meaning of the page.

One other thing to consider, and it's not an accessibility issue, is the
performance of immediately applied filters. If it takes time to apply a
checkbox, that is going to be a poor user experience to have to wait for
the filter to be applied before you can check another filter. There are
many times where I really like the filter applied immediately, if it's
efficient, because I want to see the results of that filter and try various
combinations. But it seems like there are equally a number of times where
I'd like to check a bunch of boxes before having them applied. This comes
down to a usability study.