WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relating answer options to their question

for

From: Isabel Holdsworth
Date: Sep 17, 2018 4:24AM

You've made me think: it would be very useful to have a list of common
fails matched up to the SC that they fail against. Does such a thing
exist?

If, for example, a designer spotted that a form contained a textbox
that was linked visually with an adjacent icon (say amagnifying
glass), but there was no text label, being able to click on the
failing SC would lead them to a resource describing best practice
solutions. I guess an FAQ type scenario would work well here.

If anything like this exists, perhaps someone could point me to it. If
not, I'm going to start putting something together.

Cheers, Isabel

On 15/09/2018, Jonathan Avila < <EMAIL REMOVED> > wrote:
> Birkir, I would consider that case a failure of SC 4.1.2 because each
> control must have an accessible name. For the purpose of SC 3.3.2 visible
> labels -- instructions and labels from other controls can be used -- for
> example a visible phone number could apply to 3 fields visually area code,
> number and exchange -- but for 4.1.2 I'd say we need an explicit name for
> each of those fields.
>
> Jonathan
>
> Jonathan Avila, CPWA
> Chief Accessibility Officer
> Level Access
> <EMAIL REMOVED>
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Saturday, September 15, 2018 6:15 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Relating answer options to their question
>
> Well put Jon
> Quick question, would providing a checkbox without a label in a fieldset
> with a legend be a WCAG 4.1.2 violation?
>
> <fieldset>
> <legend>I agree to the terms</legend>
> <input type="checkbox">
> </fieldset>
>
> My interpretation is that, yes it does.
> Because while "I agree to the terms" is the accessible name of the group
> element for the checkbox it is not the accessible name of the checkbox
> itself (per the accessible name and description calculation algorithm).
> Screen readers have verbosity setttings that may include not announcing
> legends for fieldsets (they shouldn't but they do), but, as far as I know,
> no screen reader ignores the accessible name of a form input element like a
> checkbox (certain caveats about aria labeling support in IE11 and such
> aside).
>
> Thanks
> -Birkir
>
>
> On 9/15/18, Jonathan Avila < <EMAIL REMOVED> > wrote:
>>> 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?
>>
>> I look at it this way.
>> SC 3.3.2 covers the requirement for visible labels (graphics or text)
>> SC 4.1.2 covers programmatic labels SC 1.3.1 In this case is there to
>> make sure the programmatic and visible label coincide -- not to the
>> point of the new WCAG 2.1 SC 2..5.3 Label in Name -- but that a person
>> can make that connection that the programmatic name sufficiently
>> provides the same information as communicated visually.
>> SC 2.5.3 takes this to a higher level then was required previously
>> explicitly indicating the same text be included but does not address
>> situations where no-text graphical labels are provided such as icons
>> without text. So 1.3.1 still has value in that situation even under WCAG
>> 2.1.
>>
>> Jonathan
>>
>> Jonathan Avila, CPWA
>> Chief Accessibility Officer
>> Level Access
>> <EMAIL REMOVED>
>> 703.637.8957 office
>>
>> Visit us online:
>> Website | Twitter | Facebook | LinkedIn | Blog
>>
>> Looking to boost your accessibility knowledge? Check out our free
>> webinars!
>>
>> The information contained in this transmission may be attorney
>> privileged and/or confidential information intended for the use of the
>> individual or entity named above. If the reader of this message is not
>> the intended recipient, you are hereby notified that any use,
>> dissemination, distribution or copying of this communication is strictly
>> prohibited.
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> Jared Smith
>> Sent: Friday, August 31, 2018 11:13 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] Relating answer options to their question
>>
>> 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
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > >