WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Thoughts on citing multiple WCAG criteria for one issue

for

From: Birkir R. Gunnarsson
Date: Nov 17, 2019 3:11PM


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