New accessibility feature coming to Firefox, an “AI powered” alt-text generator.


"Starting in Firefox 130, we will automatically generate an alt text and let the user validate it. So every time an image is added, we get an array of pixels we pass to the ML engine and a few seconds after, we get a string corresponding to a description of this image (see the code).

Our alt text generator is far from perfect, but we want to take an iterative approach and improve it in the open.

We are currently working on improving the image-to-text datasets and model with what we’ve described in this blog post…"

  • IllNess@infosec.pub
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    6 months ago

    Yes you can use both but I’ve seen some front end developers blank out alt altogether when they are using figcaption.

    I did not find this practice in MDN Web Docs but I found it in an other place:

    If you’re using an image that has a caption, it may not need alt text if the caption contains all of the relevant visual information.


    I was just wondering what Mozilla’s method was for finding these images and if they took other things in to consideration like decorative images.

    • Kissaki@beehaw.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 months ago

      Interesting. It also made me look at the MDN docs again. img alt is consistent to that. I wasn’t aware of the empty for omittable images.

      I also looked at figure again, and in my interpretation it does declare that figcaption is to be used.

      figure represents self-contained content. figcaption provides the accessible name for the parent. The accessible name is is the text associated with an HTML element that provides users of assistive technology with a label for the element.

      The resolution order being aria-labelledby, aria-label, input[type=button][value], input[type=image]|img|area[alt], …

      So figcaption takes priority over img alt.

              • Kissaki@beehaw.org
                link
                fedilink
                arrow-up
                1
                ·
                6 months ago

                Given that it’s not in the comment source I doubt it’s a browser issue. But if you can see it… wtf

                When I open the comment in your original instance context it’s there. Your comment was edited. Did you edit it in? I guess it got lost between instance communication lol.

                • IllNess@infosec.pub
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  6 months ago

                  I looked through the beehaw instance and I saw what you had screenshot. You are right. It is not your browser, it is the instance.

                  Currently they currently on 0.18.4. Infosec.pub is currently on 0.19.3. Maybe that’s the issue…

                  • Kissaki@beehaw.org
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    6 months ago

                    oh god, would suck if it’s another broken Lemmy release

                    I had other formatting problems with HTML inside code blocks being removed and bleeding out of them generating other closing tags. Maybe that was also related.