
The Web We Broke - joe5150
https://ethanmarcotte.com/wrote/the-web-we-broke/
======
gambler
_> 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.

~~~
ergothus
> 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?

~~~
chipotle_coyote
_If Apple would stop being a problem I still retain hope that HTML5 form
validation could actually be common._

[https://caniuse.com/#feat=form-validation](https://caniuse.com/#feat=form-
validation)

According to this, haven't both desktop and mobile Safari supported HTML5 form
validation for about two years?

~~~
robocat
> Apple would stop being a problem

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)

------
gorpomon
As a front-end dev, I'm trying to bake this into my process as much as
possible. I am only around 20% of the way to that. Last year I focused on
baking in testing into my process, now I'd like to do the same for
accessibility. Big ups to Google for making Lighthouse an easy to use tool.

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.

~~~
reaperducer
_A business will likely never give explicit permission or budget for A11y
work._

A11y is the second highest priority in the web sites I build. But I'm in the
healthcare industry.

~~~
gorpomon
Yep, definitely industry specific. I'm currently working in manufacturing, so
on the other end completely.

------
Grumbledour
This is sad, but in no way surprising. It has the same root cause as many
websites misusing javascript to a point where they become unusable, and that
is people not really knowing how to use the tools they are given.

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!

~~~
CM30
Well, tables for layout are necessarily in one very specific case. Namely,
coding HTML emails, where CSS support is pretty horrible and (for some reason
only known to them), Microsoft decided that they'd use Microsoft Word's
rendering engine for Outlook.

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.

~~~
Grumbledour
Yeah, HTML emails are really a sad state of affairs. So many basic CSS things
wont work there consistently. You don't need to even think about position or
float when you got trouble setting colors.

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.

------
robocat
Drew is one of our users: Drew is 70, with poor but functional eyesight, and
they have shaky hands. I try to ensure our product works for Drew because many
other users are on a spectrum with similar problems.

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?

~~~
buboard
at least make sure your buttons have a slight border and that u re not
rendering #eee text over #fff background. usability issues are usually just
small changes to the UI, not something that will disadvantage all users a
small amount.

~~~
robocat
Totally agree. And a non-human issue with your example:

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.

~~~
onion2k
_It was fixed by replacing the HDMI cable._

Unfortunately that only fixed it on that single computer. The _correct_ fix
would have been to use a different color.

~~~
robocat
I agree.

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.

~~~
onion2k
There are tools out there -
[https://webaim.org/resources/contrastchecker/](https://webaim.org/resources/contrastchecker/)

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](https://www.youtube.com/watch?v=uddZX9ZK6wY)

~~~
robocat
I just tested that on pure red, and iOS button blue, on a white background.
They both fail the AAA contrast test (on WebAIM and Google devtools).

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).

~~~
onion2k
Yes. 'Pure' colors tend to be bright, so white text doesn't contrast well
enough. As a rule, designers don't use the pure color. I suspect lots of sites
get accessibility wrong because developers prioritize using nice round numbers
(eg F00 rather than D00) instead of accessible colors.

------
Theodores
Once I suggested we get a partially sighted person help with recommendations
for clients, the goal was to get more business in as a client might need a
site rebuild if it is deemed bad on the accessibility front.

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.

------
euske
One of the strategies that I'm thinking of to advance accessibility is to tout
it as a way of cost-cutting. Blasphemy! How? Well because the major pain point
I see in a11y is _over-designing_. Managers are being a control freak on the
UX and designers are already overwhelmed by the newer features and ever-
changing requirements and standards. Just give it up! Go back to a website
with simple features and focus on what actually matters - clarity, relevance
and easy workflow. I don't know if this works for other people but this is my
take on a11y issues.

------
pvorb
Often, HTML is not hand-crafted by developers but created by content authors
in WYSIWYGs or generated from markdown. Of course developers could find ways
to force content authors to write accessible content, but most content needs
to be cheap, so people will always find ways to take shortcuts.

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.

------
mar77i
Around last christmas there was this long discussion on a mailing list I
followed about people being unable to access websites because their computers
were too old to reasonably run modern encryption algorithms in browsers. Much
of the internet is pushing for https-only access, which, it would appear,
locks out an entire bunch of end devices of perfectly healthy, yet not very
wealthy people.

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.

~~~
lucideer
> _their computers were too old to reasonably run modern encryption algorithms
> in browsers._

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.

~~~
robin_reala
Android 4.0 and earlier has no TLS1.1+ support, and both Firefox and Chrome no
longer support it.

~~~
lucideer
Yeah, exactly. These are software limitations in Android.

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).

------
gardaani
I would partly blame the web browsers. They should have better dev tools to
check that pages are accessible.

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.

~~~
jrnichols
> 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.

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.

------
buboard
this looks like something that a trained AI can solve: recognize the
meaningful parts of a page and adapt it to the user's needs. just like with
every web standard, technology and hype made those accessibility tags obsolete
very soon.

