Web design checklist

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 list can be summarised as treating web pages as serious documents, as opposed to flashy flyers or interactive presentations. 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.

HTML

Proper HTML documents should be composed, usable without CSS or JS.

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. 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.

"viewport"

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). It's a very awkward solution, but may be desirable to use, similarly to some CSS bits.

CSS

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.

Fonts

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 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.

Colours

UI colours are covered in a separate note.

Styling

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.

Sizes

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 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. Though Wikipedia doesn't look particularly bad while using full-width lines.

Executable code

This includes ActiveX, Java, Flash, Silverlight, VBScript, JavaScript, Unity Web Player, WebAssembly.

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.

Other usability aspects

There's plenty of 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.