It's literally just a static page that's dumped out of a JavaScript file, Shopify iframes excluded. But if you want accessibility issues:

* The header image, saying “Ben Eater”, has no alt-text. That would be fine, except the letters are individual SVG paths.

* Likewise, the social media sharing buttons also have no alt-text. A screenreader will just see four images with links at the beginning of the page.

* The YouTube videos are constructed out of multiple links without text each, including SVG images.

* The YouTube video links open into the same window, harming usability. The "target" attribute should only really be used in sites built out of frames, and this is not one of the exceptions.

* My screenreader-type program, in "just read the proper text" mode, misses half of the headings. Outside of this mode, I have to sit through over a minute of drivel before the content, because there's no skip-nav link, and then again for the video links. (This one doesn't quite count, because it's 'cause my screenreader-type program sucks and ignores aria-hidden when I set it to "all". But the lack of skip-nav is an issue.)

* Can't even read the plain, boring old text without JavaScript. This in itself is an accessibility issue.

I got bored at this point, but I'll list some other issues I spotted while looking through the dynamically-constructed DOM:

* Identical SVG images are copied-and-pasted throughout the file, but with different CSS styles – some browsers might waste time re-rendering.

* The page makes seventeen requests even with external JavaScript blocked, eleven of which are to external domains.

* The DOM contains, no joke, eight consecutive </div>s. The removal of some of these wrapping <div>s makes no perceptible difference to the page.

* Mixing and matching semantic and non-semantic HTML tags, confusing certain "reader mode" tools.

And it turns out that this page is actually multiple pages, with no machine-accessible links between them, bundled up into one file stretched across multiple URIs. This is not the proper way to handle caching the next page. I'm struggling to articulate how bad this is.

When I click on the "kits" page, random loading animations partially obscure the top of some of the paragraphs as it tries, and fails, to add some kind of inline purchase widget. There's significant DOM bloat, and displaying the page takes up an entire core of my laptop.

Because of the caching failure I failed to properly articulate earlier, refreshing a page other than the one you initially clicked onto causes a cache miss for all of them, and the retransmission of the HTML page (though fortunately not the thirteen pages worth of stuff, which are stored in the ~0.2MB JavaScript file).

Loading the "kits" page directly and following all of the instructions the page provides (not my default configuration) causes my nice new shiny laptop to max out a core for three seconds while the browser requests the website, waits for the request to complete, parses the HTML, requests the JavaScript, requests the CSS, compiles the CSS, renders the DOM according to the CSS, compiles the JavaScript, runs the JavaScript, repeatedly polls something due to a setInterval call, performs 9 DOM Events (notorious for being the slowest API of the web), recalculates the style for and re-renders the
DOM, completely hangs for 0.3 seconds for reasons unknown, recalculates, re-renders, runs some DOM events, fires off DOMContentLoaded (prematurely, not that the browser has any reason to know that – this might have accessibility impacts), runs more JavaScript to mutate the DOM further, performs several dozen incremental style updates and multiple repaints, fires off another DOMContentLoaded event, fires off the load event, fires off yet another DOMContentLoaded event, and another, and another (in amongst repeated recalculating and repainting of the DOM), fires off two more load events, etc.… Leaving behind one and a half seconds' worth of leisurely garbage collection after the page has finished loading, meaning I can't scroll until 4½ seconds after I click onto the page.

This is the only computing device I own capable of rendering the page in less than five seconds, even with my very fast network connection. Normal websites with an order of magnitude more writing, plus images and links, take an order of magnitude less time to load than this.

This website is not good. But it's nowhere near the worst out there – in fact, this would probably be in the top 60% of pages I use regularly, if I did.