E-mail List Archives

Search E-mail List Archives for

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

From: Isabel Holdsworth
Date: Fri, Aug 31 2018 3:24AM
Subject: Relating answer options to their question
No previous message | Next message →

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

From: Jared Smith
Date: Fri, Aug 31 2018 9:13AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

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 ADDRESS 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
> > > > >

From: Birkir R. Gunnarsson
Date: Fri, Aug 31 2018 10:30AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.

From: Jared Smith
Date: Fri, Aug 31 2018 10:50AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

Birkir -

Thanks for your thoughts on this. I agree that aria-describedby could
be a 3rd option, though with the repetition issues you describe. This
repetition, however, could not as easily be addressed at the AT level
like it could for fieldset/legend or radiogroup.

> As to your last question, I'd say that a legend is insufficient as a label for a form control.

The question wasn't really whether legend is sufficient as a label,
but whether legend alone is sufficient to meet 1.3.1.

> 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 .

Right, but WCAG 1.3.1 does not require an accessible name or a label.
It only requires that the "information, structure, and relationships
conveyed through presentation can be programmatically determined or
are available in text." I can certainly argue that putting a text box
in a fieldset provides a programmatic relationship. If it didn't then
it would also be insufficient for a grouping of radio buttons, right?
The legend also makes the information "available in text". Would this
not be sufficient to meet 1.3.1?

We would, of course, recommend fieldset/legend in this case, but it
does, I think, pose an interesting WCAG interpretation question - and
one that's currently very acute for one of our clients.

Thanks,

Jared

From: Birkir R. Gunnarsson
Date: Fri, Aug 31 2018 11:04AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

Hey Jared

I should've been more specific on this. ;) The setup may pass 1.3.1
but it would not pass 4.1.2, because the legend for the fieldset does
not translate into an accessible name for the checkbox control. Under
4.1.2, since a checkbox is an operable element, it has to have an
accessible name.

As we all know we can play WCAG interpretation gymnastics all day
*grin* I try to stay on the more pragmatic end of the spectrum, but I
personally am pretty insistent on 4.1.2 being met in all situations.

On 8/31/18, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir -
>
> Thanks for your thoughts on this. I agree that aria-describedby could
> be a 3rd option, though with the repetition issues you describe. This
> repetition, however, could not as easily be addressed at the AT level
> like it could for fieldset/legend or radiogroup.
>
>> As to your last question, I'd say that a legend is insufficient as a label
>> for a form control.
>
> The question wasn't really whether legend is sufficient as a label,
> but whether legend alone is sufficient to meet 1.3.1.
>
>> 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 .
>
> Right, but WCAG 1.3.1 does not require an accessible name or a label.
> It only requires that the "information, structure, and relationships
> conveyed through presentation can be programmatically determined or
> are available in text." I can certainly argue that putting a text box
> in a fieldset provides a programmatic relationship. If it didn't then
> it would also be insufficient for a grouping of radio buttons, right?
> The legend also makes the information "available in text". Would this
> not be sufficient to meet 1.3.1?
>
> We would, of course, recommend fieldset/legend in this case, but it
> does, I think, pose an interesting WCAG interpretation question - and
> one that's currently very acute for one of our clients.
>
> Thanks,
>
> Jared
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Fri, Aug 31 2018 12:03PM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

Isabel, going back to your original question on grouping answers with the
question, even though the first rule of ARIA
<https://www.w3.org/TR/using-aria/#rule1> recommends using native markup
before using aria attributes, so in this case using a fieldset/legend
before role="group" and aria-label, I almost always use role="group" in
these situations, mainly because of what Jared and Birkir already mentioned
- that fieldset/legend can sometimes be overly verbose. I like how the
aria-label is announced for the role="group" when you tab to the first
checkbox (or the last checkbox if you shift+tab into the group) and then
it's silent after that.

Glen

From: Guy Hickling
Date: Fri, Aug 31 2018 6:23PM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

I would like to take up the point of very long fieldset legends because
this does bother me every time I see it, and I think we could look for some
alternative solution without necessarily going down the ARIA route.

Where a group of checkboxes or radios has a very long text above the group,
but no fieldset, I have experimented with recommending as the solution that
the developers should choose a few words that correctly describe the group
and could therefore be the group label (keeping it to less than 5 words if
possible. These words will usually occur in the long text already shown on
screen.) Add these chosen words (visually on screen) above the very long
text as a visual label for the whole group. Then use them as the fieldset
legend. Just leave the long text as is, not using it for the legend. This
offers a way to have very short fieldset legends, while still showing the
desired long text before the group of checkboxes/radios.

I would be interested in people's comments on this.

Regards,
Guy Hickling

From: Isabel Holdsworth
Date: Mon, Sep 03 2018 8:39AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

Thanks everyone. We're creating a question authoring system, which
means we won't have fine control over what's uploaded. So we're trying
to cover all bases in enabling authors to create accessible content.

I think that asking an author to condense their question down into
four or five words might result in some interesting content, and good
as the idea is, we don't feel confident that authors would understand
the consequences of getting it wrong, especially since the shortened
version won't be visible. I've used this technique myself many times,
and it works well if you have control over the content.

Thanks again, Isabel

On 01/09/2018, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
> I would like to take up the point of very long fieldset legends because
> this does bother me every time I see it, and I think we could look for some
> alternative solution without necessarily going down the ARIA route.
>
> Where a group of checkboxes or radios has a very long text above the group,
> but no fieldset, I have experimented with recommending as the solution that
> the developers should choose a few words that correctly describe the group
> and could therefore be the group label (keeping it to less than 5 words if
> possible. These words will usually occur in the long text already shown on
> screen.) Add these chosen words (visually on screen) above the very long
> text as a visual label for the whole group. Then use them as the fieldset
> legend. Just leave the long text as is, not using it for the legend. This
> offers a way to have very short fieldset legends, while still showing the
> desired long text before the group of checkboxes/radios.
>
> I would be interested in people's comments on this.
>
> Regards,
> Guy Hickling
> > > > >

