WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relating answer options to their question

for

From: Jonathan Avila
Date: Sep 18, 2018 7:01AM


Isabel, the W3C has the how to meet guide which maps failures and techniques to criteria. However, adding techniques (and in particular failures) can be a long process.
https://www.w3.org/WAI/WCAG21/quickref/

Level Access (The company I work for) has best practices that map back to the standards -- samples of which can be found on webaccessibility.com (however only the descriptions are available without charge).
https://www.webaccessibility.com/best_practices.php?technology_platform_id=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 Isabel Holdsworth
Sent: Monday, September 17, 2018 6:25 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Relating answer options to their question

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.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >