Testing lazy image support, and instead finding another unexpected behavior
Hey, maybe you saw this link back in April: Native image lazy-loading for the web!?
With the release of Chrome you can try lazy loading content with elements like images and iframes, by using the
<img src="my-file.jpg" alt="this is a test!" loading="lazy">
Check out the previously mentioned link for more information on the attribute and how to polyfill.
But what impact does lazy loading have on screen readers accessing graphics in Chrome?
Giving lazy loading images try
I did testing of lazy loading images, and then again with another test case with different desktop screen readers (JAWS and NVDA on Windows and VoiceOver on macOS). Being a Chrome only feature, I only tested with Chrome.
Originally when testing, I was finding that I could not navigate using the G key to images marked for lazy loading with JAWS. This was regardless of them being standard content images, or images nested within a link.
So I filed a bug, because while the
alt attribute text for each image was still accessible when navigating by virtual cursor, not being able to navigate to these graphics via the hot key seemed like an odd quirk. I did not experience this bug with other screen readers paired with Chrome.
The next day
Waking up this morning I found that a JAWS user had come across my bug, retested and found different results.
It wasn’t the
loading attribute that was causing images to be undiscoverable when navigating by graphics, or loading a listing of graphics in the document. Rather, it seems with JAWS and Chrome specifically, images within links are “hidden”.
Oddly enough, after a system restart and retesting again this morning, I found the same. Lazy loaded graphics were all discoverable, but any graphic nested within a link was not exposed as a graphic when using JAWS 2019 (August release) when paired with Chrome 76.
Loading up JAWS 2018 and retesting again with Chrome, images, even those within a link, are exposed as graphics and can be navigated to.
Testing JAWS 2019 with Firefox and IE11 also produces similar results, graphics that are within links or as static images in the document are all discoverable by JAWS (2018 and 2019).
So, I have no answer as to why lazy loaded images weren’t discoverable to me yesterday, but are today. A full system restart seemed to sort things out in that regard, proving that the advice of “have you tried turning it off and then back on again?” almost always seems to be applicable.
But while the issue I found doesn’t actually seem to be an issue, now I’m left puzzling as to why the latest JAWS, only paired with Chrome, is not exposing graphics within links.
Feature or bug? Something to look into for another time I suppose.