From: Birkir R. Gunnarsson
Date: Mon, Sep 03 2018 8:57AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

I'd go with the old fieldset/legend and advise the authors to keep the
questions as clear and concise as possible. If they can keep
explanatory text such as (only check one answer) or the like outside
of the question (<legend>) I'd code the system in such a way that it
could be done (keep it in the fieldset after the legend).


On 9/3/18, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks everyone. We're creating a question authoring system, which
> means we won't have fine control over what's uploaded. So we're trying
> to cover all bases in enabling authors to create accessible content.
>
> I think that asking an author to condense their question down into
> four or five words might result in some interesting content, and good
> as the idea is, we don't feel confident that authors would understand
> the consequences of getting it wrong, especially since the shortened
> version won't be visible. I've used this technique myself many times,
> and it works well if you have control over the content.
>
> Thanks again, Isabel
>
> On 01/09/2018, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
>> I would like to take up the point of very long fieldset legends because
>> this does bother me every time I see it, and I think we could look for
>> some
>> alternative solution without necessarily going down the ARIA route.
>>
>> Where a group of checkboxes or radios has a very long text above the
>> group,
>> but no fieldset, I have experimented with recommending as the solution
>> that
>> the developers should choose a few words that correctly describe the
>> group
>> and could therefore be the group label (keeping it to less than 5 words
>> if
>> possible. These words will usually occur in the long text already shown
>> on
>> screen.) Add these chosen words (visually on screen) above the very long
>> text as a visual label for the whole group. Then use them as the fieldset
>> legend. Just leave the long text as is, not using it for the legend. This
>> offers a way to have very short fieldset legends, while still showing the
>> desired long text before the group of checkboxes/radios.
>>
>> I would be interested in people's comments on this.
>>
>> Regards,
>> Guy Hickling
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Isabel Holdsworth
Date: Tue, Sep 04 2018 3:06AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

Thanks Birkir. I wish we could do that, but our software is used
internationally, for all sorts of tests and exams, aimed at all age
groups, and so sadly we have zero control over question length or
content. We'll keep doing our best to enforce accessibility where we
can, and hope that authors read our documentation and follow our
advice to make their content accessible.

On 03/09/2018, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> I'd go with the old fieldset/legend and advise the authors to keep the
> questions as clear and concise as possible. If they can keep
> explanatory text such as (only check one answer) or the like outside
> of the question (<legend>) I'd code the system in such a way that it
> could be done (keep it in the fieldset after the legend).
>
>
> On 9/3/18, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>> Thanks everyone. We're creating a question authoring system, which
>> means we won't have fine control over what's uploaded. So we're trying
>> to cover all bases in enabling authors to create accessible content.
>>
>> I think that asking an author to condense their question down into
>> four or five words might result in some interesting content, and good
>> as the idea is, we don't feel confident that authors would understand
>> the consequences of getting it wrong, especially since the shortened
>> version won't be visible. I've used this technique myself many times,
>> and it works well if you have control over the content.
>>
>> Thanks again, Isabel
>>
>> On 01/09/2018, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
>>> I would like to take up the point of very long fieldset legends because
>>> this does bother me every time I see it, and I think we could look for
>>> some
>>> alternative solution without necessarily going down the ARIA route.
>>>
>>> Where a group of checkboxes or radios has a very long text above the
>>> group,
>>> but no fieldset, I have experimented with recommending as the solution
>>> that
>>> the developers should choose a few words that correctly describe the
>>> group
>>> and could therefore be the group label (keeping it to less than 5 words
>>> if
>>> possible. These words will usually occur in the long text already shown
>>> on
>>> screen.) Add these chosen words (visually on screen) above the very long
>>> text as a visual label for the whole group. Then use them as the
>>> fieldset
>>> legend. Just leave the long text as is, not using it for the legend.
>>> This
>>> offers a way to have very short fieldset legends, while still showing
>>> the
>>> desired long text before the group of checkboxes/radios.
>>>
>>> I would be interested in people's comments on this.
>>>
>>> Regards,
>>> Guy Hickling
>>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Jonathan Avila
Date: Sat, Sep 15 2018 3:38PM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

> 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 ADDRESS 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.

From: Birkir R. Gunnarsson
Date: Sat, Sep 15 2018 4:14PM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.
>
>

From: Jonathan Avila
Date: Sat, Sep 15 2018 4:19PM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

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 ADDRESS 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.

From: Isabel Holdsworth
Date: Mon, Sep 17 2018 4:24AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.
>
>

From: Jonathan Avila
Date: Tue, Sep 18 2018 7:01AM
Subject: Re: Relating answer options to their question
← Previous message | Next message →

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 ADDRESS 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.

From: Isabel Holdsworth
Date: Thu, Sep 20 2018 8:18AM
Subject: Re: Relating answer options to their question
← Previous message | No next message

Thanks Jonathan. I'm thinking more from the perspective of someone
unfamiliar with the guidelines but who thinks a specific scenario
might present an accessibility barrier. Say if one of our designers
felt the focus outline on a custom component might not be easy to see,
they could quickly scan down a list of common issues, find the one
that they're concerned about, and a link to the SC that it fails
against.

If nothing like this exists, I'm going to create one for our designers
and devs. But if it does, I'd really appreciate if someone could point
me to it please.

Cheers, Isabel

On 18/09/2018, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> 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 ADDRESS 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.
>
>