6 ms·

// "alt" is now required for improved accessibility I'm all for accessibility, but let us decide when to implement it.

• calvin 4y ago
  You should still be able to use alt="" to indicate that it is "decorative" and not meaningful imagery for a visually-impaired user.
  • latchkey 4y ago
    That's like the difference between null and undefined.
    • cramforce 4y ago
      If you have no alt attribute, then screen readers read the URL! Empty strings are the way to go for decorative images
      • deleted 4y ago
        [deleted]
      • latchkey 4y ago
        What if I have an app that no screen reader will ever read?
        • joshka 4y ago
          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.
      • abujazar 4y ago
        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.
  • chrisco255 4y ago
    Instead use the ARIA tag role="presentation": https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... to indicate when an element has no semantic meaning and is purely visual.
    • Vinnl 4y ago
      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?
    • klipilicica 4y ago
      "presentation" is the default role for an <img> element when the "alt" attribute is an empty string.
    • krono 4y ago
      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://html.spec.whatwg.org/multipage/images.html#alt https://w3c.github.io/aria/#presentation https://w3c.github.io/aria/#presentation https://w3c.github.io/aria-practices/#presentation_role https://w3c.github.io/aria-practices/#presentation_role
      • chrisco255 4y ago
        That second link from W3C gives this very example: https://w3c.github.io/aria/#example-13 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." <img src="example.png" role="presentation" alt=""> So empty alt tags are not discouraged.
• kolanos 4y ago
  > I'm all for accessibility, but let us decide when to implement it. Which usually means never.
  • googlryas 4y ago
    Which just means codebases will be littered with alt="" for no reason.
    • abujazar 4y ago
      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.
      • googlryas 4y ago
        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.
        • Vinnl 4y ago
          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.
          • googlryas 4y ago
            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.
            • Vinnl 4y ago
• lghh 4y ago
  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.
  • latchkey 4y ago
    I'm curious why you think that forcing people to write alt="" is going to improve accessibility?
    • randomguy0 4y ago
      Because that’s how screen readers know the image is decorative. It literally is/improves accessibility.
      • lghh 4y ago
        Additionally, the developer is more likely to actually write alt text when it's not decorative.
        • Vinnl 4y ago
          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.
• joshribakoff 4y ago
  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 https://html.spec.whatwg.org/multipage/images.html#alt
  • latchkey 4y ago
    NextJS could just create alt="" when rendering the HTML <img> element from their <Image> element.
    • deleted 4y ago
      [deleted]
    • Vinnl 4y ago
      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.
    • MaxLeiter 4y ago
      That could harm the experience for assistive tech users more than no alt tag
    • dariusj18 4y ago
      I think the compromise would be an optional build parameter that allows this functionality.
    • Serenacula 4y ago
      Frameworks shouldn't be changing the content you coded on the sly, that's just asking for trouble. Imagine trying to debug that.