img-uses-alt does not allow empty string or possible empty string

[lencioni]

This rule considers the following JSX bad:

function Foo() {
  return <img alt={foo || ''} />;
}

this is also considered bad:

function Foo() {
  return <img alt="" />;
}

but this is okay:

function Foo() {
  return <img alt={foo} />;
}

However, I think that all three should be okay. Empty strings can be used appropriately for alt text on images that are decorative.

[beefancohen]

I agree on the first one, since we can't determine the value of foo until runtime. However, not sure about the second - You can place a space in between the quotation marks (<img alt=" " />) and it should pass and still semantically represent the same thing to a screen reader. Also, I can implement case where alt="" (or any other form of undefined value) passes lint rule if role=presentation is present.

[lencioni]

I think the role=presentation bit makes sense. According to the spec, it should probably enforce alt="" if it has a presentation role.

Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML4) when the presentation role is applied to an image.

https://www.w3.org/TR/wai-aria/roles#presentation

[beefancohen]

Fixing first example in 0.5.3 - will upgrade minor on role=presentation enhancement. 0.5.3 should be done within the hour.

[lencioni]

Awesome! Thanks again!

[beefancohen]

0.5.3 published - should fix first use case + other bugs that are closed!

[lencioni]

I think this is still broken for cases like

function Foo() {
  return <img alt={foo.bar || ''} />;
}

and

function Foo() {
  return <img alt={bar() || ''} />;
}

and

function Foo() {
  return <img alt={foo.bar() || ''} />;
}

[beefancohen]

Added test cases for those and fixed in v0.5.4 - still may be other edge cases, working on resolving cases to handle each type specified in spec

[lencioni]

Wonderful!

[lencioni]

@evcohen do you have an ETA on the role="presentation" change? No rush--I'm just wondering if I should roll with alt=" " or wait it out.

[beefancohen]

@lencioni waiting for ci build to pass and then publishing v0.6.0. Error message updated and this strictly allows only the following scenario <img alt="" role="presentation" />

bad:

<img alt={``} role="presentation" /> etc. as we only want to deal with literals for this case.

[lencioni]

I noticed that the Chrome audit rules allows alt="" without role="presentation" and role="presentation" without alt="", FYI: https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_text_02

[beefancohen]

Use the attributes alt="", role="presentation" or include the image as a CSS background-image to identify it as being used purely for stylistic or decorative purposes and that it should be ignored by people using assistive technologies.
Source: http://fae20.cita.illinois.edu/rule/ARIA_STRICT/IMAGE_2/

Not sure what the real rule is in this case, but as a linter, I think it's better to be opinionated in a case like this or give users configuration options to manage the rigidity of the rule. My thinking is, the only time alt can be undefined (not just ="", but literally non-existent) is when role="presentation". In this sense, we can drop the check for alt altogether if role="presentation" is present. Thoughts?

[lencioni]

My reading of the text you posted agrees with the Chrome text I lined to, and it also fits my intuitive understanding. I think it makes sense to enforce the existence of alt unless role="presentation", and if role="presentation" enforce either non-existent or empty alt.