Web design checklist

Here is a checklist I have composed to design accessible websites. The w3m test guided me before, but that's not enough, and not even a serious approach. Most of the sections here are written from two perspectives: that of a user, and that of a webmaster. Many of the listed accessibility issues are covered in similar lists: Accessibility features in Firefox, WCAG, Berkeley web accessibility tips, Principles of Design by Tim Berners-Lee, and other Design Issues.

JS, cookies, ads, etc

JS may be useful (to a user; or at least not harmful) in rare cases, and even cookies may be useful, if you set a reasonable expiration date and store something useful (for a user, not for tracking) in them, but more often than not they are just abused and harm UX.

As a user: noscript, self-destructing cookies, uBlock Origin, privacy settings, etc. Turning JS and cookies off completely may also be an option, especially in a separate browser profile – keeping another one for the websites where those are required.

As a webmaster: try to avoid them. If you can't, still be prepared that some users will do that. Perhaps the best strategy is to implement essential functionality without relying on those, and additional features with them.


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.

As a webmaster, simply don't touch them. Even though not many users will disallow websites to screw 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. Also, not assuming that users are stupid is a nice (even if wrong in most cases) thing to do. To be fair, very slight relative size changes may be useful, as well as size changes in specific cases, and perhaps setting font families (sans, serif, mono) – but that's it.


Here's a relatively tricky part, for it is not binary. A user may leave colors be, or change the defaults, or rewrite the colors. As a user, I'm currently rewriting them. Built-in overriding is rather broken (and breaks many other things, including extension UIs), but there are global CSS themes such as Midnight Surfing, and a bunch of similar styles, extensions, and packages.

But as a webmaster, I'd like to cover all 3 cases. Complete color overriding by a user is not a problem if you are following basic accessibility guidelines, such as not using background images for regular images, duplicating image data with text, not relying on colors, and so on. Colors simply become irrelevant.

But here is what's tricky: if you don't use colors at all, then users with default settings are likely to see a rather appaling page (black-on-white, leading to eye strain), but if you set them – then users with altered default colors won't get their preferred values. Though they are rarely getting those anyway, so it should be fine to set some colors. Just keep good contrast, don't rely on them, don't rely on background images alone to serve as background, don't forget to set background and foreground colors together (i.e., don't assume what the preferred user colors are), and provide alternate stylesheets.

In a perfect system, a user would be able to pick reference colors (background, text, link) or constraints system-wide, and a web page would be able to generate a color theme using those; alas, it's not the case here.

And, of course, usual color-related guidelines should be followed when picking color themes: sufficient contrast ratio that isn't getting screwed by background images, but not black-on-white or white-on-black, nice colors, not too many of them, etc.

Some users (and in some environments) would prefer higher contrast between links and text, light-on-dark versus dark-on-light themes, etc; unless they are willing to use color overriding, there's currently no practical way to cover all those, though one could still try to provide alternate versions.

Usual accessibility

Here are the things that can't be changed by a user in a reliable and simple way – such as page layout, alternate versions, the possibility of keyboard-only control, standards-compliance, and all the other W3C recommendations. So they should be preserved by a webmaster.


Once HTML is ready, one should figure how to style the page in a way that would look nice with different settings. Paddings, margins, flex, and borders shouldn't harm; background-color-independent images, particularly SVG (making use of currentColor), and possibly with transparent backgrounds, should be nice for styling as well (see also: web graphics). I always liked minimalistic designs, but a few pictures can make a website to look considerably nicer – though they are not easy to make nice enough, and probably they harm designs more often than improve them.


Relative (particularly font-relative) length units should be used for pretty much everything; just things like border widths may use pixels.

Main (content) element width is quite 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 plenty of websites require a rather high resolution, so if it's not limited, lines may get too wide. A somewhat fine solution is to set max-width in ch.

Visual clutter

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; perhaps one should just be bold with cutting those out (or not introducing them in the first place).