E-mail List Archives

Search E-mail List Archives for

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

From: glen walker
Date: Sun, Nov 17 2019 3:05PM
Subject: Thoughts on citing multiple WCAG criteria for one issue
No previous message | Next message →

When doing compliance testing, do you limit the criteria for an issue to
just one criterion so as not to overinflate the number of issues found on a
page?



For example, if there was a <label> next to an <input> but the two were not
programmatically associated (ie, no "for" attribute), would you cite both
4.1.2 and 1.3.1 as the problem? My preference in that case is to just use
4.1.2. But technically there is a visual relationship between the label
and input because they're adjacent to each other on the display but that
relationship cannot be programmatically determined, so it's a 1.3.1 too. But
the solution for both 4.1.2 and 1.3.1 is the same – to use the "for"
attribute.



As another example, if you have an image embedded in a link and the link
itself does not have any visual text and the image doesn't have alt text,
that could be both 1.1.1 and 2.4.4. For me, this is more difficult than
the previous example in trying to choose just one criterion. This could
again be fixed with one solution – specifying an alt on the image – but
that is not how I would fix it. I would recommend an empty alt on the
image to hide it, then specify an aria-label on the link. That way you
don't hear the word "graphic" when the link is announced. In general,
users don't care if a link is implemented as text or as an image. They
just want to know what the link is for. So I would probably report two
separate issues (1.1.1 and 2.4.4) with separate solutions rather than one
issue with two success criteria.



If the above two examples were the only issues on the page, would you
report two, three, or four issues?

From: Birkir R. Gunnarsson
Date: Sun, Nov 17 2019 3:11PM
Subject: Re: Thoughts on citing multiple WCAG criteria for one issue
← Previous message | Next message →

I try to limit the issue count to the number of elements that have to
be fixed (in your case, 2).
I typically do not include WCAG success criteria in my audit reports
(at least internal), people do not need to see the complex WCAG
references (unless they are legal or accessibility experts
themselves), instead I try to focus on the element, the problem and
how to fix it.
If you must include a success criterion, go with the one you think is
most relevant, you can list the other (or others) as (also impacted)
or (also applicable) but I would not inflate the number of issues by
listing them separately, again, focus on the unit of code that is the
problem.
That is just my recommendation of course, I never claim infalability. ;)


On 11/17/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> When doing compliance testing, do you limit the criteria for an issue to
> just one criterion so as not to overinflate the number of issues found on a
> page?
>
>
>
> For example, if there was a <label> next to an <input> but the two were not
> programmatically associated (ie, no "for" attribute), would you cite both
> 4.1.2 and 1.3.1 as the problem? My preference in that case is to just use
> 4.1.2. But technically there is a visual relationship between the label
> and input because they're adjacent to each other on the display but that
> relationship cannot be programmatically determined, so it's a 1.3.1 too.
> But
> the solution for both 4.1.2 and 1.3.1 is the same – to use the "for"
> attribute.
>
>
>
> As another example, if you have an image embedded in a link and the link
> itself does not have any visual text and the image doesn't have alt text,
> that could be both 1.1.1 and 2.4.4. For me, this is more difficult than
> the previous example in trying to choose just one criterion. This could
> again be fixed with one solution – specifying an alt on the image – but
> that is not how I would fix it. I would recommend an empty alt on the
> image to hide it, then specify an aria-label on the link. That way you
> don't hear the word "graphic" when the link is announced. In general,
> users don't care if a link is implemented as text or as an image. They
> just want to know what the link is for. So I would probably report two
> separate issues (1.1.1 and 2.4.4) with separate solutions rather than one
> issue with two success criteria.
>
>
>
> If the above two examples were the only issues on the page, would you
> report two, three, or four issues?
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Sun, Nov 17 2019 4:35PM
Subject: Re: Thoughts on citing multiple WCAG criteria for one issue
← Previous message | Next message →

On 17/11/2019 22:05, glen walker wrote:
> When doing compliance testing, do you limit the criteria for an issue to
> just one criterion so as not to overinflate the number of issues found on a
> page?
[...]
> As another example, if you have an image embedded in a link and the link
> itself does not have any visual text and the image doesn't have alt text,
> that could be both 1.1.1 and 2.4.4.

And also 4.1.2, as then the link lacks an accessible name too.

It depends on how you report things. If you're doing a spreadsheet
showing all issues found, then you should really show everything that
was failed. In a more freeform/written report, I'd make a single issue,
but note that it fails all these separate SCs...but still write it up as
a single "thing".

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Sun, Nov 17 2019 4:37PM
Subject: Re: Thoughts on citing multiple WCAG criteria for one issue
← Previous message | Next message →

On 17/11/2019 23:35, Patrick H. Lauke wrote:
>> As another example, if you have an image embedded in a link and the link
>> itself does not have any visual text and the image doesn't have alt text,
>> that could be both 1.1.1 and 2.4.4.
>
> And also 4.1.2, as then the link lacks an accessible name too.

And, incidentally, I call these sorts of things "Cascades of fail" - see
slide 30 from my recent a11yTO talk here
https://patrickhlauke.github.io/wcag-interpretation/#30 :)

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: glen walker
Date: Sun, Nov 17 2019 5:27PM
Subject: Re: Thoughts on citing multiple WCAG criteria for one issue
← Previous message | Next message →

Thanks for the thoughts (especially on a weekend).

I had looked at the a11yTO slides a couple weeks ago :-)
In fact, I had a question about slide 51 and whether the example did indeed
fail 1.4.1 while passing 1.4.11.
I don't have a recording of a11yTO so didn't have the context of the slides
but I presume if the different colors ("sign in") have meaning, then it
would be a 1.4.1 issue. I'm not going to delve into the topic of defining
what "color" means.


On Sun, Nov 17, 2019 at 4:38 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 17/11/2019 23:35, Patrick H. Lauke wrote:
> >> As another example, if you have an image embedded in a link and the link
> >> itself does not have any visual text and the image doesn't have alt
> text,
> >> that could be both 1.1.1 and 2.4.4.
> >
> > And also 4.1.2, as then the link lacks an accessible name too.
>
> And, incidentally, I call these sorts of things "Cascades of fail" - see
> slide 30 from my recent a11yTO talk here
> https://patrickhlauke.github.io/wcag-interpretation/#30 :)
>
>
>

From: Tim Harshbarger
Date: Mon, Nov 18 2019 3:23AM
Subject: Re: Thoughts on citing multiple WCAG criteria for one issue
← Previous message | No next message

I think there may be a couple reasons why listing all the relevant success criteria for an element might be the better approach.

I think one reason it is attractive just to let a single success criterion to stand in for others is because we guess that fixing that one issue will fix all the other success criteria we would have listed for the same element. However, project teams can be quite imaginative in how they solve accessibility issues and it is possible that they might implement a solution that only fixes the criterion you listed--and none of the criteria you chose not to list. Unfortunately, that puts us in a situation where we have to return to the project team to let them know about additional accessibility defects of which they were unaware.

I think the other reason is educational. For example, if they have an image link without alt text, citing multiple issues (even though you can fix multiple issues with one approach) teaches them that images need alternative text and links need accessible text--if they pick up on that information, that is something they can use in the future to avoid either type of issue.

I'm not saying there is no reason for taking the other approach or the other approach always creates problems, but that it seems to me that listing all the relevant issues for an element might be the better approach.

Thanks,
Tim Harshbarger
Senior Accessibility Consultant
Deque Systems