• he/him

one more cute disaster… it’s hard here in paradise

last.fm listening



thricedotted
@thricedotted

about to share an accessibility opinion. here are some caveats and relevant context about myself: i am not a screen reader user. i am employed as a "user experience developer", which means i am paid to spend some portion of 40 hours a week thinking about web accessibility and expect other people at my job to take my considerations seriously, but i am not an expert by any means.


best practices around alt text and image descriptions for so-called "user-generated content", like the things you and i post on this website, is still an open problem. many of the most well-known resources on writing good alt text are targeted toward application developers and editorial teams at organizations and ~SEO optimization~ -- people who need alt text on websites that are for Getting Things Done, not hanging out with your friends.

before the entire accessibility team at twitter got sacked, i think they were making great progress in exposing accessibility affordances for user-generated content... it would have been really interesting to see how they would have continued to evolve 🫥 exposing an interface for entering image descriptions to users (along with a short description of what it's for!) that was also really useful for sighted users as well was a big step in the right direction! but i'm sure they didn't nail it the first time and i wish we could have gotten to see the iteration on that. alas.

the truth is cohost has several accessibility and general layout issues that still need to be ironed out, and i am confident that they will be in time, especially if folks make feature requests and signal to staff that these things are important to their user base. while there are better and worse ways to use the existing affordances for making user content more accessible, i'm not convinced that writing alt text short enough to not trigger a detrimental UI condition (shrinking an image rather than keeping it at its largest size regardless of how long the description is) is the way to go.

a spitballing aside on how i would go about thinking about these issues if they were presented to me at my job
  • step 0 would be Gather Some Actual User Data and Feedback, which ideally is something i'd collaborating with a design team on. but if i don't get to have any of that for... reasons.......... and i'm just relying on what anecdata i have so far............... hahahahah well. let's continue

  • it seems like there's a lot of ambiguity around what "good alt text" is. when presenting users with an image description field, its purpose and function should be clear. maybe we could even provide a few "best practices" here

  • aside inside the aside: it's actually astonishing that people put long alt text in the existing alt text box, which doesn't look like it's designed for more than like 2 words, lol. people are going through a bit of trouble to put long descriptions in here!

  • user-generated content clearly still presents a wide range of alt text possibilities. how can we support expressive alt text?

    • support multiple image description fields? one for short alt text, one for longer image descriptions?

    • multiple fields complicates the UI. maybe support one field, but only attach it to the image as real alt text if it's less than, say, 125 characters; otherwise, render a separate caption and let screen readers know about it by attaching it to an element with the aria-describedby attribute, which exists for this exact situation :)

  • also let's address the low-hanging fruit of fixing the UI to not shrink an image when a description is under it :)))))

finally, here is a resource on writing image descriptions: How to Write an Image Description. imo it's very thoughtful and does a great job providing situations and examples of alt text in different contexts!


You must log in to comment.

in reply to @thricedotted's post: