[JensRex]

>Where did we go wrong?!

I think JavaScript is what started the downward spiral that ruined the web. It's what enabled the shoehorning of the web browser into an application framework. Now Google, Facebook and Amazon and a few others control it, and are actively hostile against anyone who doesn't align with their interests.

[pjc50]

No, the real problem is a tension between standardised, accessible, boring documents and the desire for flashiness. Being nonstandard helps a website "stand out", and helps the designer sell it to the commissioner of the design. Even if this doesn't help the actual users of the website.

Many customers have a sort of "print design" mentality where they want the website to look a particular way on their device, preferably a pixel-perfect match to something done in Illustrator. This was true in the Flash era, and it's still true today - that's why you get restaurants whose menu is only available as a PDF, a deeply mobile-hostile format, when just putting it on the front page would actually be easier and work better for the user.

[userbinator]

that's why you get restaurants whose menu is only available as a PDF, a deeply mobile-hostile format, when just putting it on the front page would actually be easier and work better for the user.

IMHO that's still better than making it an SPA, because the former at least can be easily downloaded and viewed locally. Another example I've seen is a recent redesign of a public transit site, where a simple HTML form and directory of PDFs (literally --- it was just the webserver's directory listing) for finding bus schedules was turned into an SPA that took a disturbingly long time to load and was filled with, as the sibling comment puts it, "flashy, user-hostile crap". The old design was unchanged since at least 1999, if not slightly before.

[buckminster]

A local restaurant had their menu redone in React! Not just React, but React done badly. Click on "Lunch Menu", say, and literally nothing changes for 30 seconds. Then the new page appears. I took a while to realise it wasn't completely broken. God knows how much they paid for it. It's awful.

Edit: I should add, this reactivity serves no purpose. It's a sit down restaurant. You can't order electronically.

[wlesieutre]

> that's why you get restaurants whose menu is only available as a PDF, a deeply mobile-hostile format, when just putting it on the front page would actually be easier and work better for the user.

That might be the case if the website were the only place where the menu goes, but they need a paper menu for in the restaurant and just putting a PDF of that is easier than also maintaining a second copy in a web-friendly format.

[Finnucane]

That's not really a good excuse, since the PDF is made from a source document that could be repurposed to be more web-friendly if they were willing to make a small amount of extra effort.

[wlesieutre]

Small for you, a person who hangs out on HN.

Even with a service like Squarespace, asking a restaurant owner to create a well-formatted digital version of the menu and keep it up to date with any revisions is a big enough ask that they can't be assed.

Having visually impaired friends who aren't well served by a PDF that doesn't respect their text size preferences and requires zooming way in and scrolling side to side to read each line, I wish that weren't the case. But that's where we're at.

[Finnucane]

Then it sounds like there's a missed opportunity for some clever person to develop a better system for these customers to use.

[paulryanrogers]

My guess is the problem is more that there are too many such systems in use. So unifying the process to make a paper and web change requires updating a thousand different solutions.

[Causality1]

I would be fine with every restaurant having a pdf menu because that would still be better than the modern approach of not showing a menu at all until you give them your location and start an online order. Frankly most of the time I just go to their Google Maps page where I can expect to find a photograph of the in-restaurant menu taken by a helpful reviewer.

[anoncake]

It's both. The problem is that 1. people want to make flashy, user-hostile crap and 2. Javascript etc. exist so they can. Getting rid of Javascript is hard but not as hard as convincing everyone to cooperate and therefore must happen.

[perl4ever]

For almost any small business, there are a few things I want that I would think would be standardized but people don't do them.

I want a menu, a phone number, an address, the hours they are open. Maybe an email address or other message sending interface. And I want those to be easy to access on a phone or on a PC. Slap a nice picture on it if you like, but keep the functionality. Why is that so difficult/rare? I mean, it must be that the average small business owner is focused on different things that having a straightforward way for customers to contact them and get basic information.

[onion2k]

I realise it's popular to rally against JS on HN, but in this case the article is about designing a good information hierarchy for users' with sight problems, and the state of accessible design was terrible long before JS apps came along. This is not a JS problem. It's a too-many-developers-don't-care-about-accessibility problem. It's been a problem at least since I started making web software in 1997.

Going back to "design like it's 1999" would present users with things like this - https://web.archive.org/web/19991013122821/http://www.yahoo.... Try finding a link in that mess using a screenreader. You'd be sitting and waiting for it to read them all out for a while. Design was no better for accessibility back then.

The takeaway here is really that when you design a website you need to take an accessibility-first approach. This is a good article to start - https://www.smashingmagazine.com/2018/04/designing-accessibi...

[extra88]

The 1999 Yahoo, like the site in the article, is a directory, of course there are going to be a lot of links. The 1999's main flaw is a complete lack of headings (and the "buttons" on either side of the logo are image map links without accessible names).

The site in the article might have overdone it with links, having two links close to each other both going to the same destination, but from the images I think they overdid the number of headings. There are headings that are nothing but film titles and no content following. But the film title headings are heading level 4 so Simon could choose to ignore them and only read the level 2 headings which do seem to be for identifying groups of content within the page.

Simon can use Ctrl-F to look for particular text in the page, same as anyone else, if he's looking for something in particular. If he's just browsing, he's going to have to read all the links until he finds what he wants, same as anyone else. He can't visually skim in two dimensions but his screen reader can read the text much faster than a inexperienced user could understand.

[paulmooreparks]

Precisely. I'm one of the few dinosaurs who still works in the non-web software space, and I can say that accessibility is still not where it ought to be in that space, and its problems pre-date the web.

[Pigo]

Many of the people here on HN probably work at much larger corporations than I, so my take might be different. But what I have noticed is a severe lack of interest in hiring UI/UX people. Earlier in my career I had access to at least one UX person I could team up with before starting a new app.

There are some great ui libraries you can leverage these days, and they seem to fool some management into thinking pretty equals well designed. Eventually I end up in a series of meetings where we decide the aesthetics by committee. They don't seem to appreciate that a dedicated person could do it faster and better. But they always ignore my request for such a role.

[madeofpalk]

One thing I also notice when seeing issues like this is that this is also a problem with both the assistive tools themselves, and the accessibility APIs and methods available to build web pages.

I don't think there's anything inherently wrong with building content and feature rich websites, but when we do it is difficult to build them in a way, with or without javascript, that's also useful to browse through screen readers. We have to resort to hacks like skip link hacks and the rest.

I think not only do we have to get better at building accessible web pages, but the technology needs to get better to make building accessible web pages easier and more usable.

[extra88]

Skip links are mainly for people who don't use a screen reader but do solely operate the computer by keyboard (or keyboard emulator, like a switch). Screen reader users shouldn't need skip links because page content should be organized within landmarks (header, main, search, footer, etc.) and have headings identifying different parts of the page and their logical hierarchy, the screen reader gives them tools to list and move to those semantic structures.

[madeofpalk]

This is actually one of the exact 'features' I was thinking should be there. I guess this might be due to my inexperience with these tools (my problem!) but I've never experienced, or figure out how to, jump between the landmarks with VoiceOver.

[extra88]

In VoiceOver on a Mac, one way I know is to press VO-U to open the Web Rotor then use the left-right arrow keys to navigate through the options, one will list landmarks if they are present on the page.

I don't recall how to call up the Web Rotor on iOS devices.

[ntsplnkv2]

Slightly off-topic, not related to accessibility, and maybe it's nostalgia, but seeing that yahoo page from 99, I miss that web. Everything is so easy to see from there. Sure, it looks boring. But it's so functional, for me.

[onion2k]

Everything is so easy to see from there.

Yahoo has thousands of categories of links, so you're really only seeing a tiny portion. Finding something niche required drilling down three or four levels (and exploring if you couldn't find the right one.) Google's search box is much more efficient, but you lose the fun of discovery.

