Skip to content

Instantly share code, notes, and snippets.

@minitech
Last active January 4, 2020 11:59
Show Gist options
  • Save minitech/4146758 to your computer and use it in GitHub Desktop.
Save minitech/4146758 to your computer and use it in GitHub Desktop.
minitech’s Web Checklist

minitech’s Web Checklist

Here are some guidelines that will make me actually like your amazing new web application!

  1. Make sure encoding is handled properly every step of the way. If comes out as ’, you’ve got a problem on your hands. 😊

  2. Make it accessible. Turn off images, JavaScript, and CSS. If your website is still legible and usable (it’s okay if it’s just barely usable, or not particularly interactive) then you are already in the top 0.01%.

  3. Check your grammar. One of the fastest ways to lose respect in a blog post (or worse — in body copy) is to make basic orthographical or grammatical mistakes. These include, but are not limited to:

    • Missing apostrophes — Bitbucket even did that.
    • Extraneous apostrophes — I’ve seen more of these than I can count. Namely, “it’s” in places where “its” belongs. Twitter!
    • Typos. Spell-check is quick and convenient, but proofread all the same! Words cab bee miss spelled end stall male it pest a rudimentary check. And get someone else to proofread.
  4. Make things visible. Nobody wants to scroll all the way down the page to hunt for a link in tiny, low-contrast type. Maybe you should move more things to the top or the side, but avoid the tiny, low-contrast type, please and thank you.

  5. Handle JavaScript click events properly. Twitter fails miserably at this. Always, always, always check the mouse button and modifier keys. It’s as simple as

    if (e.button || e.altKey || e.ctrlKey || e.metaKey || e.shiftKey) return;

    . (You don’t even have to worry about compatibility, because if they’re not there, they’re falsy.) Otherwise, I will try to open something in a new tab and be annoyed when it loses my pseudo-popup page or something.

  6. Optimize for execution speed. Developers seem to, for the most part, have fast computers. Be sure to test your application on a low-powered netbook and see how it fares. Twitter, once again, fails miserably in this category. Don’t be Twitter. (Oh, what’s that, you wish you were Twitter?)

  7. Optimize for page load speed. It’s an unfortunately common mistake not to handle caching properly. Reduce the load on both your server and your client, and set the right headers. (This isn’t the only optimization by a long shot, but it’s one of the easiest and most effective.)

  8. Use pretty links. This is another one of those win-win situations. Users like to know where they’re going when they visit a link — and search engines do too!

  9. Test your site. It’s gotta be embarrassing when you push a quick bugfix and everything breaks. I hear that that “unit testing” thing can help, but make sure to go through a usual routine on every page. It might also make you notice <insert usability problem here> before it annoys people.

  10. Don't put arbitrary restrictions on your passwords. Microsoft fails miserably this time. Putting an upper bound on password length (an unreasonable one, like 16) or disallowing certain characters is a really good way to make security-savvy people wary of your service. And, of course, it should go without saying (but it won’t) that you should hash your passwords using an actual password-hashing algorithm, like scrypt or bcrypt. Even better, take the doubt away and enable OpenID- or Persona-based login!

  11. If you’re going to auto-select, do it immediately after the textbox appears. Just about everybody fails this one — including Google. Check and auto-focus fields in a <script> element that directly follows the field in question. It’s also nice when login forms check for a pre-existing username (the Back button does, in fact, do that) and select the (now empty) password box instead. If you don’t do that, make sure to use the autofocus attribute!

  12. Make sure to use a loading indicator for your fancy Ajax-y things. Stack Overflow is good at this — no need to be excessive, or to show a loading indicator for less-important actions, but the user needs to know that clicking that link actually did something.

Make the web a better place! Tell your friends! Thanks, devs.

@leniel
Copy link

leniel commented Jan 27, 2013

Nice checklist!

Copy link

ghost commented May 31, 2013

Thanks, great info. I've taken a printout:)

@panique
Copy link

panique commented Jun 11, 2013

Just want to add: Here in germany there's an official definition of "accessability of websites" by the government. You know, in central europe EVERYTHING is regulated and defined. Germans. ;)
And the most important thing in accessability is (probably to guide blind people) STRUCTURE !!!

So, what LOOKS logical to a seeing user (even without images, js, css), might be unreadable for screenreaders, when headlines mix up with other stuff, tables are not tables (!), navigation comes AFTER content, deep-level-div-sets, etc...

This is a HUGE topic, but i think it might be a good idea to keep your HTML as simple, logical and screenreader/searchengine-readable as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment