Accessibility Toolbar Gotcha with <noscript> Elements

Posted by Steve Green on 15 May 2016.

Like many accessibility testers, I use the List Images feature of the Accessibility Toolbar to check that all the images on a page have appropriate "alt" attributes.

On a recent project, the Toolbar showed that all the images that were listed did indeed have appropriate "alt" attributes, but it wasn't telling the whole truth.

The HTML Validator tells another story

As part of another test I uploaded the source code to the W3C Online HTML Validator, which reported a number of images without "alt" attributes. How could that be?

It turned out that the page contained a <noscript> element that replicated almost the entire page content, but with some differences, one of which was the lack of "alt" attributes for images.

Conclusion

The conclusion is that the Accessibility Toolbar is probably analysing the Document Object Model (DOM), not the source code. This makes sense because it means it can analyse any code that is generated or modified by JavaScript, but it does leave this blind spot.

Further tests showed that the same applies to all the other tools in the Accessibility Toolbar such as Heading Structure and Table Headers.

Lessons learned

1. On each page, check if there is a <noscript> element and determine what it is doing. Our experience is that they are often legacy content that should have been removed or artefacts of frameworks that have not been inserted intentionally.
   
   There is no reason to use <noscript> elements these days - progressive enhancement has long been a better approach. However, we still encounter <noscript> elements surprisingly often.
2. If the page is intended to be used with or without JavaScript, conduct all the relevant tests using the Accessibility Toolbar twice - once with JavaScript on and again with it turned off.