WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: What's the best way to identify semi-related filter options (a.k.a., facets)?

for

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

From: Jeremy Echols
Date: Wed, Aug 11 2021 1:52PM
Subject: What's the best way to identify semi-related filter options (a.k.a., facets)?
No previous message | Next message →

Say I'm on an e-commerce site like Amazon and looking for music. They'll have things like "Format" where you can look only for music that's available on cassette, CD, Vinyl, etc. But these options aren't mutually exclusive, so you can look for anything that's on cassette or CD, not just one or the other.

Say you have a dozen or so of these top-level categories. There might be "genre", "decade", etc.

Some argue that each of these sections should be a fieldset, because then the checkboxes are all given a label. For instance, the "decade" fieldset might have a legend of simply "Decade" and each checkbox then has the context "Decade" in front of it.

Others argue that headings make more sense, because a fieldset should be used for values that apply to a single field, not choosing options from a similar category. The claim is that the heading of "Decade" is enough context to know that the "1980s", "1990s", and "2000s" checkboxes are filters within that category. Or if it isn't, the claim is that you can apply something like "aria-describedby" to add context.

I'm personally a bit torn. The fieldset approach gives free context, while using headings means we either assume the headings give enough context, or we have to add more description (which means a rougher UI or else screen-reader-only text). But semantically it feels like all the checkboxes, no matter which category they belong to, are equally related to each other. A fieldset implies a strong, tight grouping of fields, but in this scenario the category is just an organization of fields that are all answering a single question: "how would you like to refine your search?"

So my questions:


* Can both approaches be made WCAG compliant? I am pretty sure they can, but I want to be certain.
* Is a heading (h1, h2, h3) enough context for such groupings of checkboxes or would additional labeling be necessary?
* Is one option clearly more semantically correct than the other, or is this one of those "more art than science" situations?

From: Aditya
Date: Wed, Aug 11 2021 2:36PM
Subject: Re: What's the best way to identify semi-related filter options (a.k.a., facets)?
← Previous message | Next message →

Jeremy,

May be use both.. fieldset and heading tag wrapped in legend.

It provides heading navigation option and context for input elements.

Aditya


Sent from my iPhone

> On Aug 11, 2021, at 2:52 PM, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
>
> Say I'm on an e-commerce site like Amazon and looking for music. They'll have things like "Format" where you can look only for music that's available on cassette, CD, Vinyl, etc. But these options aren't mutually exclusive, so you can look for anything that's on cassette or CD, not just one or the other.
>
> Say you have a dozen or so of these top-level categories. There might be "genre", "decade", etc.
>
> Some argue that each of these sections should be a fieldset, because then the checkboxes are all given a label. For instance, the "decade" fieldset might have a legend of simply "Decade" and each checkbox then has the context "Decade" in front of it.
>
> Others argue that headings make more sense, because a fieldset should be used for values that apply to a single field, not choosing options from a similar category. The claim is that the heading of "Decade" is enough context to know that the "1980s", "1990s", and "2000s" checkboxes are filters within that category. Or if it isn't, the claim is that you can apply something like "aria-describedby" to add context.
>
> I'm personally a bit torn. The fieldset approach gives free context, while using headings means we either assume the headings give enough context, or we have to add more description (which means a rougher UI or else screen-reader-only text). But semantically it feels like all the checkboxes, no matter which category they belong to, are equally related to each other. A fieldset implies a strong, tight grouping of fields, but in this scenario the category is just an organization of fields that are all answering a single question: "how would you like to refine your search?"
>
> So my questions:
>
>
> * Can both approaches be made WCAG compliant? I am pretty sure they can, but I want to be certain.
> * Is a heading (h1, h2, h3) enough context for such groupings of checkboxes or would additional labeling be necessary?
> * Is one option clearly more semantically correct than the other, or is this one of those "more art than science" situations?
> > > >

From: Birkir R. Gunnarsson
Date: Thu, Aug 12 2021 8:11PM
Subject: Re: What's the best way to identify semi-related filter options (a.k.a., facets)?
← Previous message | Next message →

I use grouping elements (<fieldset> or <div role="group">) to group
elements with a common group label, including filters.