[ntsplnkv2]

That's fine - I would expect to find something niche after doing some research.

Show me an example of "something niche" being available. Right away?

I don't always have something I want to search for, either.

[BaronSamedi]

I agree but would qualify it. There is a clear benefit to JS based web applications. However, there was not a need to insert JS into every web site. With JS used sparingly in trusted web applications we could whitelist them and block JS everywhere else. But since JS is now ubiquitous, blocking it is tedious to impossible.

[msla]

You don't need JS to make a website where all of the text is in image files because the website designer needed to use a specific font at a specific size and loading fonts over the Internet was a bizarre pipe dream in 1999. Also, pixels are the same size for everyone, because I say so.

You don't need JS to make a website play MIDI at you.

You don't need JS to make a website shove all of the navigation into Flash. OK, maybe ActionScript is an extended version of ECMAScript, but the point is, Flash isn't accessible, and it's as bad as, if not worse than, the least accessible modern websites.

You don't need JS to make a website centered entirely around frames. Frame-centric design is truly the forgotten scourge of Web development.

The point is, there's a certain segment of the Webdev-hiring population who demands websites be either print documents or applications. They're utterly immovable and, therefore, will get what they want, which is websites with pixel-perfect rendering (regardless of how horrible they look on anything but their own monitor) or websites which, as you say, are applications in a browser. None of this is new. Web browser development has, in part, been a process of enabling browsers to appease these people while giving Webdevs more options to make the resulting pages at least somewhat less annoying.

[masswerk]

Some observations on this:

- There were JS rich and data driven web applications in the 1990s. E.g., there were all those text feeds for news etc, formatted for use with terminals. Client side reader applications for these were essential, since servers were not that powerful yet and suffered easily from load. And it could be done using the tech of the day, using hidden frames for loading what we now call padded JSON. (You had to be more on the defensive side regarding latency and loading order, since the app was dispersed over a couple of frames, but it could be done.) The main difference here was that these were dedicated applications for reading or browsing information. There was a rather strong dedication to the specific task and its mood, instead of an all over marketing approach.

- There were strong influences that are now pretty much forgotten. Especially CD-ROMs and Adobe Director. While this was on its own rather experimental and hadn't found a common form, the influence was strong. We would have loved to go full screen and immersive, like CD-ROMs, but couldn't. (Here, JS had still lacking.) I, think, if it hadn't been for JS, wide portions of the web would have been taken over by Shockvave Director plugins and Lingo. (Compare what happened later with Flash, as it became more mature.)

- There hadn't been a well established way of doing things yet. As a developer, as a designer, you pretty much wanted to contribute something new, something never seen before to the web. It was a race for the best, the coolest site, for best organization of content, etc. In light of this, the entire idea of having standard tools and templates, to be served to every customer, was just ridiculous. How could you innovate, or convey individually, or express the uniqueness of the customer to audiences by such a Stalinist approach to the web? (Compare this to nowadays, where, with a bit of bad luck, surfing – is this still a word? – is much an affair of changing color pallets.)

[teddyh]

Even before Javascript was fast enough, they already explored other avenues; i.e. toolbars and other proprietary plugins, like Flash. If Javascript had remained infeasible, some of these toolbars and plugins would have been pushed as de facto mandatory for the normal web.