E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Kalpeshkumar Jain
Date: Tue, Aug 25 2020 1:41AM
Subject: Filter Component Accessibility
No previous message | Next message →

Hi All,

We have a Filters (checkboxes) section in the search result page.
When the User toggles any of the filters the result section is updated.
This change is dynamic and I believe it violates SC 3.2.2.

I checked various eCommerce sites and observed the same behaviour.

In my opinion an 'Apply Filter' button should be provided so that there is
no dynamic change and the User is in control of the interaction.

I would like to know your opinion on this and also whether my suggestion
makes sense.

Thanks,
Kalpeshkumar Jain

--


This mail is governed by the LearningMate Privacy Policy and Disclaimer
at *https://www.learningmate.com/privacy/
<https://www.learningmate.com/privacy/>*

From: Patrick H. Lauke
Date: Tue, Aug 25 2020 2:32AM
Subject: Re: Filter Component Accessibility
← Previous message | Next message →

On 25/08/2020 08:41, Kalpeshkumar Jain via WebAIM-Forum wrote:
> Hi All,
>
> We have a Filters (checkboxes) section in the search result page.
> When the User toggles any of the filters the result section is updated.
> This change is dynamic and I believe it violates SC 3.2.2.

That's not necessarily the case, though opinions vary on this. Arguably,
having results dynamically change to reflect what the user just checked
is not, in my view, a change of "content that changes the meaning of the
Web page" https://www.w3.org/TR/WCAG22/#dfn-change-of-context

There have been similar discussions around 4.1.3, and whether or not it
applies in situations like this. The general consensus at the time was
that IF the newly displayed/filtered list of results has some text that
visibly says "Showing 1 - 20 of 80 results" or similar, then *that*
could be seen as a status, and should be dynamically announced when it
changes. This would then help AT users understand that ticking those
filter boxes had some kind of effect.

But otherwise, this is a scenario that falls between SCs, I'd say. It's
not a clear-cut failure.

> I checked various eCommerce sites and observed the same behaviour.
>
> In my opinion an 'Apply Filter' button should be provided so that there is
> no dynamic change and the User is in control of the interaction.
>
> I would like to know your opinion on this and also whether my suggestion
> makes sense.

If possible, by all means suggest an "Apply Filter" button. Otherwise,
another option would be to at least have a status (which could even be
visually hidden, but just announced by AT) that informs the user that
something has happened/changed (e.g. "Filter applied" or "Results
filtered" or similar). That then at least helps AT users.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: glen walker
Date: Tue, Aug 25 2020 8:18AM
Subject: Re: Filter Component Accessibility
← Previous message | Next message →

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.

From: Jeremy Echols
Date: Tue, Aug 25 2020 8:29AM
Subject: Re: Filter Component Accessibility
← Previous message | Next message →

Some websites actually reload the entire page when choosing things like this, and I think *that* would violate 3.2.2 because it's a full page reload, focus is lost, etc. If it's just the results section, as others have mentioned, it can be handled in a way that satisfies 3.2.2.

From: Kalpeshkumar Jain
Date: Wed, Aug 26 2020 3:04AM
Subject: Re: Filter Component Accessibility
← Previous message | No next message

Thank you everyone for their inputs, I am closing this thread.

Thanks,
Kalpeshkumar Jain


On Tue, Aug 25, 2020 at 7:59 PM Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:

> Some websites actually reload the entire page when choosing things like
> this, and I think *that* would violate 3.2.2 because it's a full page
> reload, focus is lost, etc. If it's just the results section, as others
> have mentioned, it can be handled in a way that satisfies 3.2.2.
>
>