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.
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?
According to this, haven't both desktop and mobile Safari supported HTML5 form validation for about two years?
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)
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.
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.
They can use SSPI too, which is a generic mechanism to support other authentication methods:
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.
A business will likely never give explicit permission or budget for A11y work. Just like unit tests or e2e tests are rarely line items too. At my midsize consultancy we don't even mention it, we just bake it into the work we do. We find the time-- we make it work. It's our job. Writing inaccessible sites is kind of like building a car but ignore all environmental regulations. Your bosses boss might be ok with it, but should you be ok with it?
Think about all the work you do as a front-end dev that is not explicitly writing production code. You research libraries. You learn from screencasts. You read blog posts. You form complicated opinions about Redux. You have long code reviews. You agonize over naming. You can take similar care with accessibility. And lastly, it's not only important to be 100% accessible, it's also important to care and constantly improve. This a reminder to myself more than anyone else.
A11y is the second highest priority in the web sites I build. But I'm in the healthcare industry.
One not so dirty secret of accessibility has always been that it is not something you do afterwards, but that you have already done 80% of what needed to be done by just writing valid, standard compliant, semantic HTML.
So I would argue, if you really want to do something to make the web more accessible, usable and a generally nicer place, learn the tools of your trade. No, HTML and CSS are not so simple that they are not worth your time. They are easy to learn, true, but put in the time to get them right. Headings are an H tag, Navs are lists of links, paragraphs are p, not div. Easy stuff like that. And of course, CSS goes hand in hand with that.
You know display: none on a dropdown menu breaks accessibility, right? Of course it does, you tell the browser to not show the content. So use position: absolute; left: -999em or something. These are simple things you could and probably should know and if you do them, you already eliminated most of the problems.
Alt Tag on Images? Yeah, they are easy to forget, but they are also mandatory! So if you tend to be forgetful, use something like pink css borders around images that don't have them, so you won't in the future.
And for using tables for layout: There was a time, way back when, when css 2 was sparkling new and the young guys in the office bought a copy of Zeldmans "Designing with web standards" so the old farts would learn that the world was better now and we didn't need old crutches. If you are still using tables for layout today, you are not a web developer. Harsh but true. They got obsolete with float and position and you also have flexbox or css-grids today. I think you still actually don't need these for 95% of designs, but if you find them easier to use, please do!
And those aria tags or skip to content links? They are actually not the problem. They are icing on the cake. Include them if you like, people might thank you for them, but they also have had tools to compensate for these shortcomings for years, so they are not the real problem. Not displaying content properly or not at all without 500K of JS is, though.
So do something for accessibility and the web and learn the basics, it goes a long way to making you a better and more efficient developer and making the web more pleasant to use for all of us!
Yeah, it's screwed up, and god knows what the accessibility of these things is like because of it. Someone needs to start a Zeldman esque web standards push for that media too.
I actually felt HTML mails were finally coming along and getting better standard support until Microsoft decided to use Words engine instead of IE/Edge. Since then, all is lost on that front.
Chris is one of our users. Chris has a unique disability within our clientbase, and they work for a government department. There are two developers working on UI, and it would take me 3 man months to write code to make our product work for Chris. I am a founder so I have the authority to make our product work for Chris, but there is no external pressure on us to do so (not even by the government department).
The fundamental question that occurs is: should we invest 3 months working on functionality specific to a single person (Chris) or should we invest 3 months working on a feature that benefits all our users a small amount?
If you really can point to a specific user and define 3 months of work for that person to use the app then you're lucky. You really know your users, and you can determine exactly how much of a problem not supporting that user is. That's very unusual.
I think you tragically underestimate the variety of disabilities out there.
You think that less than 1 in 1000000 has a unique disability?
You think that there is no long tail of different disabilities?
And it really depends on the number of users you have. If you have 1000 users, and one of them is blind, then they are your Chris.
A key thing to consider is that a user with accessibility issues wants a solution that works on every website and every app. If you're thinking you need to spend months of time coding accessibility features just for your app, and expand that out to every other app, then clearly something is very wrong. That's why we have standards and best practises; if you follow them then your app will 'just work' with accessibility software.
And, as a very useful bonus feature, if you've written your app with semantic markup, a good information hierarchy, a contrast-y color scheme, and and a bit of thought then it'll also work better for every single other user regardless of their accessibility needs. It'll simply be a better app.
That doesn't eliminate the tradeoff, but it changes user stories. Maybe Amy is 25 in full health and not only that but pretty bright and a well-compensated developer at a FAANG company... but is going to suffer severe carpal tunnel and tendonitis before she turns 28. Maybe Brad is a 50 year old long time power user but macular degeneration is going to hit him hard in the next 5 years.
Maybe the group of people who will benefit from an accessibility feature is less narrow than it might seem at any given point in time.
We had #EEF as a subtle light-blue 5px resizer handle on a #FFF background. However the resizer handle was invisible on a newly unboxed monitor the other day (benq 32 inch 4k monitor) - because it was showing up as white on white.
It was fixed by replacing the HDMI cable.
I think the HDMI connection was dropping back to a lower bitrate. Screenshot, and displaying the screenshot on another monitor, showed that the blue resizer line was there but it was not being displayed correctly.
Unfortunately that only fixed it on that single computer. The correct fix would have been to use a different color.
I admit I am still unsure how to decide what is an acceptable colour difference in the face of both human issues and technological complications.
Google actually added a new 'AAA' contrast checker to Chrome 73 in the devtools ('AA' was already there). https://www.youtube.com/watch?v=uddZX9ZK6wY
The majority of apps and websites would fail the AAA test in heaps of places (unless they have a "high-contrast mode").
#F00 on #FFF: fail on AAA (pure red on white: contrast 4).
#07F on #FFF: fail on AAA ("iOS" button blue on white: contrast 4.13).
Accessibility as a right requires actions on the part of others - which means it comes at the expense of another's rights. Real Rights require inaction from others not action.
I explained how Google rank according to accessibility and how GoogleBot is the biggest 'screen reader' there is, so accessibility should be part of the SEO sales pitch.
The men in white coats from the local mental health hospital did not come and collect me but I did feel that this was the expectation, particularly for suggesting we bring a partially sighted person into the process.
The web is hampered by a visual design process that was necessary a decade ago when you did need to know what you were doing with non-standards-compliant browsers. However, a whole industry has built up around this process and mockups are never made from simple HTML documents structured with semantic HTML elements such as 'aside', 'section', 'article', 'nav' and so forth. What emerges from a visual design process always gets coded up with some allegedly 'agile' process with many 'div' elements and maybe a 'header' element thrown into the mix because someone on the SEO team has demanded it for SEO.
Fundamentally it is this visual led design process rather than mocking up the content with semantic HTML that is getting the div soup industry into this accessibility problem. If you mark up a document with the proper HTML tags and put it through the WAVE tool then it comes up good.
For instance, rather than using 'div' containers for images, if you use 'figure' then you can add a 'figcaption' in there. The 'figcaption' can describe the picture, e.g. 'my cats dinner' and the 'alt' tag on the img can be 'messy bowl with prawns in it'. In this way you can have 'what it is' and 'what it looks like'. What is there not to like from a SEO perspective? Never mind accessibility!
I hope that the work Google are doing with Lighthouse that flags accessibility can be brought in to actively down-rank websites that fail on this metric, with an upranking for HTML5 semantic usage where there is document structure instead of divs bloated with class tags from lame frameworks.
The guy defending unencrypted traffic got bullied and called names, and I stepped in but not to the amount of success that would have anyone from the opposing side acknowledge that there is indeed a case to be made for it. I ultimately cancelled my subscription, because I realized all the arguments had been repeated several times over to no effect.
Or, to put it another way, which is more important: letting a user who currently only has access to extremely old technology access any page on the site, or protecting (for example) someone suffering from domestic abuse when they access a page with details on how to get help?
In the end it’s a judgement call, but if you can argue your case both approaches are valid.
Do your remember any of the examples of such computers given?
I'm aware of the problem of no-longer-supported software too old to have added support for modern encryption, but I'm unfamiliar with this being a hardware problem.
The above comment seemed to be referring to older hardware so I was wondering if they were simply conflating bundled software (like pre-installed OS) or actually talking about hardware limitations.
While there is of course plenty of hardware that would be too limited for modern encryption, but I would seriously doubt anyone would be using it due to budget constraints (as in, these would more likely be specialised hw for niche embedded applications).
I don't want to say that modern JS frameworks aren't problematic, but I think they might only account for a small part of these bad numbers.
I know that Firefox has its accessibility dev tool tab, but I don't really understand it. It looks very technical.
Chrome has Audit tab which checks that the web page is accessible. Fixing the errors helps, but I still have no idea how screen readers or other assisting technologies show the page.
Why web browsers can't have accessibility mode which changes the web page to show only data that screen readers and other accessibility tools see. Replace images with alt texts, remove css layout and colors, etc.
Browsers have a mode to check responsive layouts for mobiles. They should have a similar mode for accessibility.
if they did, they wouldn't be able to shove advertisements in your face. What you're talking about sounds like Reader view, which Firefox and Safari sure support, but often times popovers and "You've read 3 of your 5 free articles.." garbage blocks you and prevents Reader view from working. I've had visually impaired users complain about this very thing.
1. Even if accessibility is somehow done, it's often for marketing reasons and just for the most visible part. A perfect example is Netflix. They make special movie description tracks for the blind, but they only do that because of public outrage. Their website in general is usable but it could be way better. The only big company that used to be different was Apple, but then Jobs died and they've gotten much worse. Still the best of the FAANG companies but much worse than before. For example, the accessibility of the coding app for kids is apparently amazing because they can use it to show off, but Xcode is apparently still very, very bad.
2. Accessibility is not just about disability. Denying access to people under a certain age, living in a certain location or even using a certain (non JS) browser is inaccessibility too. This is something the law actively encourages (particularly when age and location come into play). I don't think it should be the developer's job to decide such things. A perfect example here is BBC. They do a really amazing job at the "classic" accessibility, but their geo restrictions are horrendous.
3. If you really can't do the accessibility, fine, but don't actively try to make the job harder for others. Don't be Twitter, don't break your API for special clients for the blind that are much easier to use. Don't be the polish railroad company and don't actively change your API in such a way that the accessibility-focused third party app stops functioning. Don't be Amazon, don't lock screen readers out with all the piracy apps when designing your DRM solution. Not being able to do anything is acceptable. Being dicks is not.
 https://twblue.es https://twitter.com/euroblind/status/983246388216631296
