Missing <img> alt attribute should be an error, not a warning.

[ckundo]

WebAIM indicates that even presentational images should have alt attributes, they should just be empty as an instruction to assistive tech to ignore them. Otherwise screen readers may read the file name or apply other heuristics to guess the description.

What do you think about elevating the severity on this audit to an error rather than a warning?

Here is the line: https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/audits/ImageWithoutAltText.js#L27

[alice]

http://www.w3.org/TR/wai-aria/roles#presentation states "Authors SHOULD NOT
provide meaningful alternative text (for example, use alt="" in HTML4) when
the presentation role is applied to an image." The rule as written returns
false (i.e. passes) for either any alt attribute value (including empty),
or a role of "presentation". (It doesn't treat having both alt text and
role=presentation as an issue, however.) Is there a specific case that
you're thinking of where it is a false negative (i.e. passes but shouldn't)?

Do you think it's worth elevating the severity? I think we decided against
it originally on the basis that it usually didn't make a page unusable
(unlike, say, unlabelled form elements), but was usually more of an
annoyance (overly verbose in the case of images lacking alt="") or a gap in
information. We could certainly reconsider that, though.

On Sat, Jul 20, 2013 at 3:03 PM, Cameron Cundiff
notifications@github.comwrote:

WebAIM indicates that even presentational images should have alt
attributes http://webaim.org/techniques/images/alt_text#null, they
should just be empty as an instruction to assistive tech to ignore them.
Otherwise screen readers may read the file name or apply other heuristics
to guess the description.

What do you think about elevating the severity on this audit to an error
rather than a warning?

Here is the line:
https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/audits/ImageWithoutAltText.js#L27

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10
.

[ckundo]

On second thought, I agree with your original decision to make it a warning and not an error. Errors should be reserved for issues that 'make the page unusable', as you said, akin to an unhandled exception. I think that distinction is important, and a good one to document in the README. It also informs how we'll represent the errors in capybara-accessible, so thanks again for the clarification.

[ckundo]

Also, thanks for the reference on role="presentational". I didn't know about that guideline.

[willcc]

Our team is trying to achieve/maintain our product's accessibility according to usability and WCAG AA (nee 508) compliance on a distributed developer team.

We definitely agree that missing alt attributes don't break the experience -but- would be a significant blocker for us to achieve our business objective of staying on the right side of AA. We use GADT in our regression test suite where we'd prefer the true failures to equate to things that a) break the page and b) break compliance.

Any chance we could reconsider this issue and have missing alt attributes be failures?

[alice]

@willcc How urgent is this for you? I think a better solution would be to allow users to override the default error level settings, something like:
var auditConfig = new axs.AuditConfiguration();
auditConfig.setSeverity('imgWithoutAltText', axs.constants.Severity.SEVERE);

This would be a bit more work than just setting the severity of the rule across the board, but I think we need to do it anyway for cases like this.

I'll raise a bug for this and link it here, then you can follow it. In the meantime, if this is super urgent for you, you can always change it in a local fork and then revert to the main repository once that bug is fixed.

[willcc]

Configuration would certainly solve the problem for us.

We're a little low on developers atm but if that is still hanging around open in a couple weeks we'll pick that up and add the config.

[ckundo]

@willcc pull request #43 introduces a configuration mechanism for overriding severity for specific rules, like so:

auditConfig.setSeverity('badAriaRole', axs.constants.Severity.WARNING)