~~~
rchaud
This would be a good use case for AI. Unfortunately the implementation right
now is pretty poor, at least when it comes to MS PowerPoint. When I add an
image to a slide deck, PPT automatically attempts to add a caption with its
best guess of what the image is. 90% of the time it says "An image of a cell
phone", and I have never once added that image.

------
miki123211
Blind guy here with some thoughts:

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[0]. 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.[1] 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.[2] Don't be
Amazon, don't lock screen readers out with all the piracy apps when designing
your DRM solution.[3] Not being able to do anything is acceptable. Being dicks
is not.

[0] [https://www.theverge.com/2015/4/14/8413569/netflix-
daredevil...](https://www.theverge.com/2015/4/14/8413569/netflix-daredevil-
audio-descriptions-now-available)

[1] [https://twblue.es](https://twblue.es)
[https://twitter.com/euroblind/status/983246388216631296](https://twitter.com/euroblind/status/983246388216631296)
[2]
[https://translate.googleusercontent.com/translate_c?depth=1&...](https://translate.googleusercontent.com/translate_c?depth=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=https://www.dobreprogramy.pl/Moj-
Pociag-nie-dziala-przez-PKP-PLK.-Kto-ma-racje-w-sporze-o-
rozklad,News,80382.html&xid=25657,15700023,15700186,15700190,15700248,15700253&usg=ALkJrhgAugslXaeq9NoZtcMTdD2d0CS1VQ)
[3] [https://github.com/smythp/blind-hackers](https://github.com/smythp/blind-
hackers)

~~~
leoc
It seems that more public pressure on Apple might make a difference here.

~~~
miki123211
No no no. Public pressure doesn't work that way. If you make public pressure,
Apple will fix the few isues the public was outraged about and leave the
invisible rest untouched. That's "marketing accessibility". The impressive,
very visible and not that useful stuff is usually accessible, the invisible
nitty gritty details of some settings dialog burried deep in the application
that you suddenly need aren't. Even if it is accessible, this kind of
accessibility done because of regulation or marketing can be horrible, see
Google Docs. Is it useful? yes. Is it extremely verbose, speaking too much
when the user does not need or want it? Yes. Is it completely unlike what
blind people are used to? Also yes. I can elaborate more and provide examples
if interested.

------
exodust
I have doubts about the validity of the findings.

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" accessibility.

This is "million-something" clickbait. Any time someone does something
involving a "million" somethings, everyone stops what they're doing and looks.

------
jdsully
Are ADA lawsuits not applicable to the web? It seems a financial incentive is
the only way to really resolve this.

~~~
Nadya
They are and there have been many _rather bullshit_ drive-by lawsuits in
regards to them too. With no leeway to give you time to fix the problem
either.

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. [0]

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.

[0]
[https://www.insidehighered.com/news/2017/03/06/u-california-...](https://www.insidehighered.com/news/2017/03/06/u-california-
berkeley-delete-publicly-available-educational-content)

~~~
asark
> 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.

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.

~~~
Nadya
The end result of that is an internet ran by businesses and large corps
capable of _affording_ to be on the internet. Ma & Pa shops and small
restaurants may not be able to afford to have a website, which could be enough
to put them out of business.

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.

------
jacquesm
Without regulatory action this will never happen. There isn't any money in it
and so the laws of capitalism more or less push towards ignoring the issue
until it can't be ignored any longer because there is a price attached to
that.

The annoying thing is that the web was made with accessibility and
screenreaders in mind, your typical javascript powered piece of shit one-page
application is a nightmare for screenreaders and other kinds of accessibility
aids. And this is getting worse over time, when form trumps function and pixel
perfect placement of text is more important than the text itself there is not
much hope for self-governance.

~~~
asark
Part of it's the platform's defaults, part of it's every product owner and
designer thinking every part of their "experience" needs to be some special
snowflake crap.

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.

~~~
r_c_a_d
There is a bit of a chicken and egg problem here. As long as most of the
popular websites are styled to extremis so that the users think they look
nice, then there is no "market" for browsers and/or plugins that have features
like sorting tables and "nicer" default styling in general.

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.

------
NeoBasilisk
>Pages containing popular JavaScript frameworks were more likely to have
accessibility errors than those that didn’t use those frameworks.

probably the least surprising part

------
jhare
More work is put into bogus GDPR cookie warnings no one cares about.

~~~
arvinsim
Not complying with GPDR is a legit threat to a company's bottom line. A11y
much less so.

~~~
detaro
Depends: for a company operating purely in the US/outside Europe, an ADA
lawsuit, or customers from fields that have a11y requirements not buying their
product, seems more likely than GDPR fines. At least for now, there's little
indication of GDPR tools being even attempted against companies not explicitly
doing business here.

------
draw_down
Everywhere I have ever worked, accessibility is 100% an afterthought if it
ever even came up at all. In the places where people tried to do something
about it, it was never a business priority or explicitly given resources; just
something people did out of the kindness of their hearts. And I think that's
the whole story. If you want this to change, press on companies to build this
in as a concern, the way they should do with performance, security,
localization, and whatever else.

~~~
jhare
Exact same experience.

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.

