Hacker News Reader

Comment by antihero | Hacker News Reader

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service.

The vast majority of users will have even a rudimentary smartphone (some years ago I visited the Calais jungle to donate food and supplies, and whilst people were struggling to eat, they knew that a smartphone was a cheap, key thing to obtain and hold onto because they make accessing help and communicating with their support network possible) and or laptop that can handle some lightweight JavaScript and benefit from an enhanced experience.

View on HN

I don't think the problem is that niche though. Even outside of accessibility concerns, there are plenty of times I've tried to use websites on smartphones within intermittent internet access — e.g. on the London underground checking in to a flight on the way to the airport or ordering a pizza when coming home late from work.

In both scenarios, I'm trying to complete my task as quickly as possible while I still have a good connection. A simple HTML page (with JS layered on top for fancier stuff) would be plenty to get the job done. Instead you get hindered by sites that aren't optimised in any way for slow devices or slow internet.

Heard that Facebook before had "2G Tuesdays" where the product teams throttled their internal net speeds to 2G while browsing the site to see what it was like — that should be the standard for dev teams. The trouble is so many things are designed and tested by people on T1 broadband in a downtown office, but that's not the set-up of a majority of their users.

Sidetrack: Is T1 still ~1.5 Mbps or is it referring to something more modern nowadays?

It's still 1.544Mbps. That use to mean you were at a university or something, but now seems to mean you can't get DSL in your area.

> so many things are designed and tested by people on T1 broadband in a downtown office

I wish. A T1 is 1.5mbit. CNN's front page is 6MB - 30 seconds at full T1 bandwidth.

Maybe try https://lite.cnn.io.

I can't remember exactly how much it was, but within the last year, I ran out of cellular data and my "unlimited" plan dropped back to a lesser amount of bandwidth, but still what used to be broadband. However, I literally could not load any website I tried. However much it was, it was way more than dialup. It seemed to me like there was no point in a soft cap, if one can't even load the website to change plans.

I would hazard a guess that it was 2G. And yes, it's absolutely infuriating that so many basic services (which used to be implemented just fine on 2G speeds (or less!)) no longer remotely function without LTE.

Perhaps they forgot to disable 2G on their servers /s

I think this is an exclusionary mindset. Just because it is a tiny subset of users, it is OK to exclude them?

How about when it is quite easy in many cases to support them, by using standard conform simple HTML?

Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is supposed to give you security, I need to allow scripts, to have a login. Otherwise there is only a background picture. Thank you very much, so helpful! And then when I allowed their scripts, guess what. A text became visible, which told me, that in general scripts need to run in order to use the page. How much fail is that? They don't know the noscript tag or something?

That's only today's anecdote. I see this kind of fail every day, except for the days, when I miraculously manage to avoid all badly designed websites. It is getting worse and worse, because web developers seem to find it normal to, by default, reach for JS, instead of thinking about how they can solve the same thing using just HTML and CSS for a second or two.

I think it is still worth pursuing simplicity in web development. For the earlier example: Rendering a login using JavaScript is not simplicity. It is unnecessary, silly, and exclusionary without need.

So my message is: If your service can be done using plain simple standard conform HTML(5), then use it. It will also almost always have less bugs and be simpler code to maintain. Information display does not require dynamic pages per se. Usually it does not and many many websites are about information display, not impossible to solve via REST dynamic pages. Nowadays properly designed static websites are faster than badly designed JS heavy websites, which render on the client-side. The bloat has become this bad already.

> Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? ... They don't know the noscript tag or something?

This is often less about the developers not knowing a technique and more about the constraints they're working under. Maybe there's a third party auth library they're using that requires JS. Maybe either they or or their management have other priorities than removing JS from the login screen. It's not that hard to believe that scriptless login would fall fairly low on a team's priority list behind features more likely to drive revenue, etc.

That doesn't explain the lack of a noscript message, which is the difference between "we really need you to turn on javascript" and "as you can plainly see, our page is broken".

I think reaching for JS is often a reflex because we want to avoid delving into building backends that aren't a simple REST API. If you stick to HTML and CSS you need to start building pages and managing state server-side, which a lot of people don't really want to do.

Even cheap, old smartphones support JS. You can have fast, efficient JS.

> You can have fast, efficient JS.

