> implementing ARIA markup on HTML only benefits those using assistive technology.

I'd argue that implementing ARIA markup properly also makes developers consider the general markup and structure of their product. Which in turn can lead to better UX in general, as it will lead to new insights. Yes, training developers does cost time so it is an expensive. That's often true for anything that will improve your product.

> Moreover, not every web product is simple to make accessible even by experts because eyes can process a lot of information very quickly across two dimensions, and UX designers often take this for granted.

Do you think that UX designers who take this for granted are good UX designers? I'd say that if they take it for granted that eyes can process more information, that they might need a refresher course on UX. Designs that lean heavily on visually cues and have a lot of them generally tend to be too complex and cause a visual overload.

A bonus benefit of ARIA markup is that if you have any automated UI tests they benefit from good ARIA markup and generally tend to be a bit more stable than tests using regular classes and IDs.

When I said "UX designers often take this from granted", what I meant was "literally every single UX designer I have ever worked with professionally has taken this for granted".

Accessibility is not always cheap and easy. I am only saying it isn’t more expensive if you know what you are doing.

In my 15 year career as a JavaScript developer all the biggest failures were directly attributed to poor training and leadership qualifying low standards. At some point people would do themselves a huge service by admitting they are too lazy/inept to train their staff and they deliver shit as a result. I got tired of all the weak excuses so now I do something else for a living.

If the problem is needing more competent people, that tends to be an expensive problem to solve because competent people generally cost more to hire.

While that sounds logical it’s completely false in practice. Competent people need jobs just as much as incompetent people but it’s challenging to distinguish the two. Most employers are just happy to put bodies in seats and will adjust expectations accordingly.

> ARIA markup on HTML only benefits those using assistive technology.

This specific case: ARIA labels also help search engine indexers find pages and extract information within pages more effectively. Excluding contemporary concerns about search engines intercepting advertising revenue by doing this, it is undoubtedly better for the able-sighted and blind user alike to have the option of finding an answer by visiting one page rather than two.

More philosophically: if accessibility makes things easier for people with a disability, that means it is easier for someone emulating a disability. For instance, whenever I'm holding something in one hand, I'm effectively emulating the abilities of a physically one-handed person, so if you make a design that works for one-handed people, you're also giving everyone else the extra opportunity to multitask.

> I'm not saying accessibility isn't important, but these kinds of arguments that it is always cheap and easy often actually make it harder for engineers to get the resources they need to implement it successfully.

Parent poster wasn't saying it is cheap and neither would I, but whilst the incidental benefit of accessibility improvements to able-bodied people might not seem obvious, it always exists.

I think the argument is more along the lines of "if you look after the pennies, the pounds look after themselves," not the slight straw man of "every single little accessibility improvement benefits every single user." If you have accessibilty at the heart of what you're doing then it will almost inevitably improve the product for everyone to some extent. My argument would be stronger, in that I think there's a very high probability that it will improve the product significantly for a large proportion of your audience.

I do think training developers and designers on accessibility is a core part of having them ship professional quality work. Even if product people and designers aren't thinking about it, I think it's reasonable to expect competent front-end developers to understand how to implement designs to some professional standard that doesn't make the page unusable for people with disabilities and expose the company to lawsuits.

On the other hand I don't think the business really knows/cares what HTML you use, they just can reasonably trust people to implement stuff in the "right" way, which 90% of time is identify the correct HTML to represent the nature and structure of the design and build out from there. You'd expect things to "just work" when you are paying for front-end specialists.

Another thing to consider is that some design choices seem to be in contention whether they're accessible or not. Eg dark mode makes it harder to read with astigmatism and creates visual hallucinations afterwards (it looks as though you're looking through blinds). Others swear that light mode hurts their eyes.

I'm in that second group. I have an inherited, untreatable retinal disease that causes photophobia (light sensitivity) and contrast issues. When contrast is high enough for me to read text in light mode, total light emission from the screen is just way, way too high. When I can't wrangle something into dark mode, I usually wear sunglasses at my computer desk. I know of someone (my sister's friend) whose retinal disease makes her so light sensitive that she cannot comfortably look up at the moon when she's outside on a clear night with a full moon.

What accessibility demands all users have is neither light mode nor dark mode, but the ability to easily choose between them (and maybe other color or contrast options).

This is why accessibility is closely tied to hackability and customizability. There isn't one solution that works for everybody. Accessibility is about giving users flexibility and control in the way they access, consume, and produce content, etc., so that they can do so in ways that meet their specific needs. It's about user agency in the same sense as ye olde ’user agent'— and that's why it's something that should resonate with every hacker.