WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relating answer options to their question

for

From: Birkir R. Gunnarsson
Date: Aug 31, 2018 10:30AM

Jared
As to your last question, I'd say that a legend is insufficient as a
label for a form control.
a legend does not translate to an accessible name for the checkbox,
only the <label> element (implicit or explicit) or the title attribute
can be used to assign an accessible name to a checkbox (or
aria-label/aria-labelledby of course). You can check the accessible
name and description algorithm for details .

As to the original problem.
aXe interprets WCAG 1.3.1 so that input elements with a common name
attribute require a common label. This is not 100% accurate but a
pretty close approximation.
I require a common label for all radio buttons (unless there is no
common label visually and each radio button label is clear enough to
make sense with no other context).
When the purpose of a group of checkboxes is to select one or more
options for the same problem or question I also require a common label
to be programmatically associated.

There are 3 ways to do this:

<fieldset>/<legend> (make sure that explanatory text does not go in
the <legend> only the question).

ARIA grouping
role="group" on the container element (role="radiogroup" if all inputs
are radio buttons), and aria-label with the common question or
aria-labelledby pointing to the element with the common question. The
advantage of aria-label is you can provide the briefest possible form
of the question manually, but rewording visible content is always a
bit dangerous.
eg.
<div role="group" aria-label="favorite foods">
<h2>What are your favorite foods</h2>
.... bunch of checkboxes with foods containing bacon
</div>


The third option is to have no grouping but instead have
aria-describedby on each checkbox referencing the common question.
This causes the question to be read for every checkbox, but at leastit
is read after the checkbox itself.

I think the problem of overly verbose screen reader announcement
should be addressed by the screen reader vendor or by users through
verbosity settings. Users should be able to hear the common label for
a group of elements on demand or when moing focus into the group.

Also, be aware of the notorious NVDAissue where it does not announce
the common label for a group of checkboxes (because it only announces
the common label in application mode and checkboxes do not trigger
application mode).

There is an open issue on the NVDA GitHub repo from a couple of years
ago, but when I last tested this (a while ago)it had not been fixed.
-B


On 8/31/18, Jared Smith < <EMAIL REMOVED> > wrote:
> This is an area of WCAG that is subjective. I'm sure many would flag a lack
> of a fieldset/legend for a group of radio buttons as being a failure under
> 1.3.1. The WCAG documentation does list adding a fieldset/legend as a
> Sufficient Technique (https://www.w3.org/TR/WCAG20-TECHS/H71.html). This,
> of course, does not mean that you have to have one in order to be
> conformant. The documentation does not list lack of fieldset/legend as a
> failure.
>
> Support for fieldset/legend varies across browsers and screen readers.
> Various screen readers treat them very differently - some repeat the legend
> for every control within the fieldset. This can be very intrusive and
> annoying, especially if the legend is lengthy. Chrome *STILL* doesn't
> support them at all. As you note, styling has historically been a bit
> difficult, but I think this is much less of an issue in modern browsers.
> You can remove all of the legend styling to keep the semantics without any
> of the styling problems.
>
> As an alternative, you could use role="radiogroup" with an ARIA label to
> group radio buttons and provide the grouping a label. For screen reader
> users, this should be treated identically to fieldset/legend. Radiogroup
> is, however, only for radio button groups - it shouldn't be used for groups
> of checkboxes or other controls (though last time I tested it seemed to
> work OK).
>
> In my opinion, I think fieldset/legend (or radiogroup) is certainly optimal
> for groupings of controls that are ambiguous without the association of the
> higher level description/legend (or group label), but I think it may be a
> bit of a stretch to call it a 1.3.1 failure if that descriptive text is
> present immediately before the grouping.
>
> I ran into an interesting, related question just yesterday - is it a WCAG
> 1.3.1 failure for a text box to have a fieldset legend, but not a label?
>
> Jared
>
>
> On Fri, Aug 31, 2018 at 3:24 AM, Isabel Holdsworth <
> <EMAIL REMOVED> > wrote:
>
>> Hi all,
>>
>> On one of our pages there's a heading, a question and a set of
>> checkboxes that allow the user to choose one or more answers from a
>> list of four or five possibles.
>>
>> We've been advised that not wrapping the whole thing in a fieldset
>> with the question as a legend could be a WCAG2 fail (I'm not sure
>> under which guideline).
>>
>> As a screenreader user, I find that this sort of mark-up can be
>> intrusive, as I have to listen to the whole question before hearing
>> the label on the first checkbox. Also, long legends are notoriously
>> difficult to style upp using CSS.
>>
>> Is there any other, less intrusive, way of associating a question with
>> its possible answers, or is the fact that the question appears just
>> before the options in the DOM enough to create an implicit
>> association?
>>
>> Thanks as always for any thoughts on this.
>>
>> Cheers, Isabel
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.