You know... this is true. I know this is true, because we had JS 20+ years ago on Pentium processors. It's possible to write JS that doesn't require multiple cores on a 2019 Ryzen...

But there are also the other sort of sites. You know the ones. Take a stab at which is more prevalent, and receives the majority of ire =[

Making things more accessible rarely has a downside for folks who don't need it in my experience, and often has an upside. My favorite example is doorknobs - think of a round doorknob vs one with a lever. People with broken/missing fingers/hands or fine motor impairments will have a much easier time opening a door with a simple lever vs gripping and turning a round doorknob, and so will a person with two fully intact hands who is also carrying groceries. (edit: corrected italics)

In the US, we collectively decided (via elected representatives) that this is important to us, and we passed the ADA to enforce it. Visually impaired people have as much right to use stuff as you and I do, and the law says so.

From a purely economic point of view: if your competitor's website supports the visually impaired, and yours does not, then even though that's a relatively small market segment you're probably giving away 100% of it. And blind people have friends and family too, and they'll also send all of those people to your competitor.

Do you have an example (outside of a niche, like a site catering specifically to some disability) of the economic argument working? Because the obvious economic counter argument is that while you work on accessibility your competitors work on features for the 90+% rest of the population.

In my opinion it's why it's especially important to have regulations here, free market won't save us because in most cases the ROI just isn't there. However this is wrong to abandon those people, thus we need incentives to force people to do the right thing.

Heh, not directly, but...

Once upon a time, a younger engineer worked for a company that dealt with the DOD. The DOD wanted to upgrade their website, and as often happens, the lowest bidder was a giant company who could blacken the sky with lawyers. They worked and worked, and their deadline slipped. Finally, they made something that kind of worked, sort of, as long as the wind wasn't blowing too hard.

The younger engineer noticed that the new DOD website served webpages via carrier pigeon, but with more latency. As in, page loads often took minutes. He proposed to the lord of his domain: "your majesty, what if I crafted a robot to visit all of their pages and enscribe their lore into our own tomes, such that when your customers want the information, we can give it to them in milliseconds, and not minutes. Oh, and I can make the robot labor only at night lest the DOD get persnickety." The lord gave his blessing, and the younger engineer went away and made The Thing.

The Thing worked wonders, and there was much rejoicing among the many kingdoms. But lo, the DOD was not happy, for it made their contractors look as though a pack of jackasses. And so they sent a sternly worded missive: "cease at once, knave, or we shall cut you off from the river of nectar for all of time!" And the younger engineer's lord's voice quavered, for he knew that his own kingdom would starve if this were to happen.

But the younger engineer was cleverer. He noticed that the DOD's website could not be perceived by those who could not see, but his own website was beautiful to behold by both the sighted and those not. He proposed a plan to his lord, and his lord giggled for the plan was good and clever.

The lord sent a missive of his own, both to the Maker Of The Website and the DOD, saying:

"Alas, your own website cannot be perceived by those without sight, as are some of our customers. Our website can be. If you go away and stop sending threatening letters, our customers have agreed to behold the riches of thine data through our site as a proxy, and not file a lawsuit with an injunction that shall turn your website off tomorrow until you spend a few tens of millions of dollars fixing it."

And the Maker Of The Website shut the hell up about it, and the DOD formally approved the plan, and all were happy.

Except for the Maker Of The Website, of course, but lo, they were as though a pack of jackasses.

The younger engineer was celebrated, then moved away to distant lands with better pay.

The end.

That's a nice story, but it worked because of regulations and because the other website took minutes to render a page. That makes it hard to quantify whether accessibility was a significant factor in people using your site.

But thank you for taking the time to recount this story, I'm glad good prevailed over evil!

Don't modern screen-readers work based on rendered content? So if your JS is outputting ARIA tagged DOM, it will be fine.

HTML typically just works, even for users on powerful hardware accessing non-essential services. You don't have to worry about some modal warping out of the screen, or having your scrollbar hijacked.

I hear you: Businesses have no incentive to cater to niche segments of the population as they are not revenue drivers. What you call "enhanced experience," I translate to "adverts" (what else?).

How can government compel businesses to provide better experiences? Why, standards and regulations of course.

A massive fine might help.

Social pressure in the form of "corporation xyz only supports ie6 for their bank website" is another way.

Reply on news.ycombinator.com