Design like it’s 1999(exclusive-design.vasilis.nl)
exclusive-design.vasilis.nl
Design like it’s 1999
https://exclusive-design.vasilis.nl/design-like-its-1999/
49 comments
In 99, the screenreader would have serenaded him with visitor counters "This website has had over [graphic without alt text] visitors since July 1997" and "This site works best in Microsoft Internet Explorer 4" which isn't very comforting when he's using a screen reader, and the whole website would be laid out in a table, sometimes with menus that were sliced graphics instead of text, or entirely javascript. Meanwhile the accessibility wing of the web standardistas got so angry at people using font tags instead of the designated header markups that the font tag got deprecated when css browser coverage was half decent. And let's not even start on Flash.
Not to mention the prevalence of "Mystery Meat" navigation, where you couldn't know what a graphical link did until you hovered or clicked on it.
http://www.webpagesthatsuck.com/mysterymeatnavigation.html
(For whatever it's worth I still agree with the sentiment of the author here, just worth pointing out that the 1990's weren't a panacea and that usable web design has existed throughout history.)
http://www.webpagesthatsuck.com/mysterymeatnavigation.html
(For whatever it's worth I still agree with the sentiment of the author here, just worth pointing out that the 1990's weren't a panacea and that usable web design has existed throughout history.)
You forgot image maps!
For the younger ones: https://en.wikipedia.org/wiki/Image_map
For the younger ones: https://en.wikipedia.org/wiki/Image_map
In my experience, many websites are an extension of their CEO's ego. They don't have the money to build a website that is both unique and usable, but there's no way they want to look everyone else - so they drop the requirement to be usable.
They're the same people that drive impractical cars, because they look flashy.
They're the same people that drive impractical cars, because they look flashy.
Yep.
CEO of our company didn't like the progress on one of our frontends, so he took a weekend to write a whole new one himself, claiming it was "almost done." It was, as you may predict, nowhere near done, but still shoved into Git and became the new frontend.
In reality he seemed offended that he didn't know much about how we (the frontend team) built it and he didn't like that, so he built the way he thinks he knows, which turned out to just be a hodge podge of code from various tutorials and no singular vision for how the application functions. There are no less than three different paradigms in use in this codebase, and none of them really play well together.
The end result is that it took us nearly as long as it took us to develop the first version to bring the second version up to feature parity, but now we have a giant mess of a codebase that was very strictly written to do exactly the things the CEO wrote it to do. Predictably, development slowed to a crawl pretty quickly because we're essentially forced to rewrite every single individual piece that needs touching.
I told them this was a bad idea and would only make things take far, far longer than finishing the one we had. The whole reason this was done? The CEO and CTO found some bugs but didn't want to file them on the issue tracker. They decided it was better that the CEO write his own, despite the CEO having exactly zero experience with frontend development. This is just one of a long line of bizarre decisions that I have accurately predicted would only cost us more time and money than is worth it.
We're currently looking for new jobs.
CEO of our company didn't like the progress on one of our frontends, so he took a weekend to write a whole new one himself, claiming it was "almost done." It was, as you may predict, nowhere near done, but still shoved into Git and became the new frontend.
In reality he seemed offended that he didn't know much about how we (the frontend team) built it and he didn't like that, so he built the way he thinks he knows, which turned out to just be a hodge podge of code from various tutorials and no singular vision for how the application functions. There are no less than three different paradigms in use in this codebase, and none of them really play well together.
The end result is that it took us nearly as long as it took us to develop the first version to bring the second version up to feature parity, but now we have a giant mess of a codebase that was very strictly written to do exactly the things the CEO wrote it to do. Predictably, development slowed to a crawl pretty quickly because we're essentially forced to rewrite every single individual piece that needs touching.
I told them this was a bad idea and would only make things take far, far longer than finishing the one we had. The whole reason this was done? The CEO and CTO found some bugs but didn't want to file them on the issue tracker. They decided it was better that the CEO write his own, despite the CEO having exactly zero experience with frontend development. This is just one of a long line of bizarre decisions that I have accurately predicted would only cost us more time and money than is worth it.
We're currently looking for new jobs.
That wouldn't fly where I live, there are a set of rules to make sure the website can be used by anyone and a company can be fined for breaking too many of the guidelines[1]. It's called "universal design" (or universell utforming in Norwegian)
It's not like they hunt webpages that are breaking the law, but since I have carpal tunnel syndrome excessive scrolling is painful and I've been able to make a few local webpages change just by emailing them with the guidelines. The government even provides a test-suite [2] for your web page.
I've seen plenty of the pages you mention that could use a touch of this :)
[1] https://uu.difi.no/om-oss/english
[2] https://uu.difi.no/krav-og-regelverk/testprosedyrar-nettstad... (Norwegian)
It's not like they hunt webpages that are breaking the law, but since I have carpal tunnel syndrome excessive scrolling is painful and I've been able to make a few local webpages change just by emailing them with the guidelines. The government even provides a test-suite [2] for your web page.
I've seen plenty of the pages you mention that could use a touch of this :)
[1] https://uu.difi.no/om-oss/english
[2] https://uu.difi.no/krav-og-regelverk/testprosedyrar-nettstad... (Norwegian)
>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.
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.
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.
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.
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.
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.
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.
Edit: I should add, this reactivity serves no purpose. It's a sit down restaurant. You can't order electronically.
> 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.
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.
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.
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.
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.
Then it sounds like there's a missed opportunity for some clever person to develop a better system for these customers to use.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I don't recall how to call up the Web Rotor on iOS devices.
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.
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.
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.
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.
Show me an example of "something niche" being available. Right away?
I don't always have something I want to search for, either.
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.
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.)
- 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.)
>This is a nice example of how easy it is to make something usable for someone like Simon. But it doesn’t really go beyond the usable. There is no personality in it, and we didn’t really explore other possible solutions. In the next chapter I will tell about the invisible animations I made together with Hannes Wallrafen. In this project we went beyond the functional by working with both identity and nonsensical ideas.
I don't agree, the site did it's job and it did it well. This isn't from a company, so the personality isn't that important. The accessibility is more important in this case.
I don't agree, the site did it's job and it did it well. This isn't from a company, so the personality isn't that important. The accessibility is more important in this case.
> This isn't from a company, so the personality isn't that important.
I'm curious what you mean by this? It seems to me that content from individuals is exactly where personality matters. And from a company, it matters less because both sides of the equation just want to get to a decision point on whether you'll use their product. Branding is a tool to help get to their desired outcome, not a goal in and of itself.
I'm curious what you mean by this? It seems to me that content from individuals is exactly where personality matters. And from a company, it matters less because both sides of the equation just want to get to a decision point on whether you'll use their product. Branding is a tool to help get to their desired outcome, not a goal in and of itself.
Think of it this way: for a screen reader, every bit of "identity" is a screaming popup.
Even a simple image saying "welcome to x" gets old really quick. It is already in the page title.
Narrative, linear, well delimited paginated interfaces like web search work much better, magic autoloading infinite or overly long lists do not.
Short version: if it looks fine when styles, images are disabled, it's probably ok, as long as it does not try to mess with input.
Even a simple image saying "welcome to x" gets old really quick. It is already in the page title.
Narrative, linear, well delimited paginated interfaces like web search work much better, magic autoloading infinite or overly long lists do not.
Short version: if it looks fine when styles, images are disabled, it's probably ok, as long as it does not try to mess with input.
Remember CSS Naked Day? It’s coming up now, on April 9th.
This site has A TON of personality!
Both in the copy "I'll keep it short" and also that it's unlike anything else on the web.
Both in the copy "I'll keep it short" and also that it's unlike anything else on the web.
Using a website that seems to be focused on video content as a demonstration of (in)accessibility for the blind seems a little unusual... perhaps something like a news site --- which has lots of textual content --- would make a better example.
A blind person browsing a video site does not necessarily mean they want to watch the videos. They might want to listen to the audio, or share the video links they find.
People who use screenreaders aren't necessarily completely blind. Maybe they want to watch videos but have a vision impairment that makes reading the text on the site difficult, thus use a screenreader.
People use screenreaders for many different reasons.
People use screenreaders for many different reasons.
Reminded me of a quote from Paul Arden: "All creative people need something to rebel against."
It's why things were simple and easy to understand in 1999. But then we all rebelled making it more sophisticated and complicated on purpose. And then now we all want to rebel against what we've done. The pendulum swings and swings. I do prefer the 1999 version myself :)
It's why things were simple and easy to understand in 1999. But then we all rebelled making it more sophisticated and complicated on purpose. And then now we all want to rebel against what we've done. The pendulum swings and swings. I do prefer the 1999 version myself :)
Here is a two-fold win: use the Vimium extension for navigating the web.
It lets you navigate web pages via keyboard shortcuts much faster than a mouse.
Also, it readily exposes issues of non compliant links and navigation elements that would also be missed by a screen reader.
It lets you navigate web pages via keyboard shortcuts much faster than a mouse.
Also, it readily exposes issues of non compliant links and navigation elements that would also be missed by a screen reader.
Shout out to one of my favorite projects, Luakit [^], the only chromeless browser that lets me resize the window to a single pixel.
Best part is the vim interface,
Best part is the vim interface,
:open hacker news
[ddg results]
/Hack
Enter
:tabopen github top lua questions
[Github search results]
:bookmark
The same layout is not going to work best for both sighted and impaired people. Attention spans are short and sight has an order of magnitude more information bandwidth than hearing.
He did pick one of the worst sites. The whole site is a design disaster with lots of times not working vids.
[deleted]
"Toggle Accessibility" button forwarding to a clean page.
Sitemaps or screenreaders.txt