Firstly, I'm suspicious of "big data" in general and any emotional interpretation of machine-driven analysis of that data. But who cares, let's look at the findings..
> 2,099,665 layout tables were detected compared to only 113,737 data tables
I'm calling bullshit.
First of all, they found 2 million tables in 1 million websites? That's ridiculous. But not as ridiculous as the claim that all those 2 million tables were layout tables. Come on guys, think about it. That's not happening unless the samples included "way back machine" versions of those sites.
Find me ONE website in the list with a layout table. I challenge you. There's no way that any site in the top 1000 is going to have layout tables or "abysmal"
This is "million-something" clickbait. Any time someone does something involving a "million" somethings, everyone stops what they're doing and looks.
Compliance is almost impossible for small teams. You can't rely on a lot of 3rd party code/widgets since many of them are non-compliant so now you require an in-house development team to recode a 3rd party widget to follow WCAG guidelines. Don't forget that you can't post any videos without transcripts! Transcripts cost money and time to create. So now people are simply denied videos altogether. 
These lawsuits have done far more harm to the public than good. Because they aren't focused on actually helping users, but turning a profit for some lawyer instead.
I'm the "go to" person regarding WCAG 2.0 / ADA within my company. I actually despise my job because I don't get to spend time making our websites more accessible to users but instead spend most of my time appeasing lawyers with too much time on their hands.
We've gotten a lot of mileage out of going nuts with "UX" and styling on the web. Maybe it's time to stop thinking about whether or not we could, and start thinking about whether or not we should.
Of course you gotta get the money folks and the designers on board or you're out of luck. A lawsuit or ten should do the trick. Though, yes, "this is bad give us money" is a place these complaints probably shouldn't be able to start.
Additionally I believe that if something can benefit people by simply existing it is better to have that thing than not have it at all if some small percentage of users aren't able to use that thing. For example, the Suicide Prevention Hotline website is not fully adhering to WCAG 2.0. I'd much rather that resource exist at all for those who may need it than to not let it exist because it doesn't adhere to WCAG 2.0
It's also very much accessible enough for actual people - but not quite "free from drive-by lawsuits" territory because it doesn't fully adhere to the guidelines.
Its clear these are not just "accidental" mistakes but people ignoring the problem wholesale. Commercial entities have responsibilities under the ADA. Yes it takes extra time and money to do it - so does designing in that ramp next to the stairs.
A little goes a long way here. It would be great if even just the alt text fields were filled out. Much easier than property developers have it.
The end result is appeasing 3rd party scanners like Powermapper without actually making the site any more accessible and in some cases making it less accessible. I've had to remove ARIA labels because Powermapper flags it as a problem for some screen readers. That's right. The markup we added to make the site as accessible as we could for screen readers was flagged as an issue and we had to remove it.
My job isn't to make websites more accessible because of these lawsuits, it's to put a stop to the lawsuits by any means necessary to the detriment of everyone. To quote my earlier post, I actually despise my job because I don't get to spend time making our websites more accessible to users but instead spend most of my time appeasing lawyers with too much time on their hands.
You can bet the construction industry has people in the room when standards are set on what sort of elevators and ramps are required.
These guys recently went through all the art galleries in New York City... Alphabetically. 
Nevertheless, web-related ADA lawsuits are on the rise: https://www.latimes.com/business/la-fi-hotels-ada-compliance...
[disclosure: I work for a company that provides services in this arena]
PO - "We need an alert dialog, just some text." Dev - "Cool, gimme a few seconds... and there you go, window.alert()" PO - "No it needs to match our styling and look exactly the same no matter where it's running." Dev — "sigh."
Meanwhile, a bunch of the most successful sites are ugly as sin. But whatever. I'm sure it's worth thousands of extra dollars (though not enough thousands to also match all the built-in functionality of the feature you're replacing!) to make the datepicker pretty, but break a11y and keyboard shortcuts.
The base platform is pretty ugly and feature-starved, though. Like, date/time formatting and conversion to the user's preferred TZ should be a built in to HTML rather than re-invented a thousand times in JS or server-side. Some basic table sorting feature that'd serve 90% of all needs ought to be built in. Maybe alerts could allow more styling while still being accessible and safe. The datepicker widget should be good enough that no-one feels the need to make their own—though to be fair I've still seen that crap happen on mobile, where the platform widgets are basically fine, though part of that was Android's fault for sometimes having god-awful datepickers depending on version and vendor. The default styling mostly is bad (alerts actually aren't too shabby these days, at least in some browsers, though). It's a crappy state of affairs.
If only a few big sites went "vanilla" then you can bet a browser that could "make them look nice" would become popular very quickly.
probably the least surprising part
12 years in industry across stacks b2b dev experience here. The word "accessibility" or
"disability" never even uttered out loud by developers, stakeholders or otherwise during every single project.
Maybe in like 50 more years it will be more common?
It's not just deadlines that gets a11y chopped off. It's not even remotely considered to begin with, unless a client demanded it specifically. Which never happened. Closest thing I've seen is internationalisation demands.
I've read sentiments and articles indicating that if you DO include good a11y support - these users love you. It garners massive loyalty, as one could imagine.
If you're a grunt serving in the lines? Good luck filling out a comment card after your desk-eaten 23 minute brown bag lunch and maybe the CEO won't fire you for the insubordination of suggesting work off of the most minimal track to $$$. I actually get anxiety sitting here thinking of how much trouble and internal political strife that would have caused in some places.
Businesses in the software industry care 0%. Negative zero.