Dear Developer, the Web Isn't About You
sonniesedge.co.uk
sonniesedge.co.uk
News flash: they're not. They're regular people with a variety of aesthetic preferences, some of which you would abhor. And for some of them, the accessibility features that you find clunky or inelegant are critical for their ability to read and understand your website.
The sales people didn't like it until he showed them how to pitch it properly to clients. Screen readers are a better reflection of how a search engine will read a site and so it was pushed as an SEO enhancement. Anecdotally, this was accurate from our research as well.
There's probably a couple thousand sites on the web now that are accessibility focused simply because of that one guy.
By designing for accessibility, you prioritize for both people with handicaps as well as machines. Think of machines as really really fast visual handicap readers.
And avoiding lawsuits is just a big plus as well.
And you would also have to have at least 15 full time employees to even be included in ADA requirements.
To some extent developers are a product of their customers' demands. If customers are emphasizing dirt prices ($200 websites what the hell is going on?) and launch deadlines of "a couple of hours", they aren't thinking about accessibility, along with a half dozen other things.
It's really become evident to me since web development became a focus of my career, that people remain blissfully unaware of those less fortunate than them. Which we should shame out of them in my respected opinion.
At the very least, all visual elements should include an alt tag.
Making your content "readable" is a good idea anyway.
One last thing, and sorry such a long comment, it occurs to me maybe a lot of websites aren't "accessible" because things like Alt tags would expose the manipulative subliminal tactics of the design.
This is how many people think about accessibility, especially starting out (myself included). An alternative framing is to realize that some people have permanent disabilities, some have temporary disabilities, and some have situational disabilities.
For example, about 15 percent of people have dyslexia. They have a more-or-less permanent challenge with reading. In the second category are people with temporary reading challenges. Someone with a concussion, stroke, or other traumatic brain injury often have similar reading challenges, that sometimes (but not always) can get better over time. And in the last category, we have people who have situational challenges, such as "I'm on in the subway and the car is moving in 3 axes and I'm trying to read on my smartphone". This is a situational challenge, but a challenge nonetheless.
If we focus only on the first category of people, the group who might be assisted by a reading-related accessibility feature seem relatively small. But when you realize that there are also temporary and situational challenges that can be ameliorated by the exact same feature, then it becomes clear that the number of people who can be helped is actually much greater than originally appeared.
Ditto for "wheelchair ramps" that are used by people with strollers or crutches for broken legs.
Rare? "Disabled" people are so common, politicians bend over backward to cater to them at the expense of others. An entire organization is devoted to service them: the AARP, where "RP" stands for "retired people". Because many over 50 are going to have a hard time reading your tiny-print, low-contrast, gray-on-light-gray website.
"Accessibility" != ("make exceptions for disabled people" WHERE "disabled people" == "protected class"). "Accessibility" means a lot of things. Maybe it's color-deficient sight ("color blind"). Maybe I lost hearing in one ear because of a tragic toilet lid accident. Maybe I'm just over 40 and wear reading glasses. Just because a user might not have a handicapped placard hanging from their rear view mirror doesn't mean they don't find your "innovative" design annoying.
This is a completely misguided notion. There are many types of disabilities out there, some can be apparent to the outside observer (physical disabilities) but there are many which are not apparent (mental and sensory disabilities).
1 in 12 men and 1 in 200 women throughout the world are affected by colorblindness.
Epilepsy affects 2.5-3 million individual in the United States.
Hearing loss and vision loss will affect most individuals during the course of their entire lives.
These disabilities and others are all considerations relevant to web and software development, with so many affected populations throughout the world disabilities are much more common than you or I might perceive.
But it's really not a question of perception among developers. Accessibility guidelines are relevant to some industries more than others, enforcement is sparse. If it became necessary to support all users and take into account their accessibility needs then we would see a change in the marketplace. The short answer is that developers and product managers who do not take accessibility into account with their products are lazy.
> It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
> Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
> Jut how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
HTML isn't "run" in the way traditional compiled languages are. It's modular by design, so of course you can tear out parts and have it still work. And the way you're tearing out things is exactly on these module boundaries; if you really wanted to pull stuff out you'd do it at a random location so you get tags being cut off.
I think she makes a lot of very valid points, Web 3.0 is abandoning its foundational robustness for ... whatever the hell js dev is nowadays.
Sure, that's a nice way to put it. If you remove data from it using its normal contract, of course it's bound to behavior reasonably well. If you go and take a linked list and start zeroing out random bits of a node's next pointer, of course it isn't going to work, and the same is true with HTML.
The browser engine is meant to be as minimal as possible, and could be easily replaced by a native browser function that ingests JSON to display pages. CSS still works normally, and the engine has a variable system to add flexibility to CSS - you can specify several CSS styles as a variable, then just use the variable in the class field of the HTML element you're describing - the browser engine will replace the variable with the several styles on page build.
These are written in JavaScript because it's the only language that runs in major browsers. Were other languages available in Chrome, Firefox, etc, this might be better in another language.
Websites should be easier to build, faster to load, more robust and stable, while being smaller in memory. But going back to 1997 technology isn't the answer.
Sure, there are some developers who don't get this, but in every case where I've seen this debated, it is only developers who are in favor of accessibility, core HTML that works without JS, etc. There is often a debate or division among developers, but there is a non-zero number of developers advocating this.
There have been, in numerous different organizations (educational, startup, big corporate) where I have worked, zero management support for any of this. Also, zero client support. These ideas typically die, because nobody but a (sometimes lone) developer is advocating for them, and they can't win the argument.
Again, I 100% agree with the sentiment, and I'd love it if the web changed to work like this (again). But the obstacle is not developers, primarily, or at least they are the group (in my experience) most open to this argument. It is absolutely everybody else in the conversation (client, sales, management, design) who doesn't want to spend time or thought on it. I don't know how to solve that.
If someone has experience succeeding at that, I'd love to read that post.
A lot of developers nowadays default to using a SPA as the starting point for everything without even considering if they actually need the whole bouquet of fronted build pipeline, innumerable dependencies, reactive something and a dozen layers of abstractions to hardly do more than loading and turning JSON into html while showing a spinning thing.
Sure, there are plenty of features of frontend frameworks that come in handy. But how often do devs truly analyze what the best tool for the job is vs. chasing after that shiny newthing.js which just came out.
1. Developers want their CV/resume to look good for the next job, and the best way to do that is to have a bunch of fancy technologies and frameworks on it. Going for what's simple and works best is great, but unfortunately not something recruiters (especially at large tech companies) care much about.
2. They're used to that one language or framework, and hence think every single problem under the sun should be solved with it. It's the old 'when all you have is a hammer' issue, and endemic in every company from the small agency to the large tech corporation.
The hilarious irony here is that supporting all devices is a contributing factor to the "problem". Yes, I want to support older versions of IE, mobile devices or whatever browser you're using. Frameworks like jQuery (or babel...) exist because of this.
It's only been in the past few years that sites have started to work relatively well between mobile and desktop formats without a separate mobile site.
This is how you make stuff on the web.
Not sure if I agree with this. Ideally, this would be the case, but the tooling and dominant platforms just aren't as mature as they would need to be to consider it a required core skill. Doing Accessibility work feels like doing CSS work back in the late 90s. The dominant target platform, JAWS, is just a horribly coded product. It kinda, sorta, handles ARIA attributes and it kinda, sorta, does the same thing each time a page is loaded, but then also doesn't.
And it's a very expensive tool. The "pro" version, which is the only version approved for dev work is $1100 (outside of the extended 90 trial for $179, I guess). Now consider that not only do your devs need copies, but so do your testers. And if they want to stay up to date, you're really looking more like $1100 + $550 a year. And, yes, there's other options, but since a lot of accessibility work is really more for lawsuit avoidance than anything else, not going with the industry standard isn't a wise choice.
And, after all of that, unless you work someplace with enough funds to properly test out your product with, you know, actual users with visual impairment, what qualifies as good accessibility is difficult to suss out. You can run automated tools, but they're just code linting tools, more or less, and really speak nothing to the user experience. How do you really test out the UI you've developed? If you close your eyes or cover the screen you still know exactly what it looks like.
Which brings us to one of the author's other points: Not everyone is rich. There are many solo web developers who simply don't have the resources available to make their website accessible. Do we (in the U.S.) need an ADA for websites? We essentially applied it to government websites, but my personal blog doesn't have to be compliant.
Regulation of that nature would have an immediate impact on solo and other small web developers, just like GDPR. Perhaps it's necessary, though, so that we aren't excluding wide swaths of people from having equal opportunities on the web.
Edit: Note that certain interpretations (including court opinions) of ADA apply the public accommodation concept to business websites. I'm not aware of such an interpretation for personal websites as ADA would probably not apply.
All HTML and JS documentation is available gratis, and every operating system is distributed with a text editor.
<html>
<head>
<title>Accessible Web Page</title>
</head>
<body>
<p>This is an accessible web page.</p>
</body>
</html>
Making an accessible website is simple as dirt. It will just look dated to people who don't need to rely on the accessibility features of their browser or OS. It may even "look" dated to people who use screen-readers.
My interpretation of "resources" here would be time / money. Making sure a site is accessible by everyone takes effort which is difficult to justify, particularly if you're already stretched to capacity.
The ADA was drafted to force physical businesses to make reasonable access a higher priority. Accessibility has the same time/money costs as any other feature. The same goes for internationalization and localization. Or for robust user data protection and security. The longer you wait to consider doing it, the more it's going to cost you.
Of course, I've worked in web design, so I know the workflow doesn't really allow you to do anything right from the beginning. Things get hacked up, and accessibility is sacrificed.
A small business doesn't have to spend money developing tooling and a framework to, e.g., make asynchronous database calls and update page data without a refresh. The community developed that because the community cares about it. The community has shown significantly less caring about persons with disabilities being able to use websites. If the developer community had developed the accessibility version of AJAX we would use it just like we use AJAX.
[1] https://www.adatitleiii.com/2017/07/doj-places-website-rulem...
Then incent a generation of 19 year olds to fix that, rather than build yet another JavaScript library dependency resolution tool. I think she is spot on: the tooling and libraries are weak because the developer community just doesn't care.
I agree that the community should care but am not at all surprised that hardly anybody does. There's no incentive to do so.
I'm not saying it's solely on businesses to make people care. They don't have the incentives, either. This is where regulations might've helped.
Well, the incentives to do so aren't obvious.
Having worked on a bunch of (a) web applications with no dynamic client behavior to speak of (b) SPAs that are essentially a dynamic client talking to a service layer speaking JSON and/or XML (c) things in between... I think I've noticed a pattern, and it's that web applications where people take the time to think about how things would work with no dynamic client behavior, going through a process that more or less represents domain logic as HTTP operations on resources that can be represented as HTML (among other representations), these applications end up being more legible over time than projects with client engineering/experience as most of the focus.
Not all applications fit this model, so there are limits to the approach. And accessibility is a somewhat different domain.
But the concerns overlap, so one tl;dr might be this:
Site accessibility is one canary in the web application mines. If it's dead, you might be accumulating technical debt.
https://webaim.org/projects/screenreadersurvey7/#used
And mobile use of screen readers has massively grown just as mobile web traffic has grown.
https://webaim.org/projects/screenreadersurvey7/#mobilescree...
There's a lot you can do without firing up a screen reader. Try to use your site without touching the mouse. Don't waste your time or someone else's if you can't complete tasks without the mouse even with your vision. Visual indication of focus is something you need anyway and not necessarily discovered by screen reader testing (though using a screen reader and screen zooming together is common).
JAWS 66.0%
NVDA 64.9%
VoiceOver 39.6%
Source: https://webaim.org/projects/screenreadersurvey7/#used
It reminds me of a quote by Obama: "Government will never run the way Silicon Valley runs because, by definition, democracy is messy. This is a big, diverse country with a lot of interests and a lot of disparate points of view. And part of government’s job, by the way, is dealing with problems that nobody else wants to deal with."
What are people recommending for progressive enhancement these days? For sites that don't need a whole lot of js, but enough that just slapping on a bunch of jquery lines would get too messy.
E.g. when you want to support sorting tables or saving forms without reloading the whole page. In other works, using js merely to make the experience smoother. Besides the points mentioned in the talk, setting up and maintaining a build pipeline for a fronted framework and maybe even server side rendering with it is just a vast overkill and unnecessary increase of complexity for the given problem.
I used to use backbone.js for those kind of sites, because its view layer worked pretty well on already existing html and letting you fallback to it, while giving you more structure and modularity than plain js/jquery.
One example, scrolling table with fixed table head. Why is that not something I can specify declaratively? Why is that next to impossible, even with the aid of JavaScript.
Where are tabs? Where are image carousels? Why is it that styling forms elements is still essentially impossible? Where are <select> elements with icons? Where are calendar date pickers that allow me to select multiple dates and ranges?
Why was three columns with header and footer declared the "Holy Grail" of CSS for a decade? And does anyone remember building rounded corners with <b> tags?
Basic basic basic structures that literally every developer is asked to build don't exist. Every developer everywhere has wasted ridiculous amounts of time making something barely functional which should have been stupidly simple.
You can:
tbody {display:block; height:50vh; overflow:scroll;}But I see interesting stats in my network panel:
HTML - 33.25K
CSS - 65.89K (the bulk of which is Twitter, which looks to be the same stylesheet loaded multiple times; 3.2K without Twitter)
JS - 53.62K (it appears all of it is Twitter)
Images - 658.75K
Media - 206.12K
Stop using Twitter's code and build for users turning off images/media gets you a half-decent loading website.
If you are building a content delivery vehicle, this all makes sense.
If you are building an interactive application, the html paradigm is terrible and we took it as far as we could. We really need to get away from HTML but that's going to require leadership.
I recently went back and wrote an application with JavaFX. It's quite a bit easier than dealing with the fiddly bits of HTML, CSS, and JS.
Web applications are terrible because we build on terrible abstractions for the purpose of applications, JS being the least worst of them. That's why we end up as an inverted pyramid.
design, bells and whistles, brand identity, tracking, ad-hoc A/B testing, banners, newsletter interstitials, page rank, comments on brand's facebook page, number of followers, claps, likes, thumbsups, reblogs, autoplaying videos, filler stock photos.
If we think of websites not related to work. How many of those would the average person view per day? 5-20 ?
I guess her previous post [2017] testing "mainstream" sites without Javascript is worth a mention:
> Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run. Jut [sic] how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
Yeah, because HTML isn't a programming language, and it's not related to whether or not the browser can render some site. It has nothing to do with the code in the browser's sanity or the server serving content. The more accurate analogy would be "Could you imagine pulling random chunks out of a string that was passed to a string manipulation function, and the function still completing?!" And the answer is yes, I can imagine that. Especially considering it is a mundane fact of life for most web developers. It's almost like the author doesn't fully comprehend the difference between a markup language and a programming language.