Entropic-Decay

Entropy πŸ’ŽπŸ²

@Entropic-Decay

the dragon ever

Icon by @ebu

friend enjoyer and aspiring game developer

aromantic/bisexual

25 years of being chaotic and counting

send pats!!

i also do custom magic item commissions

for ttrpgs and such

frequently NSFW, sometimes I write porn and sometimes I draw it of myself
🀷

Ξ˜Ξ” am creature (dragon edition)

I enjoy doing worldbuilding a lot and have a big sci-fi setting with magic I've been building for over a decade now

log inask
If you want to know more places to find me,
ask me on discord! I don't bite (unless you want me to :3)
Entropic-Decay
@Entropic-Decay
LemmaEOF
@LemmaEOF
DecayWTF
@DecayWTF

Last thing I'm gonna say on this bullshit: Some of the "accessibility requirements" people keep demanding not only can't be requirements but don't necessarily even make sense. The one that keeps killing me is "alt text for audio embeds":

  • Audio embeds already have two description fields, and I just tested that they work in a screenreader.
  • They're audio embeds! People with vision problems are quite capable of listening to them and/or the aforementioned descriptions. Deaf people can read them.
  • Most of the recommendations for alt text usage that aren't satisfied by either using the existing description fields or just writing in the post have at least potential concrete negative accessibility implications; imagine a screenreader deciding to read you the entire lyrics to All-Star while you're tabbing through a post for no clear reason.
  • There is no defined mechanism for doing this because of the aforementioned issues. It needs a lot of careful design work before even starting implementation.

It is not "tone policing" to say that a feature request does not and cannot magically become a P0 requirement and be cranked out over a weekend (because people who Make Website should never have a day off as long as there's a single open FR, clearly) just because someone decided ex nihilo it was for accessibility rather than just a nice-to-have.

You must log in to comment.

in reply to @DecayWTF's post:

daboross
@daboross

I've missed most of the discourse (just haven't found it, so my apologies), but I've one objection and one question, if that's alright. First,

Audio embeds already have two description fields, and I just tested that they work in a screenreader.

If I understand correctly, these fields are Author and Title. Both already have existing purposes: giving an author, and the title of the piece. If I want to both title a piece, and describe it for Deaf readers, then I would still need to describe it separately.

I... am not 100% convinced of the need for an alt text field given that we can just write descriptions in the past itself, but if we did need it, I don't think either existing field suffices.

Second, though, I'm wondering why you're focusing on screen readers here? Have there actually been people wanting alt text on audio for blind people? Or is it just the term "alt text" having that connotation - would another term be better? When I heard the request first, it seemed to be entirely for Deaf people, other people thinking of Deaf people, without their direct involvement, or abled people not wanting to listen for other reasons, like convenience when in a public place.

login to reply
DecayWTF
@DecayWTF

You misunderstand. I refer to screen readers here as the other major display surface besides either traditional desktops or mobile devices. Any accessibility provision or accommodation, or standard UI element, needs to work on all major display surfaces as baseline, with is the case. If it wasn't, that would be a basis for arguing that the current situation is inadequate. We also have to make sure that introducing such a field would not also introduce problems with some display surface, such as screenreaders, which there is a risk of by introducing a new, nonstandard free text field.

Since it is not the case that the current situation is inadequate for some display surface, we have to consider what other conditions might exist for the current situation to make the site fully or partly inaccessible, and the only clear example of that is that deaf or hard of hearing users can't listen to audio embeds. Okay! So we need some mechanism for allowing the user to supply a sufficient description of the audio content (what is "sufficient" per the WCAG guidelines varies by the type of content and can be anything from a short description like, say, artist and title for content "primarily intended to create a specific sensory experience" to full transcripts). The thing is, we have that! It's the post body! An "alt text" mechanism isn't really required because we already determined that we have a short description field of the type alt text is normally used for!

There is no condition anyone can point to where it is technically infeasible or makes the site in any way not fully usable to simply use the existing description fields and then fully describe, in whatever fashion, an audio post in the body. People assume that what alt text is for is a full description of (some content) but it is explicitly not that. This is why I say it cannot be an accessibility requirement because there is no way in which the site is currently fully or partly inaccessible to anyone in absence of this feature.

login to reply
Pinned Tags