UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce the problem:
1. Create page markup with an image having null ALT text ('ALT=""'), as described in WCAG 2.0 technique H67: https://www.w3.org/TR/WCAG20-TECHS/H67.html
2. Compare the source HTML to the rendered page HTML as seen through the developer tools "Inspect" feature
3. Source HTML attribute will be: 'ALT=""'
4. Rendered HTML attribute will be 'ALT' (no attribute value)

A reproduction page with some longer explanations is available via https://rawgit.com/waharnum/chromiumAltReplication/master/index.html

What is the expected behavior?
Given source HTML '<img src="sunCat.jpg" alt="" />', the rendered HTML when inspecting via the dev tools should be '<img src="sunCat.jpg" alt="" />'

What went wrong?
Given source HTML '<img src="sunCat.jpg" alt="" />', the rendered HTML when inspecting via the dev tools is '<img src="sunCat.jpg" alt />'.

Did this work before? Yes Unsure, but appears to be a recently introduced issue around 55/56

Chrome version: 57.0.2987.133  Channel: stable
OS Version: OS X 10.12.3
Flash Version: 

1) This issue was originally surfaced by a colleague who works as a web accessibility audit specialist, and uses the development tools as part of her auditing workflow. She noticed many rendered pages had begun to have an incorrect no-value use of the ALT attribute that was not matched by the original page markup.

2) When using VoiceOver with Chrome on OS X, VoiceOver treats images as though they have no ALT attribute when they in fact have the WCAG-advised null ALT text.

3) This issue is also present in Safari, so may originate in some shared code from Webkit (pure speculation). It doesn't exhibit the same issue with VoiceOver in Safari, presumably because of different approaches between Chrome and Safari to the accessibility APIs on OS X.

4) While I'm filing this is a Developer Tools issue because that's how it originally surfaced for us, I believe it is a larger issue with Chrome's interpretation and rendering of HTML source code with regard to ALT attributes of IMG tags. As far as I can tell, it is incorrect to render an ALT attribute as though it is a binary attribute like CHECKED - it must have a value, even if the value is blank.