Hacker News Reader

Comment by latchkey | Hacker News Reader

  // "alt" is now required for improved accessibility

I'm all for accessibility, but let us decide when to implement it.

View on HN

I'd rather spend a literal 6-character burden (alt="") to put an empty string in my little hobby projects than live in a world where non-hobby projects can skip adding alt.

It should be very clear by just looking around on the internet that, when given the choice, accessibility will take a back seat.

I'm curious why you think that forcing people to write alt="" is going to improve accessibility?

Because that’s how screen readers know the image is decorative. It literally is/improves accessibility.

Additionally, the developer is more likely to actually write alt text when it's not decorative.

Although I must admit, I've also seen such rules leading to developers writing alt text for decorative images, and I'm not sure if that's much better.

The HTML spec says it is required, even if you don’t think it should be required it is. https://html.spec.whatwg.org/multipage/images.html#alt

NextJS could just create alt="" when rendering the HTML <img> element from their <Image> element.

That could harm the experience for assistive tech users more than no alt tag

I think the compromise would be an optional build parameter that allows this functionality.

Frameworks shouldn't be changing the content you coded on the sly, that's just asking for trouble. Imagine trying to debug that.

Next.js can't determine what the value of the alt tag should be, i.e. whether it should actually be empty. If it would do this, it would actually tell screen reader users that the image is decorative, instead of warning them that there might be information conveyed in the image that the developer forgot to label.

You should still be able to use alt="" to indicate that it is "decorative" and not meaningful imagery for a visually-impaired user.

That's like the difference between null and undefined.

If you have no alt attribute, then screen readers read the URL!

Empty strings are the way to go for decorative images

What if I have an app that no screen reader will ever read?

Then write your own component that extends and removes the requirement. Until then, web tooling is better off explicitly acknowledging that accessibility is an explicit goal.

Alt is a required attribute of the <img> tag, so requiring it is just basic validation. C code won't compile if you omit the semicolon after statements, either.

Instead use the ARIA tag role="presentation": https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... to indicate when an element has no semantic meaning and is purely visual.

Which of these tags you should use and what they should contain is entirely context dependant.

That said, the use of empty alt tags is generally discouraged and not even allowed together with the ARIA presentation role in most cases.

This decision of theirs will steer developers towards non-compliant/asemantic code. It's really stupid.

https://html.spec.whatwg.org/multipage/images.html#alt

https://w3c.github.io/aria/#presentation

https://w3c.github.io/aria-practices/#presentation_role

That second link from W3C gives this very example:

https://w3c.github.io/aria/#example-13

"In the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as presentation because the role and the text alternatives are provided by the containing element."

So empty alt tags are not discouraged.

Hence the generally discouraged - as in not recommended in the majority of situations but exceptions exist (such as the one you provided).

As I read that page, role="presentation" is intended to remove the natural semantics of a tag (e.g. have an <h2> be treated as a <div>), rather than to tell the user that there is nothing relevant to them in the given tag?

"presentation" is the default role for an <img> element when the "alt" attribute is an empty string.

> I'm all for accessibility, but let us decide when to implement it.

Which usually means never.

Which just means codebases will be littered with alt="" for no reason.

It's often better to specify alt="" than not at all, because screen readers may use the filename instead if there's no alt attribute.

That's actually a detriment then, if the "fix" for no a11y makes screen readers think they should use no alt text, instead of some possibly meaningful alternate.

The fix for no a11y is to add a11y. In many cases (i.e. the "often" specified by GP), images contain no extra information, in which case you should indicate that by adding alt="". In other cases, you should add an actual description.

I meant the "fix" of people not caring about a11y(which is why I put it in quotes) and just trying to get their code to compile.

If people don't care about a11y, they aren't going to start devoting time to it because a tool puts a slight roadblock in their way - they're just going to try to bypass the tool.

Sure, but it doesn't really matter what you do for those people; their projects will be inaccessible anyway. For the rest of us, it's a useful reminder.

Which is ok too. It is far better than encouraging people to write alt="" or alt="asdf".

See also (naming things): https://twitter.com/secretGeek/status/7269997868

They are encouraging people to write alt text, not encouraging people to write alt="".

That's like saying "Typescript just encourages people to make everything `any` instead of defining types. It's a useless addition over JS." Sure, you _could_, but most actually use the actual tool.

alt="" has a specific and intentional meaning which is _always_ better for accessibility than an unset alt

It's 6 extra characters, you'll survive.

Reply on news.ycombinator.com