Very few images are truly decorative. An image can add meaning, mood, or context without providing information. It may be time for WCAG to use a better category.
As front end development continues to be obfuscated away from core components I wonder how much this could be addressed by tweaking the default behaviors and prop names in popular UX packages. For instance, if you are checking the type def and see aria-label you have to either know or care to look up what that means and how to use it properly. If you instead had a property like visibleToAssistiveTechnologyAs, (and don’t bury it 3 components deep in the spec and expect people to find out about it if they’re only checking out the ”filled-input " component) while more verbose, you would have a definition more immediately clear to developers who don’t care to look up the unknown out if curiosity.
Ideally devs would care enough to learn accessibility solidly before they are tasked to build something, but the reality is we learn as we go. Someone in the field for a decade is obviously going to know more and may properly incorporate assistive technologies, but with more and more devs coming from boot camps and vibes having the part of the code they most normally touch be very explicitly clear is gonna go a long way.
Devs who don’t know and don’t care will still get a linter error and make it go away. You’re also forgetting how much you know here: I had to sit through a doctor doing a web search for “assistive technology” the other day, that would be just as meaningless.
My instinct is that we can move towards abstract elements (HTML or components) that either use images decoratively or are explicitly called “picture.” Yes, that always exists, I mean making that more of an industry default. The language there conveys the purpose better, in my mind: an image may be utilitarian, a picture is for communicating something. If it’s “worth a thousand words,” it needs words, right?
As front end development continues to be obfuscated away from core components I wonder how much this could be addressed by tweaking the default behaviors and prop names in popular UX packages. For instance, if you are checking the type def and see
aria-labelyou have to either know or care to look up what that means and how to use it properly. If you instead had a property likevisibleToAssistiveTechnologyAs, (and don’t bury it 3 components deep in the spec and expect people to find out about it if they’re only checking out the ”filled-input " component) while more verbose, you would have a definition more immediately clear to developers who don’t care to look up the unknown out if curiosity.Ideally devs would care enough to learn accessibility solidly before they are tasked to build something, but the reality is we learn as we go. Someone in the field for a decade is obviously going to know more and may properly incorporate assistive technologies, but with more and more devs coming from boot camps and vibes having the part of the code they most normally touch be very explicitly clear is gonna go a long way.
Devs who don’t know and don’t care will still get a linter error and make it go away. You’re also forgetting how much you know here: I had to sit through a doctor doing a web search for “assistive technology” the other day, that would be just as meaningless.
My instinct is that we can move towards abstract elements (HTML or components) that either use images decoratively or are explicitly called “picture.” Yes, that always exists, I mean making that more of an industry default. The language there conveys the purpose better, in my mind: an image may be utilitarian, a picture is for communicating something. If it’s “worth a thousand words,” it needs words, right?