Interface Developer quality checklist

11 November 2009

Towards the end of a project or sprint, time to delivery can sometimes get crushed due to any number of reasons (late wireframe or design delivery, too many iterations, staff illness, contractors leaving, underestimation, overdelivering, changing business needs, etc.), and sadly it is usually testing time that cops it.

This checklist should help you check you've got your main bases covered.

Tools you'll need

• Firefox
  • Web developer toolbar
  • Firebug
  • YSlow
• IE
  • IE developer toolbar
  • AIS web accessibility toolbar
  • Virtual PC for various IE versions.   There's no permanent URL for this, so search microsoft.com for the latest version.

Checklist

1. Having stable, valid code will save you a lot of debugging pain.  If you know your code is sound, then it is most likely a browser fault that is the cause of any further bugs from here onwards
   1. Run the W3C HTML validator on all pages and correct
   2. Run the W3C CSS validator on all pages and correct
   3. Run the WAI tool on all pages.
   4. Run your JavaScript code through JSLint
   5. If you are hoping to have good coverage on mobiles, run mobileOK on your pages
2. Check the static text content for spelling and grammar.  Mistakes here will just make you look stupid and unprofessional.
3. Check you've done a full run-through of the site in each supported browser.  You do have an agreed browser matrix don't you?
4. View your site without CSS, can you still read everything?
5. Open up each template in a new tab and run through them using CTRL+Tab to check your layouts are all the same - do the edges of the main layout boxes sit at the same position on each page or do they jump a few pixels? Is the main heading at the same position (presuming your design intends that)?
6. Run through all pages at 1024x768 resolution (or 800x600 if you are required to support it), do you have to scroll horizontally?
7. Try using your site without JavaScript.   If you can't then non-JS users will not be able to use your site and search bots will not be able to index all your content
8. Have you remembered your print stylesheet? Print preview your pages and actually print the most likely to be printed (e.g. an article template).  Sometimes the preview lies.
9. If you are using flash, check your non-flash fallback works.  You do have a fallback right?
10. If you are using embedded media, check there is a fallback for those without it and a link to the vendor site to download the plugin.
11. If you have static links in the site, run a linkchecker.  I've used Xenu in the past which is fairly good, and free.
12. Run your pages through YSlow to find any major issues
13. If you are using XMLHttpRequest (often referred to as AJAX), test what happens when the server returns a failure (e.g. a 404 or 500 rather than 200 OK)
14. Accessibility checklist (this isn't a definitive list, if for example your navigation is inconsistent between pages then you've a problem that requires the team going back to the drawing board to solve)
    1. Your content is in a sensible order in the HTML.  If you are not sure, looking at the page with CSS off will help you decide.
       • e.g. you do not break up your main content paragraphs to line up your right hand promo boxes
    2. Go through a few pages with a screenreader and keyboard.
       • Can you get to all your links and form fields without the mouse?
       • Can you hear all your content?
       • Is hidden content still 'perceivable'?  If you are hiding with display none or visibility hidden, screenreaders will ignore that content, but if you use position absolute with left being a large negative number, it will still get read out to the user.
    3. Test all your interactive features (e.g. accordions or sliders) with a keyboard, also is the screenreader able to read the information in them? (see my previous post about focus)
    4. Page sections are marked out with headings
    5. Headings do not skip levels.  This should be picked up in the HTML validation.
    6. Have a 'skip to content' link at the top of your page
    7. You can pause any animation or movement that is on by default
    8. All forms have a submit button
       • that especially includes select field (dropdown) navigation, it should never be executed from the onchange or onselect events
    9. Text can be resized in all browsers, IE6 does it differently so be sure to test if you support it
    10. All form fields have explicit labels (i.e. you use the for attribute to refer to the field's ID rather than wrapping the field inside the label element)
    11. Missing alt attributes is a common mistake, but will be picked up in your HTML validation
    12. Foreground and background colours have sufficient contrast
    13. Testing for seizure-causing animation is difficult, but the safest course of action is not to flash anything more than 3 times in 1 second.
    14. Image maps have their links duplicated underneath as a list
    15. Any static links have sensible link text that indicates where the link will go on its own without the rest of the paragraph text around it.
    16. Any linked images have sensible alt text that indicates on its own where the link will go
    17. Specify what language the page is in.  The HTML validator will pick it up if it is missing.
    18. Tables of data have a summary and scope for each column and each row is defined

Home