Here is a checklist I have composed to design accessible websites. Most of the sections here are written from two perspectives: of a user, and of a webmaster. Some of the listed (or omitted to avoid duplication) accessibility issues are covered in similar lists: WCAG, Accessibility features in Firefox, Berkeley web accessibility tips, Principles of Design by Tim Berners-Lee and other Design Issues. WebAIM also provides interesting materials, including The WebAIM Million survey, which suggests (or confirms) generally very poor accessibility of websites. The GOV.UK Design System looks like a nice framework, too.
For a wider set of patterns, see Patterns for Personal Web Sites.
The list can be summarised as treating web pages as serious documents, as opposed to flashy flyers, interactive presentations, or showcases of one's creativity. Perhaps the easiest and pretty good way to achieve that is to avoid JS and CSS completely.
Most of the points here are rather subjective, since it is surprisingly hard to find general studies or surveys on some of the design aspects.
Proper HTML documents should be composed, usable without CSS or JS.
Navigational links, dates, and other potentially helpful bits tend to
add up to a cluttered document. It can be mitigated by incorporating
metadata (meta and link, RDFa), though there
doesn't seem to be a perfect solution that can be used and available
(i.e., supported by the common web browsers out of the box) currently.
So, they would be nice to omit, but in order to fit into regular web
usage it's still useful to show dates, and possibly navigational links.
A particularly annoying and widespread issue is clutter in the beginning of a document (sometimes including a "skip to the content" link); in graphical browsers those may be hidden, but then there are "hero" images. There should be content itself visible when opening a document, not all that stuff.
See also: "Why I don't use Netscape" (1999).
Many websites are broken, so user agents running on mobile devices tend to present all websites as broken, relying on an explicitly set viewport to tell them that it's fine to render a website properly (i.e., without hacks mitigating poorly composed web pages); seems to be similar to the "responsive design" phrase, which stands for "documents with their markup not being messed up in the particular way preventing them from being resized properly" (although as of 2021, apparently now it means that they are broken, but media queries are then used to handle a few different screen sizes; akin to breaking a physical item, putting it together with duct tape, and calling it "reinforced"). It's an awkward solution, but may be desirable to use, similarly to some CSS bits.
Likewise with the "color-scheme" standard metadata name: it should be enabled explicitly to allow a web browser to apply either a dark or a light theme, though even then it only applies it to texts and background, but not to links, usually leaving those illegible if a dark theme is used.
Giving CSS to most webmasters has an effect similar to giving WYSIWYG editors to most beginner computer users: they go crazy playing with effects, abuse styling, and resulting documents are awful.
I used to add minimal CSS in order to mitigate poor defaults of major web browsers, but then ceased to do so: it is an awkward and wrong way to fix web browser defaults, and the "fixes" themselves tend to be imperfect.
Perhaps the only way to get legible fonts everywhere as a user is not just to disable font loading, but to disallow pages to choose fonts, to limit their ability to change font sizes, and to configure the fonts for oneself. For reading from a screen, fonts without serifs seem to be appropriate, but everyone can choose what works best for them.
As a webmaster, simply don't touch them. Even though not many users will disallow websites to mess up their fonts, very few of them have fonts so bad that they require fixing by the means of CSS, and which can be fixed that way; it is much easier to just make things worse.
UI colours are covered in a separate note.
People like to adorn pages with pictures and other practically useless bits. It's an easy way to wreck accessibility, or at least to bloat pages.
Web design in general has plenty of similarities with non-web design: people try to make things to look like other things, but imperfections that creep in make it look just worse (even if it doesn't look silly in the first place); people aren't familiar with all the functionality and maintenance, want to hide functional parts away, and then it backfires; sufficiently competent designers do just a tiny fraction of all the design work that is done, and even then it's messed up once it's altered/adjusted (with either regular maintenance work or people attempting to adorn it by attaching some junk on top). A general solution in both cases is to avoid faking things, to focus on semantic/functional aspects, to make and keep those neat and clean. Though it's more important for websites, since those can commonly and easily be rendered on different devices, by different software, and with different settings.
Relative (particularly font-relative) length units should be used for pretty much everything that needs it; just things like border widths may use pixels. Perhaps it's even better to avoid altering the defaults in most cases.
Main (content) element width is tricky: while one shouldn't
reinvent OS and browser functionality, or to assume that users
can't resize windows, in practice it may not work that well:
users may just not wish to resize the windows all the time,
since many websites require a rather high resolution, so if it
is not limited, lines may get too wide. A somewhat fine
solution is to set max-width
in ch. Though pre-2023 Wikipedia, for instance,
looks fine while using full-width lines, and I'm fine with
this website not restricting the main content width either.
Another case for non-restriction is to consider whether it'd be a good default and/or universal behaviour: it's often easier to see whether proposed practices are viable when you consider whether it'd be fine if all (or nearly all) the projects followed them. And such a restriction doesn't seem to be quite sensible to actually have everywhere: if a user wants it, resizing the window would indeed suffice, but otherwise it'd be quite annoying to have large and empty enforced margins.
This includes Viola scripting language, ActiveX, Java, Flash, Silverlight, VBScript, JavaScript, Unity Web Player, WebAssembly.
Associated with unnecessary bloat and lags, security vulnerabilities, making the web unusable and creating web browser monopolies, and generally it's a bad idea. Supposed to make web pages more interactive, but these interactions remind me of those with loud/annoying advertisers/scammers, being undesirable and useless; with static documents, on the other hand, one may interact willingly, possibly processing them, or just reading them without being annoyed.
As a user: noscript, self-destructing cookies, uBlock Origin, uMatrix, privacy settings, etc. Turning those off completely (or just using a browser without support for those) may also be an option, perhaps keeping another web browser or web browser profile for the websites where those are required.
As a webmaster: avoid them. If not possible, still be prepared that some users will do that (primarily those who know how to). An acceptable strategy is to implement essential functionality without relying on those, and additional features with them. See also: Principle of Least Power.
There are papers on individual website usability evaluation, questionnaires, and just general and vague opinionated guidelines, but it's rather hard to find useful studies on topics such as general information density preferences, or how appalled users are by their default settings. One can design in a way they find usable and sensible, but when it comes to UIs aiming a wider audience, there seems to be a tendency to design for an imaginary average user, potentially leading to a cargo cult (or fashion following, perhaps), assuming that larger companies did the research well. Availability of actual studies/surveys would help with it, but I haven't found much, so this section is unfinished.
The views and approaches described above would seem rather radical to me in 2000s, when I used to compose markup based on drawn designs and to apply JS, or in 2010s, when I used to still apply a little CSS. But all along the way I had to attribute slowness, brokenness, and/or poor usability of websites to slowness of my computer hardware, to my operating system (though I used different ones) or web browser (also used different ones, the situation didn't change), to web browser settings and extensions, to me working in a dark environment (hence preferring light-on-dark themes while most of the websites were dark-on-light) and/or spending too much time in front of a screen (leading to an increased eye strain, especially with unsuitable colour themes), to my vision not coping well enough with poor colour themes and fonts. Apparently this overly charitable mindset is common: when discussing it with fellow programmers (while non-programmers usually just accept software as being broken), common sentiments were "you're not a user", "average Joe likes it". But after all this time I believe I am a user, and I suspect that Joe the average doesn't exist -- at least not in a commonly pictured idealised form, working in the exact setting the software is intended for, and generally happily using the things that tech-savvy people struggle to use. It also looks similar to a Keynesian beauty contest.
And all that time there were well-functioning websites, which didn't even do much to achieve that: they just didn't break things with useless custom decorations.