> ARIA, the language created to help make interfaces more accessible, was found on more than sixty percent of the home pages surveyed. Unfortunately, those home pages were more likely to have detectable accessibility errors.
> Pages containing popular JavaScript frameworks were more likely to have accessibility errors than those that didn’t use those frameworks.
This was obvious to me all along, but it's nice to have official statistics on this.
I would like to use this opportunity to point out the astounding hypocrisy of front-end developers who claim to be in favor of better accessibility, but then vehemently oppose the idea that HTML should have built-in component that cover basic web use cases without the need for scripting.
Sure, getting controls "right" in browsers is hard. But hoping that all web developers get them right when choosing/writing their own implementations of everything is absolutely hopeless. Accessibility should be the reasonable default you get "out of the box" when not doing something overly fancy or stupid.
> front-end developers who claim to be in favor of better accessibility, but then vehemently oppose the idea that HTML should have built-in component that cover basic web use cases without the need for scripting.
Is this a thing? (specifically that the front-end devs are the problem) I'm a dev with plenty of front-end experience, but back in the day I was sad when login pages became a thing (as opposed to built-in browser authentication), and frankly if Apple would stop being a problem I still retain hope that HTML5 form validation could actually be common.
The problem has always been (in my experience) - when browsers provide an insufficient/notably unfriendly experience (no means of managing forgotten passwords or registering logins, for example), when browser vendors refuse to play ball (IIS/IE only supported BASIC authentication, for example. Today Apple is the hold out on HTML5 validation), and/or when designers want to be "different" or have a brand that is consistent across platforms (despite those platforms having their own conventions).
Usually the front-end _devs_ want things to work with minimal effort. It's only when they are asked to do things the browsers won't do that they/we waste time rolling our own reinvented solutions.
When you run into yet-another-page that screws with how scrolling works - do you think the front-end _dev_ wanted to work on that bug-ridden task?
The amount of work Apple has put into making iOS accessible astounds me. Apple are not the bad guys here from what I can tell... (Disclaimer: I usually go Android, but iOS kicks Android's arse on more than one feature IMHO)
Wow! I haven't checked in about 3 years - last I heard they had basically shrugged it off and weren't intending to change. I'll have to check this out - if correct, I'm that much happier.
If I go through this post https://news.ycombinator.com/item?id=19367149 (A JavaScript free front end, which was on the front page a couple days ago) it seems to me about half of the comments are devs arguing that JavaScript is a better solution for page interactivity than HTML and CSS.
The 'better' varied between arguments that it was easier to debug JS, easier to maintain, and when I just looked at it now it seemed someone thought that a JS solution would be more accessible (although the argument seemed to acknowledge people needed to do work to make it accessible)
Anyway, if we agree that JS is more difficult than the other technologies named it sort of follows that more money will be earned by solving things with it, and someone once said something about the difficulty of changing someone's mind when their livelihood depends on maintaining the opinion.
Note - I make most of my money solving things with JavaScript nowadays.
If you know what you are doing it isn't needed. You can solve nearly 60-70% of accessibility issues by writing good HTML. For most of the rest having a simple understanding of CSS and JavaScript events with concern what constitutes a disability you are probably ok.
Personally I often try to avoid ARIA. ARIA is generally there to complicate for problems in the interface. If you solve for those problems directly you don't need ARIA. The role attribute is an exception though, because its always helpful.
There are always edge cases, but if you avoid stupid marketing trickery and understand the web standards you are probably safer than that supposed JS ninja spinning their favorite framework bullshit.
The Microsoft world has always had some pretty advanced yet somewhat obscure stuff --- a shame that they're not more well-known. Other examples include MSRPC (through which you can do SSH-ish things), WMI, everything Active Directory, etc.
> Pages containing popular JavaScript frameworks were more likely to have accessibility errors than those that didn’t use those frameworks.
This was obvious to me all along, but it's nice to have official statistics on this.
I would like to use this opportunity to point out the astounding hypocrisy of front-end developers who claim to be in favor of better accessibility, but then vehemently oppose the idea that HTML should have built-in component that cover basic web use cases without the need for scripting.
Sure, getting controls "right" in browsers is hard. But hoping that all web developers get them right when choosing/writing their own implementations of everything is absolutely hopeless. Accessibility should be the reasonable default you get "out of the box" when not doing something overly fancy or stupid.