AX_FOCUS_01 Possible false positive on Floated images in Anchor elements?

[hexalys]

When images are floated (for left or right positioning) within an anchor element. The <a> element size is officially 0px (for both width and height). However I am not sure that it should report any warning in this case, as long as the anchor contains a visible image with an alt text. The image being in fact nor invisible nor obscured regardless of the wrapping anchor size.

The only way to get around the warning is to make the image an inline-block (which could create left and right alignment hurdles), or assign the float at the anchor level.

Although traditionally the float is placed on the <img> because it may or may not have a wrapping anchor around it.

But technically, I don't think a screen reader or a keyboard user is impacted by the 0px size of the anchor. In which case, it's probably only worth presenting a Warning only if the image does not contain an alt text, or if the image is actually and verifiably hidden.

[ckundo]

Thanks for bringing this up @hexalys. Your observation is valid I think. Can you post an HTML snippet that is failing?

[alice]

@hexalys Agreed, this seems like it might be a bug.

What happens when you tab to this anchor element? Do you see a focus ring around the image? As @ckundo says, a code snippet would be very helpful here to help us confirm whether this is a bug or not.

[hexalys]

@alice The focus ring generally does not show. However the Safari screen/voice reader over has no issue reading the link, and do pick up a focus ring around the image when announcing the link. Its peculiar because the <img> element cannot be 'clearfixed' because it's a self closing node. And the anchor tag is technically not a layout element.

@ckundo Here is an example snippet:

<p><a href="/" title="Home"><img src="http://www.google.com/images/srpr/logo11w.png" width="269" height="95" alt="Google" style="float:left"></a></p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius. Claritas est etiam processus dynamicus, qui sequitur mutationem consuetudium lectorum. Mirum est notare quam littera gothica, quam nunc putamus parum claram, anteposuerit litterarum formas humanitatis per seacula quarta decima et quinta decima. Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum.</p>
<p><a href="/">Google</a></p>

It could be also be a Chrome bug specifically because The OS X VoiceOver does not pick up on the link in Chrome (30.0.1599.66 beta) while it does in Safari 5.1.10

[alice]

Thanks for the snippet! I had a play with it and found that, as you say, no focus ring is shown. It's on JSFiddle here: http://jsfiddle.net/Ln3nL/show/light/

I'm inclined to say that's still an issue. Focusable elements should be visible and that focus should always be discernible, and in this case the anchor is the focusable element. While, as you say, screen reader users can still interact with the link, it does affect keyboard-only users, since there will be no feedback that they have placed focus on the link and can thus interact with it.

I experimented with your suggestion of styling the anchor element with float: left and found that that resolves this particular issue (a focus ring is drawn around the image when tabbing to it) - see http://jsfiddle.net/Ln3nL/1/show/light/. It also does improve the experience for screen reader users, at least on Chrome on OSX, as VoiceOver doesn't report focus on the link when it has zero area, but does when the image is not floated, so the user can tab through the page and hear all of the interactive elements being spoken.

[hexalys]

@alice Well it's problematic both ways. Unfortunately, that's how many sites, including all wordpress sites, are made when aligning images left and right within an article. And it's unlikely that the W3C specs can address that...

Due to the large amount of such issues out there, I think a mention should be made with a recommendation to place the Float on the anchor, instead of the image, so that people don't pull their hair out as to why they get those warnings.

[ckundo]

@hexalys the warning is still valid and accurate, and the fact that it surfaces a pervasive issue is important. It may in fact be worth submitting an issue to the Wordpress team.

There may also be room for more detailed messaging in the warning output, but it could be that the specific case is out of scope for this tool. In any event, we'll keep it in mind when we come around to revising the warning and error messages. Sincere thanks for bringing it up.

[ckundo]

@hexalys I really encourage you to submit a ticket to Wordpress. It's important to upstream issues to frameworks where we can, so that these problems are addressed at the source.

http://codex.wordpress.org/Reporting_Bugs

[alice]

@hexalys Good point about the messaging: I've updated https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#-ax_focus_01--these-elements-are-focusable-but-either-invisible-or-obscured-by-another-element to explain the issue and give an example. What do you think?

[hexalys]

@alice Sounds good, thanks. @ckundo Nods