I find this to be the best user experience, since the group label is
programmatically available, the screen reader can treat it with
maximum efficiency, and we're not forcing the common label on every
single individual control label (either via label or description).
For filters that instantly affect the search results I use toggle
buttons (button elements with with an aria-pressed attribute) instead
of checkboxes.
The difference is minor but a checkbox is primarily for forms and the
expectations is that you need to submit a form (activate a button) for
the checkbox state change to impact the webpage.
Here is how I would code a search result filter with 45 days being active
<div role="group" aria-labelledby="gt">
<h3 id="gt">Include transactions within</h3>
<button aria-pressed="false">Last 30 days</button>
<button aria-pressed="true">Last 45 days</button>
<button aria-pressed="false">Last 6 months</button>
</div>


On 8/11/21, Aditya via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
> Jeremy,
>
> May be use both.. fieldset and heading tag wrapped in legend.
>
> It provides heading navigation option and context for input elements.
>
> Aditya
>
>
> Sent from my iPhone
>
>> On Aug 11, 2021, at 2:52 PM, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Say I'm on an e-commerce site like Amazon and looking for music. They'll
>> have things like "Format" where you can look only for music that's
>> available on cassette, CD, Vinyl, etc. But these options aren't mutually
>> exclusive, so you can look for anything that's on cassette or CD, not just
>> one or the other.
>>
>> Say you have a dozen or so of these top-level categories. There might be
>> "genre", "decade", etc.
>>
>> Some argue that each of these sections should be a fieldset, because then
>> the checkboxes are all given a label. For instance, the "decade" fieldset
>> might have a legend of simply "Decade" and each checkbox then has the
>> context "Decade" in front of it.
>>
>> Others argue that headings make more sense, because a fieldset should be
>> used for values that apply to a single field, not choosing options from a
>> similar category. The claim is that the heading of "Decade" is enough
>> context to know that the "1980s", "1990s", and "2000s" checkboxes are
>> filters within that category. Or if it isn't, the claim is that you can
>> apply something like "aria-describedby" to add context.
>>
>> I'm personally a bit torn. The fieldset approach gives free context,
>> while using headings means we either assume the headings give enough
>> context, or we have to add more description (which means a rougher UI or
>> else screen-reader-only text). But semantically it feels like all the
>> checkboxes, no matter which category they belong to, are equally related
>> to each other. A fieldset implies a strong, tight grouping of fields, but
>> in this scenario the category is just an organization of fields that are
>> all answering a single question: "how would you like to refine your
>> search?"
>>
>> So my questions:
>>
>>
>> * Can both approaches be made WCAG compliant? I am pretty sure they
>> can, but I want to be certain.
>> * Is a heading (h1, h2, h3) enough context for such groupings of
>> checkboxes or would additional labeling be necessary?
>> * Is one option clearly more semantically correct than the other, or is
>> this one of those "more art than science" situations?
>> >> >> >> >
> > > > >


--
Work hard. Have fun. Make history.

From: Jeremy Echols
Date: Fri, Aug 13 2021 9:46AM
Subject: Re: What's the best way to identify semi-related filter options (a.k.a., facets)?
← Previous message | Next message →

Oh, this is perfect. Thanks!

From: Sailesh Panchang
Date: Fri, Aug 13 2021 10:52AM
Subject: Re: What's the best way to identify semi-related filter options (a.k.a., facets)?
← Previous message | Next message →

Cannot agree more with Birkir.
But, yes when there is a need, fieldset/legend can be nested and work
well with JAWS / NVDA.
e.g.
<fieldset><legend>Have you ever tested positive for or been diagnosed
by a member of the medical profession with:</legend>
<fieldset><legend>Human Immunodeficiency Virus (HIV)</legend>
<p><label><input type="radio" name="grp1">Yes</label></p>
<p><label><input type="radio" name="grp1">No</label></p>
</fieldset>
<fieldset><legend>Acquired Immune Deficiency Syndrome (AIDS)</legend>
<p><label><input type="radio" name="grp2">Yes</label></p>
<p><label><input type="radio" name="grp2">No</label></p>
</fieldset>
</fieldset>

Thanks,
Sailesh

On 8/13/21, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> Oh, this is perfect. Thanks!
>
>

From: Jeremy Echols
Date: Fri, Aug 13 2021 2:35PM
Subject: Re: What's the best way to identify semi-related filter options (a.k.a., facets)?
← Previous message | No next message

That's also interesting. I wonder if it would make sense to have nested grouping for our filters. This is something I didn't know was even allowed in HTML, much less that it was useful for accessibility.

Again, thanks!